From dickinsm at gmail.com  Sat Mar  1 03:05:45 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 29 Feb 2008 21:05:45 -0500
Subject: [Python-3000] test_profile failing
In-Reply-To: <CFDE3ABF-4F02-441C-BC86-5CA39E095319@acm.org>
References: <ca471dc20802290816l125bd069y17e300542c17c7e6@mail.gmail.com>
	<CFDE3ABF-4F02-441C-BC86-5CA39E095319@acm.org>
Message-ID: <5c6f2a5d0802291805g2f5cb14fud307790aba1469ab@mail.gmail.com>

On Fri, Feb 29, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> wrote:

> They were failing for me a couple of days ago; checking now, they
> still are, and test_itertools has been added to the list of failing
> tests:
>
> test test_itertools failed -- Traceback (most recent call last):
>   File "/Users/fdrake/projects/python/py3k/Lib/test/
> test_itertools.py", line 698, in test_chain
>     self.assertRaises(TypeError, chain, N(s))
> AssertionError: TypeError not raised by chain
>

This looks like an easy one: line 698 of test_itertools.py should
be changed from

            self.assertRaises(TypeError, chain, N(s))

to

            self.assertRaises(TypeError, list, chain(N(s)))

Here N(s) is an instance of a class lacking a __next__
method; It looks like Raymond recently altered itertools.chain
to consume its arguments lazily, so the TypeError used to occur
as soon as chain(N(s)) was called, and now doesn't happen
until chain(N(s)).__next__ is first callled.

Shall I check in this fix?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080229/9844e7e0/attachment-0001.htm 

From barry at python.org  Sat Mar  1 03:13:35 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 21:13:35 -0500
Subject: [Python-3000] test_profile failing
In-Reply-To: <5c6f2a5d0802291805g2f5cb14fud307790aba1469ab@mail.gmail.com>
References: <ca471dc20802290816l125bd069y17e300542c17c7e6@mail.gmail.com>
	<CFDE3ABF-4F02-441C-BC86-5CA39E095319@acm.org>
	<5c6f2a5d0802291805g2f5cb14fud307790aba1469ab@mail.gmail.com>
Message-ID: <B74CDD27-7997-47A2-803E-C6B7319751BB@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 9:05 PM, Mark Dickinson wrote:

> On Fri, Feb 29, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> wrote:
>
>> They were failing for me a couple of days ago; checking now, they
>> still are, and test_itertools has been added to the list of failing
>> tests:
>>
>> test test_itertools failed -- Traceback (most recent call last):
>>  File "/Users/fdrake/projects/python/py3k/Lib/test/
>> test_itertools.py", line 698, in test_chain
>>    self.assertRaises(TypeError, chain, N(s))
>> AssertionError: TypeError not raised by chain
>>
>
> This looks like an easy one: line 698 of test_itertools.py should
> be changed from
>
>            self.assertRaises(TypeError, chain, N(s))
>
> to
>
>            self.assertRaises(TypeError, list, chain(N(s)))
>
> Here N(s) is an instance of a class lacking a __next__
> method; It looks like Raymond recently altered itertools.chain
> to consume its arguments lazily, so the TypeError used to occur
> as soon as chain(N(s)) was called, and now doesn't happen
> until chain(N(s)).__next__ is first callled.
>
> Shall I check in this fix?

Yes, thanks Mark!  Please say in the commit message that I approved it.

Brett, Neal and I spent several hours this evening trying to track  
down the test_profile failure, but we were unsuccessful.  We suspect  
it's due to a call from C that eventually ends up in StringIO.flush()  
but we were unable to find it.  I'm going to disable this test for the  
3.0 release; someone else is going to have to fix it.

BTW, I am on #python-dev now if anybody wants to help and/or chat  
about the release. I'm also on IM and Jabber.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8i7z3EjvBPtnXfVAQI1NQP/bmVWEdTKZ0niBqjVk003jT4XFiAfUAwr
NOBIK26zLbKeLOy6OiOQyIqnM7MjKweuS6MXZ95u+BUJYVBhfKgYuX2p5Cu+mwQq
N+N7Tsp5RmZ/sDSWMWU4Amsgy/3E9SIx+IesTN7/ExPwfR1GbmlOs+BFmD8+0QDC
O1rkPyaDlZs=
=ZWlC
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 03:15:34 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 21:15:34 -0500
Subject: [Python-3000] test_profile failing
In-Reply-To: <B74CDD27-7997-47A2-803E-C6B7319751BB@python.org>
References: <ca471dc20802290816l125bd069y17e300542c17c7e6@mail.gmail.com>
	<CFDE3ABF-4F02-441C-BC86-5CA39E095319@acm.org>
	<5c6f2a5d0802291805g2f5cb14fud307790aba1469ab@mail.gmail.com>
	<B74CDD27-7997-47A2-803E-C6B7319751BB@python.org>
Message-ID: <0468F2D1-4084-44B5-B147-4A0C6DCE829D@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 9:13 PM, Barry Warsaw wrote:

> BTW, I am on #python-dev now if anybody wants to help and/or chat
> about the release. I'm also on IM and Jabber.

Oh, and I'm doing 2.6 first in case anybody is motivated to keep  
looking for the test_profile failure this evening!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8i8R3EjvBPtnXfVAQIUJAP9FyLrvPFZKR7p57vK6gCgW7a1pOQtyJg/
s0nn5VdksgJnBtk10+9N4pCzppNW9keps2ef5nTj3InjGUzC+fFPTMd0r0DiNgTP
ilJXs0Jc9IbcFd6A/5lbsDoO8hdVdDbIuMp8Af5+1wP3/x56LR+PJ77RsHShMxpv
WmL3YjW365g=
=Agv6
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 05:38:32 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 23:38:32 -0500
Subject: [Python-3000] No releases tonight
Message-ID: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I tried, I really did.

Python 2.6 is nearly ready, I'm mostly trying to figure out how to  
build the web pages properly.  I haven't started on 3.0, but huge  
thanks go to Brett Cannon, Neal Norwitz, Mark Dickinson, and Fred  
Drake for helping out tonight with everything, including fixing the  
outstanding bugs in 3.0.

Python 2.6a1 is tagged and built, so feel free to commit changes to  
the trunk.

Python 3.0 is not tagged yet so if you can hold off from committing to  
that branch for a little while longer, that would be appreciated.  I  
will cut 3.0a3 tomorrow (Saturday) as early as possible.

time-to-start-drinking-ly y'rs,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8jdyXEjvBPtnXfVAQJSowQAgIqqYKYPvzEMtvtAHiNC+OkMpO3vxelh
9kcAgXClhCS47wAMc9viJsb5Uo12f7TlOURkEjuMZ13jrBri+HCFtrAGjjHj/qHk
KyH9ua+q0dCtpg0P0CzvxznGr7k2XV5LiZit4G+UwuSokJr/F/dUDQV3jkSgWEvh
xTRj8ZZisQw=
=Hg6S
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 15:11:34 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 09:11:34 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <fqaq21$5ao$1@ger.gmane.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
Message-ID: <CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 12:36 AM, Steve Holden wrote:

> If you can document the web stuff you have to do I will formalize it  
> as
> a procedure for use in future releases.

Hi Steve,

In this case, there was a lot more work to do because 2.6 wasn't tied  
in at all.  Add to the fact that I didn't have any experience with the  
website infrastructure made things a bit more difficult the first time  
out.  I still don't quite have the 2.6 links working correctly in my  
local fs.  So the biggest problem is really: what steps do you take  
when you need to expose a new major release on the website?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8lkF3EjvBPtnXfVAQLjtQP/cyIu6i/3hL7RMyJjwi5UWaVelq+6+DjX
c8P6aLT0Gq2jIIacwt2P5lWYGx5D2nahoLCkLoA4M3avHM6UiTaIW45nFrnffItx
F/ib/UY/j+gsudlg5GsZQrBTzvrso6BFDuIr9VISuzf3e6QRr7sAhUfXzgIETXjj
DPT3y474bDs=
=Kxv7
-----END PGP SIGNATURE-----

From steve at holdenweb.com  Sat Mar  1 16:38:32 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 01 Mar 2008 10:38:32 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
Message-ID: <fqbta0$vf8$1@ger.gmane.org>

Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mar 1, 2008, at 12:36 AM, Steve Holden wrote:
> 
>> If you can document the web stuff you have to do I will formalize it  
>> as
>> a procedure for use in future releases.
> 
> Hi Steve,
> 
> In this case, there was a lot more work to do because 2.6 wasn't tied  
> in at all.  Add to the fact that I didn't have any experience with the  
> website infrastructure made things a bit more difficult the first time  
> out.  I still don't quite have the 2.6 links working correctly in my  
> local fs.  So the biggest problem is really: what steps do you take  
> when you need to expose a new major release on the website?
> 
I guess the thing to do is to look at your diffs once you have committed 
the changes - I presume this'll all be dropped in as a single revision?

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From guido at python.org  Sat Mar  1 16:55:29 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 1 Mar 2008 07:55:29 -0800
Subject: [Python-3000] [Python-3000-checkins] r61155 -
	python/branches/py3k/Lib/test/test_profile.py
In-Reply-To: <20080301042823.E44341E401A@bag.python.org>
References: <20080301042823.E44341E401A@bag.python.org>
Message-ID: <ca471dc20803010755i63f78b6dj60ec8cdc78f315d@mail.gmail.com>

Thanks for fixing this Brett!

test_cProfile.py is still failing, but I think that's because it's the
wrong file. In 2.6, test_cprofile and test_profile are rather similar.
But in 3.0, test_cProfile.py seems to be a clone of the 'profilee.py'
test program... Probably a manual-merge glitch. Maybe it should just
be deleted and replaced with a modified copy of test_profile.py?

--Guido

On Fri, Feb 29, 2008 at 8:28 PM, brett.cannon
<python-3000-checkins at python.org> wrote:
> Author: brett.cannon
>  Date: Sat Mar  1 05:28:23 2008
>  New Revision: 61155
>
>  Modified:
>    python/branches/py3k/Lib/test/test_profile.py
>  Log:
>  Change test_profile to only compare data that originates from the test file.
>  Including the full output becomes hairy in the face of the I/O system being
>  written in Python and thus profiled (i.e., running the test on its own and then
>  under regrtest created a different profile thanks to an extra flush() call in
>  the latter case).
>
>  No need to backport as 2.x's I/O is entirely C-based and thus not profiled.
>
>
>  Modified: python/branches/py3k/Lib/test/test_profile.py
>  ==============================================================================
>  --- python/branches/py3k/Lib/test/test_profile.py       (original)
>  +++ python/branches/py3k/Lib/test/test_profile.py       Sat Mar  1 05:28:23 2008
>  @@ -29,7 +29,13 @@
>              stats = pstats.Stats(prof, stream=s)
>              stats.strip_dirs().sort_stats("stdname")
>              getattr(stats, methodname)()
>  -            results.append(s.getvalue())
>  +            output = s.getvalue().splitlines()
>  +            mod_name = testfunc.__module__.rsplit('.', 1)[1]
>  +            # Only compare against stats originating from the test file.
>  +            # Prevents outside code (e.g., the io module) from causing
>  +            # unexpected output.
>  +            output = [line.rstrip() for line in output if mod_name in line]
>  +            results.append('\n'.join(output))
>          return results
>
>      def test_cprofile(self):
>  @@ -53,7 +59,7 @@
>      with open(filename, 'r') as f:
>          for line in f:
>              newfile.append(line)
>  -            if line[:6] == '#--cut':
>  +            if line.startswith('#--cut'):
>                  break
>
>      with open(filename, 'w') as f:
>  @@ -77,22 +83,6 @@
>   # Don't remove this comment. Everything below it is auto-generated.
>   #--cut--------------------------------------------------------------------------
>   ProfileTest.expected_output['print_stats'] = """\
>  -         126 function calls (106 primitive calls) in 999.751 CPU seconds
>  -
>  -   Ordered by: standard name
>  -
>  -   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>  -        4   -0.004   -0.001   -0.004   -0.001 :0(append)
>  -        4   -0.004   -0.001   -0.004   -0.001 :0(exc_info)
>  -        1   -0.004   -0.004  999.753  999.753 :0(exec)
>  -       12   -0.024   -0.002   11.964    0.997 :0(hasattr)
>  -        1    0.000    0.000    0.000    0.000 :0(setprofile)
>  -        1   -0.002   -0.002  999.767  999.767 <string>:1(<module>)
>  -        2   -0.004   -0.002   -0.010   -0.005 io.py:1213(flush)
>  -        2   -0.002   -0.001   -0.002   -0.001 io.py:656(closed)
>  -        2   -0.004   -0.002   -0.006   -0.003 io.py:874(flush)
>  -        0    0.000             0.000          profile:0(profiler)
>  -        1   -0.002   -0.002  999.751  999.751 profile:0(testfunc())
>         28   27.972    0.999   27.972    0.999 profilee.py:110(__getattr__)
>          1  269.996  269.996  999.769  999.769 profilee.py:25(testfunc)
>       23/3  149.937    6.519  169.917   56.639 profilee.py:35(factorial)
>  @@ -101,26 +91,12 @@
>          4  115.984   28.996  119.964   29.991 profilee.py:73(helper1)
>          2   -0.006   -0.003  139.946   69.973 profilee.py:84(helper2_indirect)
>          8  311.976   38.997  399.912   49.989 profilee.py:88(helper2)
>  -        8   63.976    7.997   79.960    9.995 profilee.py:98(subhelper)
>  -
>  -
>  -"""
>  +        8   63.976    7.997   79.960    9.995 profilee.py:98(subhelper)"""
>   ProfileTest.expected_output['print_callers'] = """\
>  -   Ordered by: standard name
>  -
>  -Function                          was called by...
>   :0(append)                        <- profilee.py:73(helper1)(4)  119.964
>   :0(exc_info)                      <- profilee.py:73(helper1)(4)  119.964
>  -:0(exec)                          <- profile:0(testfunc())(1)  999.751
>   :0(hasattr)                       <- profilee.py:73(helper1)(4)  119.964
>                                       profilee.py:88(helper2)(8)  399.912
>  -:0(setprofile)                    <- profile:0(testfunc())(1)  999.751
>  -<string>:1(<module>)              <- :0(exec)(1)  999.753
>  -io.py:1213(flush)                 <- :0(exec)(2)  999.753
>  -io.py:656(closed)                 <- io.py:874(flush)(2)   -0.006
>  -io.py:874(flush)                  <- io.py:1213(flush)(2)   -0.010
>  -profile:0(profiler)               <-
>  -profile:0(testfunc())             <- profile:0(profiler)(1)    0.000
>   profilee.py:110(__getattr__)      <- :0(hasattr)(12)   11.964
>                                       profilee.py:98(subhelper)(16)   79.960
>   profilee.py:25(testfunc)          <- <string>:1(<module>)(1)  999.767
>  @@ -133,27 +109,10 @@
>   profilee.py:84(helper2_indirect)  <- profilee.py:55(helper)(2)  599.830
>   profilee.py:88(helper2)           <- profilee.py:55(helper)(6)  599.830
>                                       profilee.py:84(helper2_indirect)(2)  139.946
>  -profilee.py:98(subhelper)         <- profilee.py:88(helper2)(8)  399.912
>  -
>  -
>  -"""
>  +profilee.py:98(subhelper)         <- profilee.py:88(helper2)(8)  399.912"""
>   ProfileTest.expected_output['print_callees'] = """\
>  -   Ordered by: standard name
>  -
>  -Function                          called...
>  -:0(append)                        ->
>  -:0(exc_info)                      ->
>  -:0(exec)                          -> <string>:1(<module>)(1)  999.767
>  -                                     io.py:1213(flush)(2)   -0.010
>   :0(hasattr)                       -> profilee.py:110(__getattr__)(12)   27.972
>  -:0(setprofile)                    ->
>   <string>:1(<module>)              -> profilee.py:25(testfunc)(1)  999.769
>  -io.py:1213(flush)                 -> io.py:874(flush)(2)   -0.006
>  -io.py:656(closed)                 ->
>  -io.py:874(flush)                  -> io.py:656(closed)(2)   -0.002
>  -profile:0(profiler)               -> profile:0(testfunc())(1)  999.751
>  -profile:0(testfunc())             -> :0(exec)(1)  999.753
>  -                                     :0(setprofile)(1)    0.000
>   profilee.py:110(__getattr__)      ->
>   profilee.py:25(testfunc)          -> profilee.py:35(factorial)(1)  169.917
>                                       profilee.py:55(helper)(2)  599.830
>  @@ -164,16 +123,11 @@
>                                       profilee.py:84(helper2_indirect)(2)  139.946
>                                       profilee.py:88(helper2)(6)  399.912
>   profilee.py:73(helper1)           -> :0(append)(4)   -0.004
>  -                                     :0(exc_info)(4)   -0.004
>  -                                     :0(hasattr)(4)   11.964
>   profilee.py:84(helper2_indirect)  -> profilee.py:35(factorial)(2)  169.917
>                                       profilee.py:88(helper2)(2)  399.912
>   profilee.py:88(helper2)           -> :0(hasattr)(8)   11.964
>                                       profilee.py:98(subhelper)(8)   79.960
>  -profilee.py:98(subhelper)         -> profilee.py:110(__getattr__)(16)   27.972
>  -
>  -
>  -"""
>  +profilee.py:98(subhelper)         -> profilee.py:110(__getattr__)(16)   27.972"""
>
>   if __name__ == "__main__":
>      main()
>  _______________________________________________
>  Python-3000-checkins mailing list
>  Python-3000-checkins at python.org
>  http://mail.python.org/mailman/listinfo/python-3000-checkins
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Sat Mar  1 17:30:58 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 11:30:58 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <fqbta0$vf8$1@ger.gmane.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<fqbta0$vf8$1@ger.gmane.org>
Message-ID: <506EC4C0-11C1-4032-BB18-16C65E1EEC5B@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 10:38 AM, Steve Holden wrote:

> Barry Warsaw wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Mar 1, 2008, at 12:36 AM, Steve Holden wrote:
>>
>>> If you can document the web stuff you have to do I will formalize it
>>> as
>>> a procedure for use in future releases.
>>
>> Hi Steve,
>>
>> In this case, there was a lot more work to do because 2.6 wasn't tied
>> in at all.  Add to the fact that I didn't have any experience with  
>> the
>> website infrastructure made things a bit more difficult the first  
>> time
>> out.  I still don't quite have the 2.6 links working correctly in my
>> local fs.  So the biggest problem is really: what steps do you take
>> when you need to expose a new major release on the website?
>>
> I guess the thing to do is to look at your diffs once you have  
> committed
> the changes - I presume this'll all be dropped in as a single  
> revision?

That would be great Steve, thanks!  r11294.

I'm going to build Python 3.0 now.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mEw3EjvBPtnXfVAQKm9gP+PdoDvqTmA4kuqVrNmQJdHSsQDVcB7/sV
BRxeYH0S1TNo05NCzv6qyJ6nxe2CVI6he+chhoCbtCRqp6c5LQOXtaSHUqoSNzP9
FSw9YnQ3DHmFRX3BfNyZ7d9FS2Fs5irsLuAc+WUFNR0AWsvbwXR6qlT0qNQGP666
V46DiUdNhUA=
=ybmk
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 17:52:45 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 11:52:45 -0500
Subject: [Python-3000] [Python-3000-checkins] r61155 -
	python/branches/py3k/Lib/test/test_profile.py
In-Reply-To: <ca471dc20803010755i63f78b6dj60ec8cdc78f315d@mail.gmail.com>
References: <20080301042823.E44341E401A@bag.python.org>
	<ca471dc20803010755i63f78b6dj60ec8cdc78f315d@mail.gmail.com>
Message-ID: <8F9636D5-910D-4C42-8BE9-93FA392E1CA1@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 10:55 AM, Guido van Rossum wrote:

> Thanks for fixing this Brett!

Indeed!

> test_cProfile.py is still failing, but I think that's because it's the
> wrong file. In 2.6, test_cprofile and test_profile are rather similar.
> But in 3.0, test_cProfile.py seems to be a clone of the 'profilee.py'
> test program... Probably a manual-merge glitch. Maybe it should just
> be deleted and replaced with a modified copy of test_profile.py?

I tried the brain-dead simplest way of doing this and didn't get it to  
pass.  For now, I'm just going to disable test_cProfile and cut  
3.0a3.  We can repair it for the next alpha.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mJ3XEjvBPtnXfVAQKnIQP+LFoFWccuzguQc/mNFKSzGLl3OcYPojCw
+NomjebaHbyZa9V5SWi8xIDzLoRqf7uc7FYWxOmXQIR3H9LCHqR5HKFWTwyZnuW6
B+esv8+WZwpOjxhyZTWXFOjx/BA4kXKJCOY+ZxkVoKLh7N2aOE4X6WUcCgeWv3r8
lOAtjpo4RKg=
=alcS
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 19:51:38 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 13:51:38 -0500
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
Message-ID: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team and the Python community, I'm  
happy to announce the first alpha release of Python 2.6, and the third  
alpha release of Python 3.0.

Python 2.6 is not only the next advancement in the Python 2 series, it  
is also a transitionary release, helping developers begin to prepare  
their code for Python 3.0.  As such, many features are being  
backported from Python 3.0 to 2.6.  It makes sense to release both  
versions in at the same time, the precedence for this having been set  
with the Python 1.6 and 2.0 releases.

During the alpha testing cycle we will be releasing both versions in  
lockstep, on a monthly release cycle.  The releases will happen on the  
last Friday of every month.  If this schedule works well, we will  
continue releasing in lockstep during the beta program.  See PEP 361  
for schedule details:

     http://www.python.org/dev/peps/pep-0361/

Please note that these are alpha releases, and as such are not  
suitable for production environments.  We continue to strive for a  
high degree of quality, but there are still some known problems and  
the feature sets have not been finalized.  These alphas are being  
released to solicit feedback and hopefully discover bugs, as well as  
allowing you to determine how changes in 2.6 and 3.0 might impact  
you.  If you find things broken or incorrect, please submit a bug  
report at

     http://bugs.python.org

For more information and downloadable distributions, see the Python  
2.6 web
site:

     http://www.python.org/download/releases/2.6/

and the Python 3.0 web site:

     http://www.python.org/download/releases/3.0/

We are planning a number of additional alpha releases, with the final  
release schedule still to be determined.

Enjoy,
- -Barry

Barry Warsaw
barry at python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mlu3EjvBPtnXfVAQKePAQAgx6w9wztfJaSWkbKrbwur2U6t6o5aIY5
pyMa00CZWY06p8099BztcSjgp5rKrd6/9V7cJ0NP7NLZ+tz20uRfyI8uqoIYBIWC
ibJay6SSnzgOQM3PRIJV/K/m0dVPPPVD1LDnoEvuu+cKUpV434yHdgWkMPswsxUd
fLydrXABlOM=
=l6aj
-----END PGP SIGNATURE-----

From lists at cheimes.de  Sat Mar  1 19:56:28 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 01 Mar 2008 19:56:28 +0100
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
Message-ID: <47C9A6DC.9070708@cheimes.de>

Barry Warsaw wrote:
> In this case, there was a lot more work to do because 2.6 wasn't tied
> in at all.  Add to the fact that I didn't have any experience with the
> website infrastructure made things a bit more difficult the first time
> out.  I still don't quite have the 2.6 links working correctly in my
> local fs.  So the biggest problem is really: what steps do you take
> when you need to expose a new major release on the website?

Starting with the first betas of 2.6 and 3.0 we should also work on
official texts for the press. Other projects like PHP are drawing lots
of attention with their releases, even with bug fix and security
releases. Bad news are better than no news - a beta release is *good* news.

When 3.0a2 was released I contacted two larger German IT news sites. Non
of them even bother to reply. :/

I propose that we provide two official texts for the press. A shorter
text which explains Python and the most important changes since the last
version in a few paragraphs and a longer, more detailed text like
Martin's text for the 2.5.2 release.

I also propose translations of the shorter text to important languages
like French, German, Japanese, Portuguese and Spanish. I'm willing to
help with the German translation.

Christian

From steve at holdenweb.com  Sat Mar  1 20:01:36 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 01 Mar 2008 14:01:36 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <47C9A6DC.9070708@cheimes.de>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
Message-ID: <fqc96p$4qh$1@ger.gmane.org>

Christian Heimes wrote:
> Barry Warsaw wrote:
>> In this case, there was a lot more work to do because 2.6 wasn't tied
>> in at all.  Add to the fact that I didn't have any experience with the
>> website infrastructure made things a bit more difficult the first time
>> out.  I still don't quite have the 2.6 links working correctly in my
>> local fs.  So the biggest problem is really: what steps do you take
>> when you need to expose a new major release on the website?
> 
> Starting with the first betas of 2.6 and 3.0 we should also work on
> official texts for the press. Other projects like PHP are drawing lots
> of attention with their releases, even with bug fix and security
> releases. Bad news are better than no news - a beta release is *good* news.
> 
> When 3.0a2 was released I contacted two larger German IT news sites. Non
> of them even bother to reply. :/
> 
> I propose that we provide two official texts for the press. A shorter
> text which explains Python and the most important changes since the last
> version in a few paragraphs and a longer, more detailed text like
> Martin's text for the 2.5.2 release.
> 
> I also propose translations of the shorter text to important languages
> like French, German, Japanese, Portuguese and Spanish. I'm willing to
> help with the German translation.
> 
> Christian

PyCon is using a PR team to help with publicity. Maybe we can ask them 
for assistance on how to get the word out?

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From barry at python.org  Sat Mar  1 20:07:49 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 14:07:49 -0500
Subject: [Python-3000] The release process
Message-ID: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just announced the 2.6a1 and 3.0a3 releases, and am thawing both  
branches.

Just some quick feedback in case anybody is interested.  First, huge  
thanks go to Brett Cannon, Neal Norwitz, Mark Dickinson and Fred Drake  
for their help last night. Apologies also to them for my drunken rants  
on jabber :).  Also thanks to Martin von Loewis for the Windows msi's  
for Python 2.6.  I'm sure Martin will soon provide msi's for 3.0, but  
these are not yet available.

Some other random notes:

Brett fixed test_profile in 3.0 last night but test_cProfile was still  
broken.  I disabled the test via a TestSkipped and set this to  
expected in regrtest.py.  This test should be fixed and the expected  
skip removed.

I will definitely need help keeping the various NEWS files up to  
date.  I don't see any way that I'll be able to spend time on these  
when I'm cutting a release.  Python 2.6 NEWS was simply impossible to  
proofread because of its sheer size and the fact that it was the first  
alpha of the series.

PEP 101 describes 4 news files: Misc/NEWS and Lib/idlelib/NEWS.txt for  
both 2.6 and 3.0.  I am urgently requesting that when people commit  
newsworthy items to the Python releases that they keep the NEWS files  
up-to-date.  This is especially tricky for code merged between the two  
versions.  Thanks to Neal for looking over 3.0's NEWS file last  
night.  As RM, I am going to operate on the assumption that the NEWS  
files are up-to-date.  I'd be thrilled if someone volunteered to be  
the "NEWS czar" -- we all know when the next alpha release is coming  
(Friday March 25), so this czar would be responsible for watching  
commits and making sure that NEWS was updated as appropriate, or  
harassing the committer into updating NEWS to describe their new  
feature.  If you'd like to be this NEWS czar, please let me know.

With apologies to Anthony, welease is crack.  I made pretty good  
progress once I ditched it and starting doing things manually.   
Between now and the next alpha I intend to work on a command line  
script to help with releases.  If you're interested in helping, let me  
know.

PEP 101 is sorely out of date, especially with regards to updating web  
content and the Python documentation.  I think I now know how to  
update the python.org web site, but the new Python documentation  
format is still a mystery to me.  If someone would like to help update  
PEP 101 for the documentation steps, please let me know.

PEP 101 also describes some steps for updating the distutils version  
numbers.  These instructions seemed stale too.  If you know anything  
about distutils version numbers and the process for updating them,  
please contact me.

There's no Misc/RPM/python-3.0.spec file so I skipped that step too.   
Sean, do you know anything about that?

That's it.  See you again next time :).  Let me know if you notice  
anything broken about the releases.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mphXEjvBPtnXfVAQKPcwQAqQVP+IWO60/m1Rm1OKpcGfpS+BZILKvj
LkLJamZ6gvupFeJj1kCr6eAl62Mqaec2Z29jsnXK9TfAogGGVcW21a98rgcQUong
fRh34dt1YGVMcqw4r8G60kqYQG4caGJ9tS5oKEXq+lYWPfirLZ7mC1SkkfnJ9mVd
Cscr0ZAYayI=
=nnlY
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar  1 20:11:18 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 14:11:18 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <47C9A6DC.9070708@cheimes.de>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
Message-ID: <3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 1:56 PM, Christian Heimes wrote:

> Barry Warsaw wrote:
>> In this case, there was a lot more work to do because 2.6 wasn't tied
>> in at all.  Add to the fact that I didn't have any experience with  
>> the
>> website infrastructure made things a bit more difficult the first  
>> time
>> out.  I still don't quite have the 2.6 links working correctly in my
>> local fs.  So the biggest problem is really: what steps do you take
>> when you need to expose a new major release on the website?
>
> Starting with the first betas of 2.6 and 3.0 we should also work on
> official texts for the press. Other projects like PHP are drawing lots
> of attention with their releases, even with bug fix and security
> releases. Bad news are better than no news - a beta release is  
> *good* news.

Great idea, and I agree.  I won't be the person spearheading this  
though, but since it'll probably be me making the announcement, I'd  
like to coordinate with this effort.

> When 3.0a2 was released I contacted two larger German IT news sites.  
> Non
> of them even bother to reply. :/
>
> I propose that we provide two official texts for the press. A shorter
> text which explains Python and the most important changes since the  
> last
> version in a few paragraphs and a longer, more detailed text like
> Martin's text for the 2.5.2 release.
>
> I also propose translations of the shorter text to important languages
> like French, German, Japanese, Portuguese and Spanish. I'm willing to
> help with the German translation.

Cool, thanks.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mqVnEjvBPtnXfVAQIlkAP/U5z0xSaaDKbXxArncL49NpRTU5O431Wi
+qdlnJQbApMtWMJyw14jXD0ovDlAFFK/71fGSUW7IxBvd+sWy9xJJpwydNz5xUVJ
Ze3GYX0pWF0zDp9IIX9o3W9uotm9156lWe8Ahbsa0TWXN2AXyuRjyccIS7v2mU55
mHY6niZ8SbE=
=OJl/
-----END PGP SIGNATURE-----

From lists at cheimes.de  Sat Mar  1 20:43:24 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 01 Mar 2008 20:43:24 +0100
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <fqc96p$4qh$1@ger.gmane.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>	<47C9A6DC.9070708@cheimes.de>
	<fqc96p$4qh$1@ger.gmane.org>
Message-ID: <47C9B1DC.5070201@cheimes.de>

Steve Holden wrote:
> PyCon is using a PR team to help with publicity. Maybe we can ask them 
> for assistance on how to get the word out?

That's a *very* good idea! Let's ask some professionals rather than
writing something on our own.

Christian

From steve at holdenweb.com  Sat Mar  1 20:57:13 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 01 Mar 2008 14:57:13 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <47C9B1DC.5070201@cheimes.de>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>	<fqaq21$5ao$1@ger.gmane.org>	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>	<47C9A6DC.9070708@cheimes.de>	<fqc96p$4qh$1@ger.gmane.org>
	<47C9B1DC.5070201@cheimes.de>
Message-ID: <fqccf2$fl2$1@ger.gmane.org>

Christian Heimes wrote:
> Steve Holden wrote:
>> PyCon is using a PR team to help with publicity. Maybe we can ask them 
>> for assistance on how to get the word out?
> 
> That's a *very* good idea! Let's ask some professionals rather than
> writing something on our own.
> 
> Christian

Done, with a Cc: to Barry as release manager. Let's see whether they can 
help, at least. It's important news for PyCon anyway ...

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From lists at cheimes.de  Sat Mar  1 21:04:27 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 01 Mar 2008 21:04:27 +0100
Subject: [Python-3000] The release process
In-Reply-To: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
Message-ID: <47C9B6CB.1060909@cheimes.de>

Barry Warsaw wrote:
> I will definitely need help keeping the various NEWS files up to
> date.  I don't see any way that I'll be able to spend time on these
> when I'm cutting a release.  Python 2.6 NEWS was simply impossible to
> proofread because of its sheer size and the fact that it was the first
> alpha of the series.
> 
> PEP 101 describes 4 news files: Misc/NEWS and Lib/idlelib/NEWS.txt for
> both 2.6 and 3.0.  I am urgently requesting that when people commit
> newsworthy items to the Python releases that they keep the NEWS files
> up-to-date.  This is especially tricky for code merged between the two
> versions.  Thanks to Neal for looking over 3.0's NEWS file last
> night.  As RM, I am going to operate on the assumption that the NEWS
> files are up-to-date.  I'd be thrilled if someone volunteered to be
> the "NEWS czar" -- we all know when the next alpha release is coming
> (Friday March 25), so this czar would be responsible for watching
> commits and making sure that NEWS was updated as appropriate, or
> harassing the committer into updating NEWS to describe their new
> feature.  If you'd like to be this NEWS czar, please let me know.

I *never* sync changes from trunk Misc/NEWS to py3k Misc/NEWS. From my
point of view it doesn't make sense to put Python 2.6 changes in the
same section as Python 3.0 changes. Moving changes from to the right
section would put a large and unnecessary burden on me. In general every
change of the 2.6 source tree makes it into 3.0. Exceptions to the rule
is stuff that makes no sense like 3.0 compatibility and warnings.

Thumb rule: Changes, bug fixes and new features in 2.6 are also in 3.0
except they are outruled by a Python 3.0 feature.

Several people including me and Guido himself are watching the cvs
lists. We make sure everybody adds an entry to Misc/NEWS whenever a bug
is fixed or a new feature is added. Otherwise we crack the whip ^H^H^H
contact the committer. You can be sure that at least 98% of  all closed
bug reports, feature request and important changes have an entry in
Misc/NEWS.

So in general Misc/NEWS isn't an issue but Docs/whatsnew/ is. Only a
couple of people - mostly Georg and Andrew - are updating the files.

Christian

From tjreedy at udel.edu  Sat Mar  1 22:48:10 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 1 Mar 2008 16:48:10 -0500
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>
Message-ID: <fqciun$3l2$1@ger.gmane.org>


"Barry Warsaw" <barry at python.org> wrote in message 
news:6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB at python.org...
| -----BEGIN PGP SIGNED MESSAGE-----
|     http://www.python.org/download/releases/3.0/

As of 4:50 PM  EST, the links to Windows installers give 404 File Not 
Found.

I gather that they are still in process,
and notice that there is no public c.l.p. announcement. 




From martin at v.loewis.de  Sat Mar  1 23:26:10 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 01 Mar 2008 23:26:10 +0100
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <fqciun$3l2$1@ger.gmane.org>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>
	<fqciun$3l2$1@ger.gmane.org>
Message-ID: <47C9D802.2090205@v.loewis.de>

> As of 4:50 PM  EST, the links to Windows installers give 404 File Not 
> Found.
> 
> I gather that they are still in process,
> and notice that there is no public c.l.p. announcement. 

I just fixed that. The files were there; just the links were wrong.

Regards,
Martin

From barry at python.org  Sat Mar  1 23:29:39 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 17:29:39 -0500
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <47C9D802.2090205@v.loewis.de>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>
	<fqciun$3l2$1@ger.gmane.org> <47C9D802.2090205@v.loewis.de>
Message-ID: <05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 5:26 PM, Martin v. L?wis wrote:

>> As of 4:50 PM  EST, the links to Windows installers give 404 File Not
>> Found.
>>
>> I gather that they are still in process,
>> and notice that there is no public c.l.p. announcement.
>
> I just fixed that. The files were there; just the links were wrong.

Thanks for fixing these Martin!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8nY1HEjvBPtnXfVAQJ3YgP/TYr0X5vRqvVDEMgsHxHuiSuYZCIr8y36
ibAh3RAGeLLK7C7NiOyAfxkesf91HCbL1in0TcnD06QZy52O8elBa927JOomP3mc
Y6K4Y49JhxonBrmGcmasnc9PFjbhXtGdWLREinuzpB5itLpRv+SevMhxP27Fp8qr
df173TV4hpk=
=nf32
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Mar  1 23:37:05 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 01 Mar 2008 23:37:05 +0100
Subject: [Python-3000] The release process
In-Reply-To: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
Message-ID: <47C9DA91.9000105@v.loewis.de>

> With apologies to Anthony, welease is crack.  I made pretty good  
> progress once I ditched it and starting doing things manually.   
> Between now and the next alpha I intend to work on a command line  
> script to help with releases.  If you're interested in helping, let me  
> know.

I guess every release manager is free to come up with his own set of
tools, but I feel you've given up too quickly (or started too late -
perhaps a test release run a few days before the release would have
helped).

In any case, I'm willing to help with welease, but not with yet another
release tool. If you primarily complain about the GUIness of welease,
I could help with a command line version of it.

Regards,
Martin

From p.f.moore at gmail.com  Sat Mar  1 23:39:41 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 1 Mar 2008 22:39:41 +0000
Subject: [Python-3000] [Python-Dev]  RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <47C9D802.2090205@v.loewis.de>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>
	<fqciun$3l2$1@ger.gmane.org> <47C9D802.2090205@v.loewis.de>
Message-ID: <79990c6b0803011439n583bc2b2w5c544b620a91fa61@mail.gmail.com>

On 01/03/2008, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > As of 4:50 PM  EST, the links to Windows installers give 404 File Not
>  > Found.
>  >
>  > I gather that they are still in process,
>  > and notice that there is no public c.l.p. announcement.
>
>
> I just fixed that. The files were there; just the links were wrong.

The 2.6a1 x86 MSI is there, but the 3.0a3 x86 MSI is still giving a 404.

Paul.

From barry at python.org  Sat Mar  1 23:46:31 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 17:46:31 -0500
Subject: [Python-3000] The release process
In-Reply-To: <47C9B6CB.1060909@cheimes.de>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<47C9B6CB.1060909@cheimes.de>
Message-ID: <FF10524F-7E57-48E2-B2EA-7DF82E1F7FBC@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 3:04 PM, Christian Heimes wrote:

> I *never* sync changes from trunk Misc/NEWS to py3k Misc/NEWS. From my
> point of view it doesn't make sense to put Python 2.6 changes in the
> same section as Python 3.0 changes. Moving changes from to the right
> section would put a large and unnecessary burden on me. In general  
> every
> change of the 2.6 source tree makes it into 3.0. Exceptions to the  
> rule
> is stuff that makes no sense like 3.0 compatibility and warnings.
>
> Thumb rule: Changes, bug fixes and new features in 2.6 are also in 3.0
> except they are outruled by a Python 3.0 feature.
>
> Several people including me and Guido himself are watching the cvs
> lists. We make sure everybody adds an entry to Misc/NEWS whenever a  
> bug
> is fixed or a new feature is added. Otherwise we crack the whip ^H^H^H
> contact the committer. You can be sure that at least 98% of  all  
> closed
> bug reports, feature request and important changes have an entry in
> Misc/NEWS.

Great, this is all I'm really asking for!  The point of my  
unconscionable rant :) was that I think it's unfeasible to update the  
NEWS files at release time.  Knowing that you, Guido and others are  
keeping an eye on commits and an iron hand on the NEWS files makes me  
as the RM rest comfortably. :)

> So in general Misc/NEWS isn't an issue but Docs/whatsnew/ is. Only a
> couple of people - mostly Georg and Andrew - are updating the files.

I think it's okay if these lag behind during the alphas, but it would  
be good to start whipping these in shape by the time we start  
releasing betas.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8ncx3EjvBPtnXfVAQJeNQP+L2wK4CmGfwzgsQUHQISniaJ2rREBhJua
sJwqGNpBhnf6Uc8jJz+JRiexPdCW4AlH34FtHkyRkw2ZIVWwd6sO+7ixQPk0A/TP
+gGk1uST/sjPG3q8T5u9OElri5SoTqJzEgWMkTiGhwYouSvOjpW/GFFREySU68Tk
h9XGzJFZex0=
=aXqC
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Mar  1 23:49:42 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 01 Mar 2008 23:49:42 +0100
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>
	<fqciun$3l2$1@ger.gmane.org> <47C9D802.2090205@v.loewis.de>
	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>
Message-ID: <47C9DD86.4040300@v.loewis.de>

> Thanks for fixing these Martin!

I have now also uploaded signed MSI files for 3.0a3.

I have not tested them on a machine which doesn't have the
VS 2008 CRT installed (as all the machines I can access
right now do have it); please report what works and what
doesn't.

Regards,
Martin

From martin at v.loewis.de  Sat Mar  1 23:51:36 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 01 Mar 2008 23:51:36 +0100
Subject: [Python-3000] [Python-Dev]  RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <79990c6b0803011439n583bc2b2w5c544b620a91fa61@mail.gmail.com>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	
	<fqciun$3l2$1@ger.gmane.org> <47C9D802.2090205@v.loewis.de>
	<79990c6b0803011439n583bc2b2w5c544b620a91fa61@mail.gmail.com>
Message-ID: <47C9DDF8.30000@v.loewis.de>

> The 2.6a1 x86 MSI is there, but the 3.0a3 x86 MSI is still giving a 404.

Please try again - *those* files weren't actually there when I sent my
last message; I just built them.

Regards,
Martin

From barry at python.org  Sun Mar  2 00:03:35 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 1 Mar 2008 18:03:35 -0500
Subject: [Python-3000] The release process
In-Reply-To: <47C9DA91.9000105@v.loewis.de>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<47C9DA91.9000105@v.loewis.de>
Message-ID: <10EE358F-8120-4EAC-9413-BDE5B812639F@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 5:37 PM, Martin v. L?wis wrote:

>> With apologies to Anthony, welease is crack.  I made pretty good   
>> progress once I ditched it and starting doing things manually.    
>> Between now and the next alpha I intend to work on a command line   
>> script to help with releases.  If you're interested in helping, let  
>> me  know.
>
> I guess every release manager is free to come up with his own set of
> tools, but I feel you've given up too quickly (or started too late -
> perhaps a test release run a few days before the release would have
> helped).

Maybe.

> In any case, I'm willing to help with welease, but not with yet  
> another
> release tool. If you primarily complain about the GUIness of welease,
> I could help with a command line version of it.

The dependency on gtk is unnecessary and means it can effectively only  
be run on Linux.  Specifically it means I can't do releases on OS X.   
I don't see much benefit in having a gui tool for doing releases.

Some of the problems I had include having to run glade3 in order to  
update the menus which allow you to choose which release you were  
going to make.  It only new about py24 and 25 maintenance.  No knock  
on Anthony there, since those are the releases he had to make, but I  
shouldn't have to edit the interface description files to add new  
release versions.

Also, the scheme to compare IDLE versions seemed way off.  Maybe  
that's another thing that makes sense for py24 and py25 but it  
definitely didn't work for py30.

The much more serious problem, and where I stopped, is that welease  
broke on code containing the with statement.  I don't remember the  
details because at that point I was pretty tired and hadn't made any  
progress on the releases, but I /think/ the problem is that welease  
runs on a different version of Python than it's checking so it can't  
handle syntactic differences and such.

The kind of tool I think we need is a fairly straightforward command  
line tool, but one that would not just check that things are done, but  
also do them.  E.g. the tool would keep track of all the little places  
where version numbers and copyright years need updating.  The tool  
would actually make those changes, and using $EDITOR would show them  
to you for confirmation.  It would pause at steps that require  
coordination, such as when things need to be committed or signed, or  
when you're waiting from input from others.  It would have a dry-run  
mode and it would fairly closely follow PEP 101.

Anyway, that's the kind of tool I plan on building (or perhaps with  
help from others -- hi Benjamin) for the next alpha round.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8ngyHEjvBPtnXfVAQKYaAP+JzIj8HiwVYIJLMyxh+Glq57YQozOh2bB
XILPBwUyppBBkezcT6IWAnawo5YUGXwg1tJjS/OsqSnIoajnRQCzzR6X896qXUAn
asgXKTydmf553iSD03OG4K38UsdeD6uPUWN9zg/bceKaH2GM72p6md3Wepof4DuE
UdTGgXENXOI=
=uKmC
-----END PGP SIGNATURE-----

From skip at pobox.com  Sun Mar  2 01:28:07 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 1 Mar 2008 18:28:07 -0600
Subject: [Python-3000] [Python-Dev]  The release process
In-Reply-To: <10EE358F-8120-4EAC-9413-BDE5B812639F@python.org>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<47C9DA91.9000105@v.loewis.de>
	<10EE358F-8120-4EAC-9413-BDE5B812639F@python.org>
Message-ID: <18377.62615.194234.88761@montanaro-dyndns-org.local>


    Barry> The dependency on gtk is unnecessary and means it can effectively
    Barry> only be run on Linux.  Specifically it means I can't do releases
    Barry> on OS X.  I don't see much benefit in having a gui tool for doing
    Barry> releases.

Gtk and Glade are available through MacPorts, at least according to "port
search ...".

Skip

From aleaxit at gmail.com  Sun Mar  2 03:00:11 2008
From: aleaxit at gmail.com (Alex Martelli)
Date: Sat, 1 Mar 2008 18:00:11 -0800
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
	<3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>
Message-ID: <e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>

On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw <barry at python.org> wrote:
   ...
>  > I also propose translations of the shorter text to important languages
>  > like French, German, Japanese, Portuguese and Spanish. I'm willing to
>  > help with the German translation.
>
>  Cool, thanks.

I'd like to volunteer for Italian (and we, the Italian Python
community, do have reasonably good connections to the Italian
technical press, which is covering e.g. the upcoming Pycon Due
conference), and although my French is VERY rusty I can give it a try
if no native French speaker is forthcoming.


Alex

From hasan.diwan at gmail.com  Sun Mar  2 07:57:50 2008
From: hasan.diwan at gmail.com (Hasan Diwan)
Date: Sat, 1 Mar 2008 22:57:50 -0800
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <fqaq21$5ao$1@ger.gmane.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
Message-ID: <2cda2fc90803012257i3a63bd1etd176948ebc4ba048@mail.gmail.com>

I'll volunteer to do a French translation of the release.
-- 
Cheers,
Hasan Diwan <hasan.diwan at gmail.com>

From arnodel at googlemail.com  Sun Mar  2 09:58:34 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Sun, 2 Mar 2008 08:58:34 +0000
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
	<3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>
	<e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>
Message-ID: <827383A5-9EB5-4B02-94AB-E33D54481071@gmail.com>


On 2 Mar 2008, at 02:00, Alex Martelli wrote:

> On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw <barry at python.org>  
> wrote:
>   ...
>>> I also propose translations of the shorter text to important  
>>> languages
>>> like French, German, Japanese, Portuguese and Spanish. I'm willing  
>>> to
>>> help with the German translation.
>>
>> Cool, thanks.
>
> I'd like to volunteer for Italian (and we, the Italian Python
> community, do have reasonably good connections to the Italian
> technical press, which is covering e.g. the upcoming Pycon Due
> conference), and although my French is VERY rusty I can give it a try
> if no native French speaker is forthcoming.

I'm a native French speaker, and although I am not involved in  
Python's development I would be happy to help by translating the  
documents.  I have no connections with the French-speaking technical  
press.

-- 
Arnaud


From alexandre at peadrop.com  Mon Mar  3 02:56:57 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sun, 2 Mar 2008 20:56:57 -0500
Subject: [Python-3000] Silent failing unit tests.
Message-ID: <acd65fa20803021756w51a0db1bha7a05047b3346e44@mail.gmail.com>

Hi,

Since I got some free time during my study break, I started to work
again on my stuff. Hopefully, I finish off pickle. :-) Anyway, I found
weird while merging the py3k branch into my private branch. I found
some failing unit tests that don't report any failure when run with
regrtest:

test_pty
test_largefile
test_ossaudiodev [this one has been known to fail for while now]
test_pep247

There is probably others that I haven't noticed. You can try to find
other "silent" tests by watching the output of:

  % for t in Lib/test/test_*; do ./python $t; done

Cheers,
-- Alexandre

From brett at python.org  Mon Mar  3 03:33:00 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 2 Mar 2008 18:33:00 -0800
Subject: [Python-3000] Silent failing unit tests.
In-Reply-To: <acd65fa20803021756w51a0db1bha7a05047b3346e44@mail.gmail.com>
References: <acd65fa20803021756w51a0db1bha7a05047b3346e44@mail.gmail.com>
Message-ID: <bbaeab100803021833p44ebc3a4i4feba88d1c3883ad@mail.gmail.com>

On Sun, Mar 2, 2008 at 5:56 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Hi,
>
>  Since I got some free time during my study break, I started to work
>  again on my stuff. Hopefully, I finish off pickle. :-) Anyway, I found
>  weird while merging the py3k branch into my private branch. I found
>  some failing unit tests that don't report any failure when run with
>  regrtest:
>

On OS X 10.5:

>  test_pty

Failing.

>  test_largefile

Wasn't even executing tests! Must now that has been patched in r 61191
it is failing. =)

>  test_ossaudiodev [this one has been known to fail for while now]
>  test_pep247

Failing.

Don't know why regrtest is not picking up the failures.

-Brett

From brett at python.org  Mon Mar  3 04:28:28 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 2 Mar 2008 19:28:28 -0800
Subject: [Python-3000] Silent failing unit tests.
In-Reply-To: <bbaeab100803021833p44ebc3a4i4feba88d1c3883ad@mail.gmail.com>
References: <acd65fa20803021756w51a0db1bha7a05047b3346e44@mail.gmail.com>
	<bbaeab100803021833p44ebc3a4i4feba88d1c3883ad@mail.gmail.com>
Message-ID: <bbaeab100803021928y2bfcdcfcmb68b5a2bd804f08a@mail.gmail.com>

On Sun, Mar 2, 2008 at 6:33 PM, Brett Cannon <brett at python.org> wrote:
> On Sun, Mar 2, 2008 at 5:56 PM, Alexandre Vassalotti
>  <alexandre at peadrop.com> wrote:
>  > Hi,
>  >
>  >  Since I got some free time during my study break, I started to work
>  >  again on my stuff. Hopefully, I finish off pickle. :-) Anyway, I found
>  >  weird while merging the py3k branch into my private branch. I found
>  >  some failing unit tests that don't report any failure when run with
>  >  regrtest:
>  >
>
>  On OS X 10.5:
>
>  >  test_pty
>
>  Failing.
>
>  >  test_largefile
>
>  Wasn't even executing tests! Must now that has been patched in r 61191
>  it is failing. =)
>
>
>  >  test_ossaudiodev [this one has been known to fail for while now]
>  >  test_pep247
>
>  Failing.
>
>  Don't know why regrtest is not picking up the failures.

test_pty's failure was not showing up because it is was due to the
test consuming verbose output. When run under regrtest there is no
verbose output, so the offending code was never triggered.

test_pep247 was not triggering as it is not designed to execute in any
way other than a a main module. This has been fixed in r61195 in the
trunk so it can get forward-ported.

-Brett

From asmodai at in-nomine.org  Sun Mar  2 09:49:35 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sun, 2 Mar 2008 09:49:35 +0100
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <47C9A6DC.9070708@cheimes.de>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
Message-ID: <20080302084935.GA62047@nexus.in-nomine.org>

-On [20080301 19:57], Christian Heimes (lists at cheimes.de) wrote:
>I also propose translations of the shorter text to important languages
>like French, German, Japanese, Portuguese and Spanish. I'm willing to
>help with the German translation.

I can probably get a translation done in Japanese, Chinese and Korean.

For Portuguese I guess we could ask the ASync guys in Brazil, they're huge
Python users with their work for Canonical/Ubuntu.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
There can be no justice so long as laws are absolute...

From facundobatista at gmail.com  Mon Mar  3 18:03:06 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 3 Mar 2008 15:03:06 -0200
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <47C9A6DC.9070708@cheimes.de>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
Message-ID: <e04bdf310803030903t24716c22t55ee64668d292584@mail.gmail.com>

2008/3/1, Christian Heimes <lists at cheimes.de>:

>  I also propose translations of the shorter text to important languages
>  like French, German, Japanese, Portuguese and Spanish. I'm willing to
>  help with the German translation.

/me raises his hand while saying "Spanish, Spanish!".

Which is the official text?

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From barry at python.org  Mon Mar  3 23:43:57 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 3 Mar 2008 17:43:57 -0500
Subject: [Python-3000] [Python-Dev]  The release process
In-Reply-To: <18377.62615.194234.88761@montanaro-dyndns-org.local>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<47C9DA91.9000105@v.loewis.de>
	<10EE358F-8120-4EAC-9413-BDE5B812639F@python.org>
	<18377.62615.194234.88761@montanaro-dyndns-org.local>
Message-ID: <614DA72A-2900-4BA6-AA39-48B1E8C3CA98@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 7:28 PM, skip at pobox.com wrote:

>
>    Barry> The dependency on gtk is unnecessary and means it can  
> effectively
>    Barry> only be run on Linux.  Specifically it means I can't do  
> releases
>    Barry> on OS X.  I don't see much benefit in having a gui tool  
> for doing
>    Barry> releases.
>
> Gtk and Glade are available through MacPorts, at least according to  
> "port
> search ...".

True, but it's just more moving parts to break, especially when I  
don't really feel a u/i buys you much[*].

- -Barry

[*] Skip knows me as a diehard XEmacser so that statement can pretty  
much define my standard answer to all such questions. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8x/LXEjvBPtnXfVAQKnFAP/RDKzhQsIDuc8joSR3G2mrKv7jH+6tl04
Fq3d++1jFjE5cBiY9uDL2/799wqUKvevx2QnGrON1ins9xuYGh5/xY9w4JvbI8aX
zLq/RjNFzPl/YnMCX7OSUBjbQoE3sr+dgUpLurImsJxWaFcjqufzQuno6N0sqvWg
sevJTwfBkOE=
=HfWd
-----END PGP SIGNATURE-----

From barry at python.org  Mon Mar  3 23:53:08 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 3 Mar 2008 17:53:08 -0500
Subject: [Python-3000] [Python-Dev] The release process
In-Reply-To: <fqdiud$80b$1@ger.gmane.org>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<fqdiud$80b$1@ger.gmane.org>
Message-ID: <AF9C4630-AB72-47BB-926C-C11D4422C994@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 2, 2008, at 1:54 AM, Georg Brandl wrote:

> Barry Warsaw schrieb:
>
>> PEP 101 is sorely out of date, especially with regards to updating  
>> web
>> content and the Python documentation.  I think I now know how to
>> update the python.org web site, but the new Python documentation
>> format is still a mystery to me.  If someone would like to help  
>> update
>> PEP 101 for the documentation steps, please let me know.
>
> Well, it's not very hard to guess who this someone is, is it?

Actually, I honestly didn't know... sorry Georg!

> I've updated PEP 101, except for the part where the docs are uploaded
> to the website, I've no idea if the FTP paths etc. are still valid.

Thanks, this is a big help.  I'll double check the ftp paths, but I  
think they haven't changed.

> For the next releases, if you want to do documentation packages,
> please feel free to contact me, I'll be happy to help!

Great, thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8yBVHEjvBPtnXfVAQJemgP/aE/a54SaKc7Ls9osae+g57zcYB7d95FX
O/HcE3/QFJCQeBquTfwbOV8doyAYHFDDIw8U2GIvgppLjPEqHAJzKfBqeQIILM3a
uZM/4yUUcnnI8UQYhi4u+maztv6YwQxyKj9sLuK9GFncxk1B1z7zW4WcWISoet3H
j3XC4eFVvjM=
=SDdJ
-----END PGP SIGNATURE-----

From barry at python.org  Tue Mar  4 00:06:21 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 3 Mar 2008 18:06:21 -0500
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
	<3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>
	<e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>
Message-ID: <1D91070A-1387-4CFD-A6AC-0BA84626EE62@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 1, 2008, at 9:00 PM, Alex Martelli wrote:

> On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw <barry at python.org>  
> wrote:
>   ...
>>> I also propose translations of the shorter text to important  
>>> languages
>>> like French, German, Japanese, Portuguese and Spanish. I'm willing  
>>> to
>>> help with the German translation.
>>
>> Cool, thanks.
>
> I'd like to volunteer for Italian (and we, the Italian Python
> community, do have reasonably good connections to the Italian
> technical press, which is covering e.g. the upcoming Pycon Due
> conference), and although my French is VERY rusty I can give it a try
> if no native French speaker is forthcoming.

So how should we handle this?  Is it something you need input from me  
from, or can you just take my announcement, do the translations and  
post them to the appropriate forums?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8yEbXEjvBPtnXfVAQLU9QP/Tq3NsOHmKijNZQ2Gq8y4iLjznRAMS5ld
gkI+onjtjHO42pJ40p7UJMuUkp5V6+WzFSh1JqhxfyTLSYuMv90Jr+SKo8emtyg1
kJQjLfjtPu4JY/RIVhmbBD2IBIAchNBH2HWUjFY7Odp7TapuG78KRUFMsbt0GDP8
7XDl9xYXalg=
=w0Uo
-----END PGP SIGNATURE-----

From lists at cheimes.de  Tue Mar  4 01:41:58 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 04 Mar 2008 01:41:58 +0100
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <1D91070A-1387-4CFD-A6AC-0BA84626EE62@python.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
	<3B6D7A5F-2426-485E-BF5F-0BC16DF26A74@python.org>
	<e8a0972d0803011800v7c26035eh95a9371be21ed9b0@mail.gmail.com>
	<1D91070A-1387-4CFD-A6AC-0BA84626EE62@python.org>
Message-ID: <47CC9AD6.90504@cheimes.de>

Barry Warsaw wrote:
> So how should we handle this?  Is it something you need input from me
> from, or can you just take my announcement, do the translations and post
> them to the appropriate forums?

Your announcements are fine for Python's mailing lists and forums.
However I had a differnt target in mind, mainly large IT news sites with
broader audience. It'd be great if we can mobilize some professional PR
people to write an announcement for the press.

Christian

From skip at pobox.com  Tue Mar  4 04:30:48 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 3 Mar 2008 21:30:48 -0600
Subject: [Python-3000] [Python-Dev]  The release process
In-Reply-To: <614DA72A-2900-4BA6-AA39-48B1E8C3CA98@python.org>
References: <DE89A1CA-29D1-4A77-B427-F61ADF4C7CC8@python.org>
	<47C9DA91.9000105@v.loewis.de>
	<10EE358F-8120-4EAC-9413-BDE5B812639F@python.org>
	<18377.62615.194234.88761@montanaro-dyndns-org.local>
	<614DA72A-2900-4BA6-AA39-48B1E8C3CA98@python.org>
Message-ID: <18380.49768.250393.961583@montanaro-dyndns-org.local>


    Barry> True, but it's just more moving parts to break, especially when I
    Barry> don't really feel a u/i buys you much[*].

    Barry> [*] Skip knows me as a diehard XEmacser so that statement can
    Barry> pretty much define my standard answer to all such questions. :)

So if we put together a "gui" which uses Johan Vroman's defunct Emacs Lisp
forms package you'd be okay with that? <wink>

Skip

From rbp at isnomore.net  Wed Mar  5 01:01:04 2008
From: rbp at isnomore.net (Rodrigo Bernardo Pimentel)
Date: Tue, 4 Mar 2008 21:01:04 -0300
Subject: [Python-3000] [Python-Dev] No releases tonight
In-Reply-To: <20080302084935.GA62047@nexus.in-nomine.org>
References: <D7C34296-EB95-436E-AA17-DDD4EBCDFF22@python.org>
	<fqaq21$5ao$1@ger.gmane.org>
	<CDBAE1CD-9C0B-4ED1-8F67-0090516E1442@python.org>
	<47C9A6DC.9070708@cheimes.de>
	<20080302084935.GA62047@nexus.in-nomine.org>
Message-ID: <20080305000103.GA17165@isnomore.net>

On Sun, Mar 02 2008 at 05:49:35AM BRT, Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> wrote:
> -On [20080301 19:57], Christian Heimes (lists at cheimes.de) wrote:
> >I also propose translations of the shorter text to important languages
> >like French, German, Japanese, Portuguese and Spanish. I'm willing to
> >help with the German translation.
> 
> I can probably get a translation done in Japanese, Chinese and Korean.
> 
> For Portuguese I guess we could ask the ASync guys in Brazil, they're huge
> Python users with their work for Canonical/Ubuntu.

I could write the Portuguese translation.



        rbp

From faassen at startifact.com  Wed Mar  5 11:41:43 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 05 Mar 2008 11:41:43 +0100
Subject: [Python-3000] should Python 3's executable install as 'python'?
Message-ID: <fqltd8$ih0$1@ger.gmane.org>

Hi there,

This is quick feedback given my experiences installing Python 3 for the 
first time. Take it as that, please.

I just installed Python 3 into my local installation directory, and 
noticed it installs as 'python'. I already had a local Python 2.4 
installed which I am actively using, and its 'python' was overwritten. 
This is normal behavior for the installation process, but Python 3 not a 
usual release.

Since Python 3 is not directly compatible with Python 2, overwriting 
'python' might lead to some confusion: people may have legitimate 
expectations that their python code remains working when they use 
'python', and scripts may be referring to it using #!. I started with 
the expectation that it wouldn't change the behavior of 'python' in my 
sandbox, but that expectation was wrong. :)

So the question is whether Python 3 should install itself as 'python' as 
well as 'python3.0'. It may be that this question should be answered 
differently now than it will be in a few years, depending on the rate of 
Python 3's adoption. A Python 3.1 or 3.2 might then be installed as 
"python" straight away.

A quick search on the topic found a  discussion about this in '05 
without a conclusion, and the following text in PEP 3000:

"Naming

Python 3000, Python 3.0 and Py3K are all names for the same thing. The 
project is called Python 3000, or abbreviated to Py3k. The actual Python 
release will be referred to as Python 3.0, and that's what "python3.0 
-V" will print; the actual file names will use the same naming 
convention we use for Python 2.x. I don't want to pick a new name for 
the executable or change the suffix for Python source files."

I suspect that the PEP section I quoted already answers my question in 
the form of "no", but it seems to leave some leeway given that it refers 
to the executable as "python3.0" in its example. I understand the 
long-term reason for letting 'python' be Python 3.x: "python" should 
invoke the most recent version of Python installed. It may still not be 
the best strategy to do this in the short term however, as while people 
have such an expectation, they also tend to have the expectation that 
their code will continue to run.

Python distributors such as Linux distributions will have to determine 
what 'python' does on their system. Some may choose to invoke Python 
2.x, some may choose Python 3.x. It might useful for the Python team to 
give some guidance on this, if possible, to try to avoid inconsistent 
decisions to be taken.

It would be nice if the motivation for the decision could be added to 
the PEP so we don't have others bringing up the same topic. This might 
also be a useful place distributors of Python could get their clues as 
to policy, though perhaps a "distributor's guide" might be useful.

Regards,

Martijn


From p.f.moore at gmail.com  Wed Mar  5 12:28:22 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 5 Mar 2008 11:28:22 +0000
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <fqltd8$ih0$1@ger.gmane.org>
References: <fqltd8$ih0$1@ger.gmane.org>
Message-ID: <79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>

On 05/03/2008, Martijn Faassen <faassen at startifact.com> wrote:
> This is quick feedback given my experiences installing Python 3 for the
> first time. Take it as that, please.
[...]
> A quick search on the topic found a  discussion about this in '05
> without a conclusion, and the following text in PEP 3000:

There was a discussion on this list not long ago, under the title
"Namespaces are one honking great idea". You might want to look at
that. I don't recall any conclusion being reached, though.

As far as Unix is concerned, I have no direct interest, and so won't
comment. All I will say is that I expect Python 3 to install a
python.exe executable on Windows. I have no reason to believe that
this won't happen, and it's the current default. All I'm saying is
that whatever is decided to be appropriate on Unix shouldn't affect
Windows behaviour.

Paul.

From phd at phd.pp.ru  Wed Mar  5 12:31:02 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 5 Mar 2008 14:31:02 +0300
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
Message-ID: <20080305113102.GA10232@phd.pp.ru>

On Wed, Mar 05, 2008 at 11:28:22AM +0000, Paul Moore wrote:
> There was a discussion on this list not long ago, under the title
> "Namespaces are one honking great idea". You might want to look at
> that. I don't recall any conclusion being reached, though.

   AFAIR the conclusion was: use "make altinstall" instead of "make install".

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From ndbecker2 at gmail.com  Wed Mar  5 12:33:07 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 05 Mar 2008 06:33:07 -0500
Subject: [Python-3000] indexing wart
Message-ID: <fqm0dj$ssn$1@ger.gmane.org>

It is a bit unfortunate that slicing has a singularity.

samples_to_trim = (some calculation yielding an integer >= 0)


trimmed_vector = vector[:-samples_to_trim] if samples_to_trim != 0 else
vector[:]

A bit unfortunate that the case of samples_to_trim == 0 has to be handled
differently.

I don't really see any solution to this.




From faassen at startifact.com  Wed Mar  5 12:37:04 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 5 Mar 2008 12:37:04 +0100
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
Message-ID: <8928d4e90803050337u5ff861f0i430a5585fce1ccbb@mail.gmail.com>

Hey,

On Wed, Mar 5, 2008 at 12:28 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 05/03/2008, Martijn Faassen <faassen at startifact.com> wrote:
>  > This is quick feedback given my experiences installing Python 3 for the
>  > first time. Take it as that, please.
>  [...]
>  > A quick search on the topic found a  discussion about this in '05
>  > without a conclusion, and the following text in PEP 3000:
>
>  There was a discussion on this list not long ago, under the title
>  "Namespaces are one honking great idea". You might want to look at
>  that. I don't recall any conclusion being reached, though.

Ah, I missed that entirely! My apologies for bringing up a previous discussion.

Regards,

Martijn

From faassen at startifact.com  Wed Mar  5 12:42:39 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 05 Mar 2008 12:42:39 +0100
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <20080305113102.GA10232@phd.pp.ru>
References: <fqltd8$ih0$1@ger.gmane.org>	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
Message-ID: <fqm0vf$u4v$1@ger.gmane.org>

Oleg Broytmann wrote:
> On Wed, Mar 05, 2008 at 11:28:22AM +0000, Paul Moore wrote:
>> There was a discussion on this list not long ago, under the title
>> "Namespaces are one honking great idea". You might want to look at
>> that. I don't recall any conclusion being reached, though.
> 
>    AFAIR the conclusion was: use "make altinstall" instead of "make install".

Not that I actually *READ* the README file before installing, but there 
is only a single rather hint in the build instructions in README that 
altinstall exists, and it doesn't say what it does.

Regards,

Martijn




From phd at phd.pp.ru  Wed Mar  5 12:47:18 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 5 Mar 2008 14:47:18 +0300
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <fqm0vf$u4v$1@ger.gmane.org>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru> <fqm0vf$u4v$1@ger.gmane.org>
Message-ID: <20080305114718.GB10232@phd.pp.ru>

On Wed, Mar 05, 2008 at 12:42:39PM +0100, Martijn Faassen wrote:
> altinstall exists, and it doesn't say what it does.

   "make altinstall" installs everything including pythonX.Y binary. "make
install" does "make altinstall" and then hardlinks pythonX.Y to just
python. Running "make altinstall" without "make install" installs python
without the last step, so your previous python binary left intact, and you
new python binary is pythonX.Y.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From faassen at startifact.com  Wed Mar  5 12:54:12 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 05 Mar 2008 12:54:12 +0100
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <20080305114718.GB10232@phd.pp.ru>
References: <fqltd8$ih0$1@ger.gmane.org>	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>	<20080305113102.GA10232@phd.pp.ru>
	<fqm0vf$u4v$1@ger.gmane.org> <20080305114718.GB10232@phd.pp.ru>
Message-ID: <fqm1l4$11d$1@ger.gmane.org>

Oleg Broytmann wrote:
> On Wed, Mar 05, 2008 at 12:42:39PM +0100, Martijn Faassen wrote:
>> altinstall exists, and it doesn't say what it does.
> 
>    "make altinstall" installs everything including pythonX.Y binary. "make
> install" does "make altinstall" and then hardlinks pythonX.Y to just
> python. Running "make altinstall" without "make install" installs python
> without the last step, so your previous python binary left intact, and you
> new python binary is pythonX.Y.

Yes, I understood when you pointed it out the first time, given the 
context. I was suggesting you need text like that in README. You might 
want to add something like this:

"If you install Python 3.x on a system that already uses Python 2.x, we 
encourage you to use 'make altinstall'. Doing "make install" risks 
breaking existing scripts until they have been updated to work with 
Python 3.0."

Regards,

Martijn


From gustavo at niemeyer.net  Wed Mar  5 14:00:56 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Wed, 05 Mar 2008 10:00:56 -0300
Subject: [Python-3000] PEP 3102
In-Reply-To: <ca471dc20802141513i1f62c9d9mea4deb8d16f10b65@mail.gmail.com>
References: <20080214174812.AGY90177@ms19.lnh.mail.rcn.net>
	<ca471dc20802141513i1f62c9d9mea4deb8d16f10b65@mail.gmail.com>
Message-ID: <47CE9988.20605@niemeyer.net>


> Agreed. Now can you come up with a syntax for positional-only
> arguments? So far everybody has failed at that, and there are some use
> cases where it's useful too.

I guess it might be too late, but has anyone considered:

def func(normal_arg, *, positional_arg, **, keyword_arg):
    pass

-- 
Gustavo Niemeyer
http://niemeyer.net

From gustavo at niemeyer.net  Wed Mar  5 14:06:22 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Wed, 05 Mar 2008 10:06:22 -0300
Subject: [Python-3000] PEP 3102
In-Reply-To: <47CE9988.20605@niemeyer.net>
References: <20080214174812.AGY90177@ms19.lnh.mail.rcn.net>
	<ca471dc20802141513i1f62c9d9mea4deb8d16f10b65@mail.gmail.com>
	<47CE9988.20605@niemeyer.net>
Message-ID: <47CE9ACE.1050100@niemeyer.net>


> I guess it might be too late, but has anyone considered:
> 
> def func(normal_arg, *, positional_arg, **, keyword_arg):
>     pass

Or even that, since it's meaningless to have a positional argument in the
middle:

def func(positional_arg, *, normal_arg, **, keyword_arg):
    pass

-- 
Gustavo Niemeyer
http://niemeyer.net

From skip at pobox.com  Wed Mar  5 14:30:41 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 5 Mar 2008 07:30:41 -0600
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <fqm1l4$11d$1@ger.gmane.org>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru> <fqm0vf$u4v$1@ger.gmane.org>
	<20080305114718.GB10232@phd.pp.ru> <fqm1l4$11d$1@ger.gmane.org>
Message-ID: <18382.41089.546853.464296@montanaro-dyndns-org.local>


    Martijn> "If you install Python 3.x on a system that already uses Python
    Martijn> 2.x, we encourage you to use 'make altinstall'. Doing "make
    Martijn> install" risks breaking existing scripts until they have been
    Martijn> updated to work with Python 3.0."

Of course the same holds true for people who install multiple minor
revisions of Python 2.x.  The README files on both trunk and the py3k branch
need updating.  If I get a chance today and nobody beats me to it I will
modify it with something like Oleg's wording.

Skip

From murman at gmail.com  Wed Mar  5 15:16:11 2008
From: murman at gmail.com (Michael Urman)
Date: Wed, 5 Mar 2008 08:16:11 -0600
Subject: [Python-3000] indexing wart
In-Reply-To: <fqm0dj$ssn$1@ger.gmane.org>
References: <fqm0dj$ssn$1@ger.gmane.org>
Message-ID: <dcbbbb410803050616t2a1522b7sf3dff51c8449b9c0@mail.gmail.com>

On Wed, Mar 5, 2008 at 5:33 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> It is a bit unfortunate that slicing has a singularity.
>
> samples_to_trim = (some calculation yielding an integer >= 0)
>
>
> trimmed_vector = vector[:-samples_to_trim] if samples_to_trim != 0 else
> vector[:]
>
> A bit unfortunate that the case of samples_to_trim == 0 has to be handled
> differently.
>
> I don't really see any solution to this.

Just transform the problem away. If you can guarantee that
samples_to_trim is <= len(vector), then it's trivial:
trimmed_vector = vector[:len(vector) - samples_to_trim]

If not, it gets more complicated, but you can wrap the upper bound in
a max(0, ...).

-- 
Michael Urman

From guido at python.org  Wed Mar  5 18:39:16 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Mar 2008 09:39:16 -0800
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <20080305113102.GA10232@phd.pp.ru>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
Message-ID: <ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>

On Wed, Mar 5, 2008 at 3:31 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> On Wed, Mar 05, 2008 at 11:28:22AM +0000, Paul Moore wrote:
>  > There was a discussion on this list not long ago, under the title
>  > "Namespaces are one honking great idea". You might want to look at
>  > that. I don't recall any conclusion being reached, though.
>
>    AFAIR the conclusion was: use "make altinstall" instead of "make install".

Actually I believe the conclusion was that "make install" should be
have like "make altinstall". Now that I think about it I believe there
should be *no* way to install it as just "python" -- that's just
encouraging people to do something dumb.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From skip at pobox.com  Wed Mar  5 19:11:50 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 5 Mar 2008 12:11:50 -0600
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
Message-ID: <18382.57958.331087.10882@montanaro-dyndns-org.local>


    Guido> Actually I believe the conclusion was that "make install" should
    Guido> be have like "make altinstall". Now that I think about it I
    Guido> believe there should be *no* way to install it as just "python"
    Guido> -- that's just encouraging people to do something dumb.

Well, whoever updates the Makefile will need to update the README file as
well.  I checked in a change earlier describing how to properly install
multiple versions using the altinstall target.

If, in the future, the install target does what the altinstall target does
today, what should the target that does what the install target does today?

    (???, install) = (install, altinstall)

Skip


From guido at python.org  Wed Mar  5 19:19:16 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Mar 2008 10:19:16 -0800
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <18382.57958.331087.10882@montanaro-dyndns-org.local>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
Message-ID: <ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>

On Wed, Mar 5, 2008 at 10:11 AM,  <skip at pobox.com> wrote:
>
>     Guido> Actually I believe the conclusion was that "make install" should
>     Guido> be have like "make altinstall". Now that I think about it I
>     Guido> believe there should be *no* way to install it as just "python"
>     Guido> -- that's just encouraging people to do something dumb.
>
>  Well, whoever updates the Makefile will need to update the README file as
>  well.  I checked in a change earlier describing how to properly install
>  multiple versions using the altinstall target.
>
>  If, in the future, the install target does what the altinstall target does
>  today, what should the target that does what the install target does today?
>
>     (???, install) = (install, altinstall)

I guess I wasn't clear -- I don't want there to be a target that does
what install does today. It would be a mistake to use it in 99.99% of
cases. IOW

  install = altinstall

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From skip at pobox.com  Wed Mar  5 19:30:23 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 5 Mar 2008 12:30:23 -0600
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <18382.57958.331087.10882@montanaro-dyndns-org.local>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
Message-ID: <18382.59071.112078.109268@montanaro-dyndns-org.local>


yikes!

    skip> If, in the future, the install target does what the altinstall target does
    skip> today, what should the target that does what the install target does today?

    skip>     (???, install) = (install, altinstall)

Let me try this again.  If, in the future, the install target does what the
altinstall target does today, what should we call the target that does what
the install target does today?

Skip

From phd at phd.pp.ru  Wed Mar  5 20:13:46 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 5 Mar 2008 22:13:46 +0300
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
Message-ID: <20080305191346.GA23170@phd.pp.ru>

On Wed, Mar 05, 2008 at 09:39:16AM -0800, Guido van Rossum wrote:
> Actually I believe the conclusion was that "make install" should be
> have like "make altinstall". Now that I think about it I believe there
> should be *no* way to install it as just "python" -- that's just
> encouraging people to do something dumb.

install: altinstall
   echo "Your python is now $(INSTALLPATH)/python$(MAJOR).$(MINOR)"

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From phd at phd.pp.ru  Wed Mar  5 20:18:43 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 5 Mar 2008 22:18:43 +0300
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <18382.57958.331087.10882@montanaro-dyndns-org.local>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
Message-ID: <20080305191843.GB23170@phd.pp.ru>

On Wed, Mar 05, 2008 at 12:11:50PM -0600, skip at pobox.com wrote:
>     Guido> Actually I believe the conclusion was that "make install" should
>     Guido> be have like "make altinstall". Now that I think about it I
>     Guido> believe there should be *no* way to install it as just "python"
>     Guido> -- that's just encouraging people to do something dumb.
> 
> Well, whoever updates the Makefile will need to update the README file as
> well.  I checked in a change earlier describing how to properly install
> multiple versions using the altinstall target.
> 
> If, in the future, the install target does what the altinstall target does
> today, what should the target that does what the install target does today?
> 
>     (???, install) = (install, altinstall)

   forceinstall? dangerous-install? damaging-install? (half-wink ;)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From ncoghlan at gmail.com  Wed Mar  5 22:40:39 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 06 Mar 2008 07:40:39 +1000
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>	<20080305113102.GA10232@phd.pp.ru>	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
Message-ID: <47CF1357.5040808@gmail.com>

Guido van Rossum wrote:
> I guess I wasn't clear -- I don't want there to be a target that does
> what install does today. It would be a mistake to use it in 99.99% of
> cases. IOW
> 
>   install = altinstall

Leaving it up to packagers for the different distributions to decide if 
they want to add the 'python' symlink? That sounds reasonable to me.

Does this apply to 2.6 as well, or just 3.0?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Wed Mar  5 23:12:45 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Mar 2008 14:12:45 -0800
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <47CF1357.5040808@gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
	<47CF1357.5040808@gmail.com>
Message-ID: <ca471dc20803051412j58144e2fi6f9ec3b00a90feab@mail.gmail.com>

On Wed, Mar 5, 2008 at 1:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
>  > I guess I wasn't clear -- I don't want there to be a target that does
>  > what install does today. It would be a mistake to use it in 99.99% of
>  > cases. IOW
>  >
>  >   install = altinstall
>
>  Leaving it up to packagers for the different distributions to decide if
>  they want to add the 'python' symlink? That sounds reasonable to me.
>
>  Does this apply to 2.6 as well, or just 3.0?

Only 3.0.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Wed Mar  5 23:30:49 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 06 Mar 2008 11:30:49 +1300
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <20080305191843.GB23170@phd.pp.ru>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<20080305191843.GB23170@phd.pp.ru>
Message-ID: <47CF1F19.4030204@canterbury.ac.nz>

Oleg Broytmann wrote:
>    forceinstall? dangerous-install? damaging-install? (half-wink ;)

burnmybridgesinstall

-- 
Greg

From skip at pobox.com  Wed Mar  5 23:31:48 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 5 Mar 2008 16:31:48 -0600
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
Message-ID: <18383.8020.234900.192145@montanaro-dyndns-org.local>


    Guido> I guess I wasn't clear -- I don't want there to be a target that
    Guido> does what install does today. It would be a mistake to use it in
    Guido> 99.99% of cases. IOW

    Guido>   install = altinstall

The install target does three things (ignoring Mac framework installs):

    altinstall
    bininstall
    maninstall

The altinstall target is version-specific, so it's fine.  The bininstall and
maninstall targets create files which are not obviously tied to a specific
version though.  Their actions are complex enough that most people are not
going to want to do them manually though.  I still think it worthwhile to
have *some* target in the Makefile which depends on altinstall and does the
bininstall and maninstall steps.  Something like "makeprimary"?  I don't
know.  You still need some way to record all the steps necessary to make
what you're installing "right now" be considered "python".

Skip
 

From guido at python.org  Thu Mar  6 00:23:13 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Mar 2008 15:23:13 -0800
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <18383.8020.234900.192145@montanaro-dyndns-org.local>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
	<18383.8020.234900.192145@montanaro-dyndns-org.local>
Message-ID: <ca471dc20803051523w172500cdn4865a2d70479422f@mail.gmail.com>

On Wed, Mar 5, 2008 at 2:31 PM,  <skip at pobox.com> wrote:
>
>     Guido> I guess I wasn't clear -- I don't want there to be a target that
>     Guido> does what install does today. It would be a mistake to use it in
>     Guido> 99.99% of cases. IOW
>
>     Guido>   install = altinstall
>
>  The install target does three things (ignoring Mac framework installs):
>
>     altinstall
>     bininstall
>     maninstall
>
>  The altinstall target is version-specific, so it's fine.  The bininstall and
>  maninstall targets create files which are not obviously tied to a specific
>  version though.  Their actions are complex enough that most people are not
>  going to want to do them manually though.  I still think it worthwhile to
>  have *some* target in the Makefile which depends on altinstall and does the
>  bininstall and maninstall steps.  Something like "makeprimary"?  I don't
>  know.  You still need some way to record all the steps necessary to make
>  what you're installing "right now" be considered "python".

Let them type "make altinstall bininstall maninstall".

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From stephen at xemacs.org  Thu Mar  6 01:33:21 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 06 Mar 2008 09:33:21 +0900
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <18383.8020.234900.192145@montanaro-dyndns-org.local>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
	<18383.8020.234900.192145@montanaro-dyndns-org.local>
Message-ID: <87k5kgvgha.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:

 > I still think it worthwhile to have *some* target in the Makefile
 > which depends on altinstall and does the bininstall and maninstall
 > steps.  Something like "makeprimary"?

How about "install-as-python" or "install-as-default"?


From jek-gmane at kleckner.net  Fri Mar  7 00:41:33 2008
From: jek-gmane at kleckner.net (Jim Kleckner)
Date: Thu, 06 Mar 2008 15:41:33 -0800
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <47C9DD86.4040300@v.loewis.de>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	<fqciun$3l2$1@ger.gmane.org>
	<47C9D802.2090205@v.loewis.de>	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>
	<47C9DD86.4040300@v.loewis.de>
Message-ID: <fqpvff$lg2$1@ger.gmane.org>

Martin v. L?wis wrote:
>> Thanks for fixing these Martin!
> 
> I have now also uploaded signed MSI files for 3.0a3.
> 
> I have not tested them on a machine which doesn't have the
> VS 2008 CRT installed (as all the machines I can access
> right now do have it); please report what works and what
> doesn't.

When I install 2.6a1 onto a Windoze machine without any previous 
install, I get a dialog:
  There is a problem with this Windows Installer package.
  A program run as part of the setup did not finish as expected.
  Contact your support personnel or package vendor.

Note that it didn't have VS2008 or any other new code installed.

When running the Python console, running
  import Tkinter

results in an error saying that _tkinter can't be loaded.
  DLL load failed.  The system can't find _tkinter.pyd

_tkinter.pyd and tcl84.dll and tk84.dll are in DLLs and
appear to have reasonable permissions.

I suspect something in the install failed to set something
in the registry.  Is there any log file of the install
to inspect?


From martin at v.loewis.de  Fri Mar  7 01:03:15 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 07 Mar 2008 01:03:15 +0100
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <fqpvff$lg2$1@ger.gmane.org>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	<fqciun$3l2$1@ger.gmane.org>	<47C9D802.2090205@v.loewis.de>	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>	<47C9DD86.4040300@v.loewis.de>
	<fqpvff$lg2$1@ger.gmane.org>
Message-ID: <47D08643.50207@v.loewis.de>

> I suspect something in the install failed to set something
> in the registry.  Is there any log file of the install
> to inspect?

You need to run

msiexec /i <msifile> /l*v <logfile>

to generate a logfile for the installation.

Regards,
Martin

From jek-gmane at kleckner.net  Fri Mar  7 00:56:24 2008
From: jek-gmane at kleckner.net (Jim Kleckner)
Date: Thu, 06 Mar 2008 15:56:24 -0800
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <fqpvff$lg2$1@ger.gmane.org>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	<fqciun$3l2$1@ger.gmane.org>	<47C9D802.2090205@v.loewis.de>	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>	<47C9DD86.4040300@v.loewis.de>
	<fqpvff$lg2$1@ger.gmane.org>
Message-ID: <fqq0bb$nnp$1@ger.gmane.org>

Jim Kleckner wrote:
> Martin v. L?wis wrote:
>>> Thanks for fixing these Martin!
>> I have now also uploaded signed MSI files for 3.0a3.
>>
>> I have not tested them on a machine which doesn't have the
>> VS 2008 CRT installed (as all the machines I can access
>> right now do have it); please report what works and what
>> doesn't.
> 
> When I install 2.6a1 onto a Windoze machine without any previous 
> install, I get a dialog:
>   There is a problem with this Windows Installer package.
>   A program run as part of the setup did not finish as expected.
>   Contact your support personnel or package vendor.
> 
> Note that it didn't have VS2008 or any other new code installed.
> 
> When running the Python console, running
>   import Tkinter
> 
> results in an error saying that _tkinter can't be loaded.
>   DLL load failed.  The system can't find _tkinter.pyd
> 
> _tkinter.pyd and tcl84.dll and tk84.dll are in DLLs and
> appear to have reasonable permissions.
> 
> I suspect something in the install failed to set something
> in the registry.  Is there any log file of the install
> to inspect?

I forgot to mention that this is on a current-patch XP
system and that I also tried python-2.6.13944.msi
from the buildbot just in case after uninstalling/reinstalling.



From jek-gmane at kleckner.net  Fri Mar  7 01:56:09 2008
From: jek-gmane at kleckner.net (Jim Kleckner)
Date: Thu, 06 Mar 2008 16:56:09 -0800
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <47D08643.50207@v.loewis.de>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	<fqciun$3l2$1@ger.gmane.org>	<47C9D802.2090205@v.loewis.de>	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>	<47C9DD86.4040300@v.loewis.de>	<fqpvff$lg2$1@ger.gmane.org>
	<47D08643.50207@v.loewis.de>
Message-ID: <fqq3ra$202$1@ger.gmane.org>

Martin v. L?wis wrote:
>> I suspect something in the install failed to set something
>> in the registry.  Is there any log file of the install
>> to inspect?
> 
> You need to run
> 
> msiexec /i <msifile> /l*v <logfile>
> 
> to generate a logfile for the installation.

Ok, I have the 3MB log file.  Should I upload it
somewhere or is there a pattern to find?

Perhaps this "PROPERTY CHANGE: Deleting SECONDSEQUENCE" ?


Property(S): Privileged = 1
Property(S): DATABASE = C:\WINDOWS\Installer\5f5ad0.msi
Property(S): OriginalDatabase = C:\cygwin\tmp\python-2.6a1.msi
Property(S): UILevel = 5
Property(S): Preselected = 1
Property(S): CostingComplete = 1
Property(S): OutOfDiskSpace = 0
Property(S): OutOfNoRbDiskSpace = 0
Property(S): PrimaryVolumeSpaceAvailable = 0
Property(S): PrimaryVolumeSpaceRequired = 0
Property(S): PrimaryVolumeSpaceRemaining = 0
Property(S): SOURCEDIR = C:\cygwin\tmp\
Property(S): SourcedirProduct = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(S): ProductToBeRegistered = 1
MSI (s) (FC:D0) [16:38:30:939]: MainEngineThread is returning 1603
MSI (s) (FC:C0) [16:38:30:939]: Destroying RemoteAPI object.
MSI (s) (FC:54) [16:38:30:939]: Custom Action Manager thread ending.
MSI (c) (E0:54) [16:38:30:954]: Back from server. Return value: 1603
MSI (c) (E0:54) [16:38:30:954]: Decrementing counter to disable 
shutdown. If counter >= 0, shutdown will be denied.  Counter after 
decrement: -1
MSI (c) (E0:54) [16:38:30:954]: PROPERTY CHANGE: Deleting SECONDSEQUENCE 
property. Its current value is '1'.
Action ended 16:38:30: ExecuteAction. Return value 3.
MSI (c) (E0:54) [16:38:30:954]: Doing action: FatalError
Action 16:38:30: FatalError.
Action start 16:38:30: FatalError.
Action 16:38:30: FatalError. Dialog created
Action ended 16:38:32: FatalError. Return value 2.
Action ended 16:38:32: INSTALL. Return value 3.
MSI (c) (E0:54) [16:38:32:375]: Destroying RemoteAPI object.
MSI (c) (E0:2C) [16:38:32:375]: Custom Action Manager thread ending.
Property(C): X = C:\Python26\Tools\pynche\X\
Property(C): UpgradeCode = {65E6DE48-A358-434D-AA4F-4AF72DB4718F}
Property(C): ProductName = Python 2.6a1
Property(C): ProductCode = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(C): ProductVersion = 2.6.101
Property(C): Manufacturer = Python Software Foundation


From artomegus at gmail.com  Fri Mar  7 04:43:53 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Thu, 6 Mar 2008 22:43:53 -0500
Subject: [Python-3000] The case for unbound methods?
Message-ID: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>

Exhibit A, wraptest.py (demonstrates using a wrapper to insert an
extra argument into method calls):

------------------------------------------------------------

import sys

if sys.version_info[0] < 3:
    _self_attr = 'im_self'
else:
    _self_attr = '__self__'

class methodwrapper(object):
    def __init__(self, descriptor, callable=None):
        self.descriptor = descriptor
        self.callable = callable

    def __get__(self, obj, type=None):
        if self.callable is not None:
            return self
        return methodwrapper(self.descriptor,
                             self.descriptor.__get__(obj, type))

    def __call__(self, *args, **kwargs):
        if self.callable is None:
            raise TypeError('wrapper called before __get__')
        try:
            obj = getattr(self.callable, _self_attr)
        except AttributeError:
            # must be a function
            return self.callable.__call__('inserted',
                                          *args,
                                          **kwargs)
        if obj is None:
            # must be an unbound method
            if not args:
                raise TypeError('instance argument missing')
            return self.callable.__call__(args[0],
                                          'inserted',
                                          *args[1:],
                                          **kwargs)
        # must be a bound method
        return self.callable.__call__('inserted',
                                      *args,
                                      **kwargs)

if __name__ == '__main__':
    class A(object):
        @methodwrapper
        @staticmethod
        def s(inserted):
            return inserted

        @methodwrapper
        @classmethod
        def c(cls, inserted):
            return inserted

        @methodwrapper
        def i(self, inserted):
            return inserted

    a = A()
    assert a.s() == 'inserted'     # instance binding - static method
    assert a.c() == 'inserted'     # instance binding - class method
    assert a.i() == 'inserted'     # instance binding - instance method
    assert A.s() == 'inserted'     # class binding - static method
    assert A.c() == 'inserted'     # class binding - class method
    assert A.i(a) == 'inserted'    # class binding - instance method

------------------------------------------------------------
Exhibit B:

Run wraptest.py in Python 2.5, and all assertions pass.

However, run it in Python 3.0, and witness:

Traceback (most recent call last):
  File "wraptest.py", line 64, in <module>
    assert A.i(a) == 'inserted'    # class binding - instance method
AssertionError

------------------------------------------------------------
Summary:

There is a subtle difference between an unbound method and a function.
 Generally, one can assume that the underlying function of an unbound
method will expect an instance as the first argument, but this is not
the case for plain functions.  Here's why:

1) The staticmethod descriptor always returns a function, to which no
arguments are passed implicitly.

2) The classmethod descriptor always returns a bound method, which
implicitly passes an instance (the class) as the first argument to the
underlying function.

3) That leaves regular instance methods.  In version 2.5, the
descriptor will return either a bound method (in which the instance
argument is passed implicitly), or an unbound method (in which an
instance argument must be passed explicitly), depending on the binding
used: instance binding or class binding, respectively.  Either way,
the underlying function will expect an instance as the first argument.

Here is a table of combinations for Python 2.5, using wraptest.py as
the template:

a.s -> staticmethod descriptor -> function (no im_self attribute)
a.c -> classmethod descriptor -> bound method (im_self = A)
a.i -> function descriptor -> bound method (im_self = a)

A.s -> staticmethod descriptor -> function (no im_self attribute)
A.c -> classmethod descriptor -> bound method (im_self = A)
A.i -> function descriptor -> unbound method (im_self = None)

If you are creating a custom descriptor that needs to wrap static
methods, class methods, and instance methods, one can determine the
difference between instance binding and class binding for instance
methods by whether the descriptor returns a bound method or an unbound
method.

However, in 3.0, unbound methods have been done away with, and the
situation is as follows:

a.s -> staticmethod descriptor -> function (no __self__ attribute)
a.c -> classmethod descriptor -> bound method (__self__ = A)
a.i -> function descriptor -> bound method (__self__ = a)

A.s -> staticmethod descriptor -> function (no __self__ attribute)
A.c -> classmethod descriptor -> bound method (__self__ = A)
A.i -> function descriptor -> **function!** (no __self__ attribute)

As such, if the wrapper receives a function from the descriptor, how
does it know if it is a static method, which doesn't need an instance
argument, or an instance method with class binding, which does?

OK, I suppose that that the code *could* check if the descriptor is an
instance of staticmethod or classmethod.  However, this is slower than
the duck typing used in the example code, assuming that a majority of
methods are plain instance methods.  And, by using duck typing, the
class can wrap other descriptors that might mimic classmethod or
staticmethod.  The code above could even be extended to do just that,
by mimicking the behavior of the underlying descriptor (essentially
masking its presence).   That way, several wrappers could be chained
together, without having to check the type of the descriptor.

Another solution would be to create two separate wrappers: one for
static methods, and one for class methods and instance methods.
However, this seems clumsy, since it isn't even necessary in 2.5.

Have I made a case for the existence of unbound methods?  I don't
know.  I'll be the first to admit that I may have missed something
vitally important in my analysis.  Perhaps there is a new way of doing
things in 3.0 to which I should strive.  Or, perhaps I am too hung up
on creating a "universal" method wrapper.

Anyway, those are my thoughts on the subject.  Thanks for your time,

Anthony Tolle

From guido at python.org  Fri Mar  7 05:59:54 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 6 Mar 2008 20:59:54 -0800
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
Message-ID: <ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>

Would you mind giving an "executive summary" of your argument that
doesn't require scanning 40 lines of code?

On Thu, Mar 6, 2008 at 7:43 PM, Anthony Tolle <artomegus at gmail.com> wrote:
> Exhibit A, wraptest.py (demonstrates using a wrapper to insert an
>  extra argument into method calls):
>
>  ------------------------------------------------------------
>
>  import sys
>
>  if sys.version_info[0] < 3:
>     _self_attr = 'im_self'
>  else:
>     _self_attr = '__self__'
>
>  class methodwrapper(object):
>     def __init__(self, descriptor, callable=None):
>         self.descriptor = descriptor
>         self.callable = callable
>
>     def __get__(self, obj, type=None):
>         if self.callable is not None:
>             return self
>         return methodwrapper(self.descriptor,
>                              self.descriptor.__get__(obj, type))
>
>     def __call__(self, *args, **kwargs):
>         if self.callable is None:
>             raise TypeError('wrapper called before __get__')
>         try:
>             obj = getattr(self.callable, _self_attr)
>         except AttributeError:
>             # must be a function
>             return self.callable.__call__('inserted',
>                                           *args,
>                                           **kwargs)
>         if obj is None:
>             # must be an unbound method
>             if not args:
>                 raise TypeError('instance argument missing')
>             return self.callable.__call__(args[0],
>                                           'inserted',
>                                           *args[1:],
>                                           **kwargs)
>         # must be a bound method
>         return self.callable.__call__('inserted',
>                                       *args,
>                                       **kwargs)
>
>  if __name__ == '__main__':
>     class A(object):
>         @methodwrapper
>         @staticmethod
>         def s(inserted):
>             return inserted
>
>         @methodwrapper
>         @classmethod
>         def c(cls, inserted):
>             return inserted
>
>         @methodwrapper
>         def i(self, inserted):
>             return inserted
>
>     a = A()
>     assert a.s() == 'inserted'     # instance binding - static method
>     assert a.c() == 'inserted'     # instance binding - class method
>     assert a.i() == 'inserted'     # instance binding - instance method
>     assert A.s() == 'inserted'     # class binding - static method
>     assert A.c() == 'inserted'     # class binding - class method
>     assert A.i(a) == 'inserted'    # class binding - instance method
>
>  ------------------------------------------------------------
>  Exhibit B:
>
>  Run wraptest.py in Python 2.5, and all assertions pass.
>
>  However, run it in Python 3.0, and witness:
>
>  Traceback (most recent call last):
>   File "wraptest.py", line 64, in <module>
>     assert A.i(a) == 'inserted'    # class binding - instance method
>  AssertionError
>
>  ------------------------------------------------------------
>  Summary:
>
>  There is a subtle difference between an unbound method and a function.
>   Generally, one can assume that the underlying function of an unbound
>  method will expect an instance as the first argument, but this is not
>  the case for plain functions.  Here's why:
>
>  1) The staticmethod descriptor always returns a function, to which no
>  arguments are passed implicitly.
>
>  2) The classmethod descriptor always returns a bound method, which
>  implicitly passes an instance (the class) as the first argument to the
>  underlying function.
>
>  3) That leaves regular instance methods.  In version 2.5, the
>  descriptor will return either a bound method (in which the instance
>  argument is passed implicitly), or an unbound method (in which an
>  instance argument must be passed explicitly), depending on the binding
>  used: instance binding or class binding, respectively.  Either way,
>  the underlying function will expect an instance as the first argument.
>
>  Here is a table of combinations for Python 2.5, using wraptest.py as
>  the template:
>
>  a.s -> staticmethod descriptor -> function (no im_self attribute)
>  a.c -> classmethod descriptor -> bound method (im_self = A)
>  a.i -> function descriptor -> bound method (im_self = a)
>
>  A.s -> staticmethod descriptor -> function (no im_self attribute)
>  A.c -> classmethod descriptor -> bound method (im_self = A)
>  A.i -> function descriptor -> unbound method (im_self = None)
>
>  If you are creating a custom descriptor that needs to wrap static
>  methods, class methods, and instance methods, one can determine the
>  difference between instance binding and class binding for instance
>  methods by whether the descriptor returns a bound method or an unbound
>  method.
>
>  However, in 3.0, unbound methods have been done away with, and the
>  situation is as follows:
>
>  a.s -> staticmethod descriptor -> function (no __self__ attribute)
>  a.c -> classmethod descriptor -> bound method (__self__ = A)
>  a.i -> function descriptor -> bound method (__self__ = a)
>
>  A.s -> staticmethod descriptor -> function (no __self__ attribute)
>  A.c -> classmethod descriptor -> bound method (__self__ = A)
>  A.i -> function descriptor -> **function!** (no __self__ attribute)
>
>  As such, if the wrapper receives a function from the descriptor, how
>  does it know if it is a static method, which doesn't need an instance
>  argument, or an instance method with class binding, which does?
>
>  OK, I suppose that that the code *could* check if the descriptor is an
>  instance of staticmethod or classmethod.  However, this is slower than
>  the duck typing used in the example code, assuming that a majority of
>  methods are plain instance methods.  And, by using duck typing, the
>  class can wrap other descriptors that might mimic classmethod or
>  staticmethod.  The code above could even be extended to do just that,
>  by mimicking the behavior of the underlying descriptor (essentially
>  masking its presence).   That way, several wrappers could be chained
>  together, without having to check the type of the descriptor.
>
>  Another solution would be to create two separate wrappers: one for
>  static methods, and one for class methods and instance methods.
>  However, this seems clumsy, since it isn't even necessary in 2.5.
>
>  Have I made a case for the existence of unbound methods?  I don't
>  know.  I'll be the first to admit that I may have missed something
>  vitally important in my analysis.  Perhaps there is a new way of doing
>  things in 3.0 to which I should strive.  Or, perhaps I am too hung up
>  on creating a "universal" method wrapper.
>
>  Anyway, those are my thoughts on the subject.  Thanks for your time,
>
>  Anthony Tolle
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Fri Mar  7 07:30:21 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 07 Mar 2008 19:30:21 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
Message-ID: <47D0E0FD.5080808@canterbury.ac.nz>

Anthony Tolle wrote:

> Have I made a case for the existence of unbound methods?

Not very well, IMO.

Without seeing a concrete use case, it's hard to be
sure, but my feeling is that there's almost certainly
a better way of thinking about the problem you're
trying to solve -- one that doesn't require introspecting
on a callable object to find out whether its implementation
involves a 'self' argument. That's *not* duck typing,
it's look-inside-before-you-leap.

-- 
Greg

From martin at v.loewis.de  Fri Mar  7 07:40:50 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 07 Mar 2008 07:40:50 +0100
Subject: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
In-Reply-To: <fqq3ra$202$1@ger.gmane.org>
References: <6E72CEB8-D3BF-4440-A1EA-1A3D545CC8DB@python.org>	<fqciun$3l2$1@ger.gmane.org>	<47C9D802.2090205@v.loewis.de>	<05D00F06-8B87-4B94-8878-42E1F3F50F90@python.org>	<47C9DD86.4040300@v.loewis.de>	<fqpvff$lg2$1@ger.gmane.org>	<47D08643.50207@v.loewis.de>
	<fqq3ra$202$1@ger.gmane.org>
Message-ID: <47D0E372.1080105@v.loewis.de>

> Ok, I have the 3MB log file.  Should I upload it
> somewhere or is there a pattern to find?

Please compress it, and make a bug report on
bugs.python.org.

Regards,
Martin


From artomegus at gmail.com  Fri Mar  7 14:06:44 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Fri, 7 Mar 2008 08:06:44 -0500
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
Message-ID: <47857e720803070506r35b345d7w9748d01a835b3008@mail.gmail.com>

Greg Ewing wrote:

>  Not very well, IMO.
>
>  Without seeing a concrete use case, it's hard to be
>  sure, but my feeling is that there's almost certainly
>  a better way of thinking about the problem you're
>  trying to solve -- one that doesn't require introspecting
>  on a callable object to find out whether its implementation
>  involves a 'self' argument. That's *not* duck typing,
>  it's look-inside-before-you-leap.

>From the Python Tutorial glossary:

----------
duck-typing
    Pythonic programming style that determines an object's type by
inspection of its method or attribute signature rather than by
explicit relationship to some type object ("If it looks like a duck
and quacks like a duck, it must be a duck.") By emphasizing interfaces
rather than specific types, well-designed code improves its
flexibility by allowing polymorphic substitution. Duck-typing avoids
tests using type() or isinstance(). Instead, it typically employs
hasattr() tests or EAFP programming.
----------

That's what the code is doing. By wrapping the attribute access in a
try statement, it is essentially performing a hasattr() test.  That is
all hasattr does anyway; it tries getattr and checks if an exception
occurs.

So the question becomes, what is the 'duck test' for objects returned
by descriptors?  The test used in the example code works with Python
2.5, but fails in only one case in Python 3.0, because unbound methods
were removed.  When writing a wrapper that might wrap static methods
or instance methods (with class binding), the distinction between them
disappears when the attribute signature is the same for the the
respective callable objects.

As for a more concrete example, imagine the wrapper using the inspect
module to gather some information about the stack frame and passing it
along to selected methods.

I just like flexibility, and that's what unbound methods permitted in
2.5.  With them, the attribute signature of callable objects is
distinct for three separate cases: static methods, instance methods
with instance binding, and instance methods with class binding (class
methods are just a subset of instance methods with instance binding).

I'm not saying that unbound methods are 100% essential--I can learn to
live without them--I just think they provided some additional
flexibility, and that's a good thing in my opinion.

From pje at telecommunity.com  Fri Mar  7 15:50:38 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 07 Mar 2008 09:50:38 -0500
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
Message-ID: <20080307145103.6403D3A40AC@sparrow.telecommunity.com>

At 08:59 PM 3/6/2008 -0800, Guido van Rossum wrote:
>Would you mind giving an "executive summary" of your argument that
>doesn't require scanning 40 lines of code?

He's writing a variant of 'partial' that inserts an argument *after* 
the 'self', if there is one, but doesn't rely on 'self' being called 
'self'.  The only way to do that is by having unbound methods.

Personally, I think the error message for calling unbound methods was 
a better argument for keeping them.  (That, and the other use cases 
for unbound methods' im_class that I googled up the last time this 
subject came up.)

See also...

Error message use case:
http://mail.python.org/pipermail/python-dev/2007-November/075361.html

py.test breakage (i.e., your original retraction of unbound-method removal):
http://mail.python.org/pipermail/python-dev/2005-January/051236.html

Misc. Use cases found via Googling:
http://mail.python.org/pipermail/python-dev/2007-November/075308.html


From alexandre at peadrop.com  Fri Mar  7 18:39:35 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 7 Mar 2008 12:39:35 -0500
Subject: [Python-3000] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
Message-ID: <acd65fa20803070939t1b9da7d7vd06d39f0176be20@mail.gmail.com>

Hi,

A while ago, I found some pieces of code which were susceptible to
overflow. I posted a patch, however I haven't heard any comment about
it. Could someone, who has the time, take a look and review the patch
before I commit it?

http://bugs.python.org/issue1950

Thanks,
-- Alexandre

From guido at python.org  Fri Mar  7 18:59:44 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 7 Mar 2008 09:59:44 -0800
Subject: [Python-3000] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <acd65fa20803070939t1b9da7d7vd06d39f0176be20@mail.gmail.com>
References: <acd65fa20803070939t1b9da7d7vd06d39f0176be20@mail.gmail.com>
Message-ID: <ca471dc20803070959t433e1b45obc2fe5be8469b1a@mail.gmail.com>

I wish I could, I really wish, but I won't have time until April 1st,
unless I can steal some time while at PyCon.

On Fri, Mar 7, 2008 at 9:39 AM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Hi,
>
>  A while ago, I found some pieces of code which were susceptible to
>  overflow. I posted a patch, however I haven't heard any comment about
>  it. Could someone, who has the time, take a look and review the patch
>  before I commit it?
>
>  http://bugs.python.org/issue1950
>
>  Thanks,
>  -- Alexandre

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Fri Mar  7 21:15:36 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 7 Mar 2008 12:15:36 -0800
Subject: [Python-3000] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <ca471dc20803070959t433e1b45obc2fe5be8469b1a@mail.gmail.com>
References: <acd65fa20803070939t1b9da7d7vd06d39f0176be20@mail.gmail.com>
	<ca471dc20803070959t433e1b45obc2fe5be8469b1a@mail.gmail.com>
Message-ID: <bbaeab100803071215n10be935bxf4492a6fbab75cd0@mail.gmail.com>

On Fri, Mar 7, 2008 at 9:59 AM, Guido van Rossum <guido at python.org> wrote:
> I wish I could, I really wish, but I won't have time until April 1st,
>  unless I can steal some time while at PyCon.
>

Ditto for me, but make my availability time April 8th.

-Brett


>
>  On Fri, Mar 7, 2008 at 9:39 AM, Alexandre Vassalotti
>  <alexandre at peadrop.com> wrote:
>  > Hi,
>  >
>  >  A while ago, I found some pieces of code which were susceptible to
>  >  overflow. I posted a patch, however I haven't heard any comment about
>  >  it. Could someone, who has the time, take a look and review the patch
>  >  before I commit it?
>  >
>  >  http://bugs.python.org/issue1950
>  >
>  >  Thanks,
>  >  -- Alexandre
>
>  --
>  --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
>

From artomegus at gmail.com  Sat Mar  8 04:47:48 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Fri, 7 Mar 2008 22:47:48 -0500
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
Message-ID: <47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>

On Thu, Mar 6, 2008 at 11:59 PM, Guido van Rossum <guido at python.org> wrote:
> Would you mind giving an "executive summary" of your argument that
>  doesn't require scanning 40 lines of code?
>

Let me put it this way: if unbound methods are gone for good, then I
think it would nice to develop some guidance on checking the signature
of callable objects, to enable decorators to play nice with each
other--especially if they intend to modify the argument list.

For example, let's say there are two wrappers around two different
method types, like so (this is a short pseudo-code example, I
promise):

class A(object):
    @wrapper2
    @wrapper1
    @staticmethod
    def sm(*args):
        ...

    @wrapper2
    @wrapper1
    def im(self, *args):
       ...

Let's say the purpose of both wrapper1 and wrapper2 is to insert a new
argument into the argument list.  How should they do this for each
combination of method and binding type?

It would work as follows (in these examples, self.callable is what was
returned by the __get__ method of the wrapped descriptor):

For a static method:
   return self.callable(newarg, *args, **kwargs)

For an instance method with instance binding (i.e. a bound method):
   return self.callable(newarg, *args, **kwargs)

For an instance method with class binding (i.e. an unbound method):
   return self.callable(args[0], newarg, args[1:], **kwargs)

Notice the change?  This is necessary to maintain consistency for
handling instance binding and class binding.  With instance binding
(i.e. a bound method), the instance argument is passed implicitly--as
the first argument--by the wrapped callable.  Thus, the wrapper must
simulate this for class binding, because the instance argument must be
passed explicitly.

So how does wrapper1 know whether it is wrapping a static method, a
bound method, or an unbound method?  Well, one way it could do this is
to examine the type of the descriptor it is wrapping.  If it sees that
it is an instance of staticmethod, then it can process it as such.

However, wrapper2 doesn't have this luxury, since all it knows is that
it is wrapping an instance of wrapper1.

The other way is to examine the callable returned by the __get__
method of the wrapped descriptor.  This is where things get
interesting.

In Python 2.5, this was extremely easy:  If the callable has no
im_self attribute, then it is a static function.  If the callable has
an im_self attribute, and im_self is None, then it is an unbound
method.  If im_self is not None, then it is a bound method.  Simple.

But there's more: because the attribute signature is so simple, it can
easily be emulated by wrapper1's __get__ function, and thus wrapper2
would be able to make the same determination.  Plus, wrapper1 could
even copy the im_func attribute, so it would be possible to follow the
chain of wrappers all the way back to the original function.

But Python 3.0 breaks the pattern, because unbound methods no longer
exist.  When examining the callable returned by __get__, the signature
for a static method and an "unbound" method is the same (both plain
functions).  Now the wrapper will not be able to determine how to
modify the arguments.

How about this as a compromise?

1) In Python 3.0, all functions will have a read-only __self__
attribute that is set to None (so that it looks like an unbound
method, signature wise).

2) Bound methods will continue to behave as before; as a callable
object with a __self__ attribute referencing the instance object, and
a __func__ attribute referencing the original function object.

3) If a function is decorated with @staticmethod, then its __get__
method will return a callable object that wraps the function.  The
callable object will have no __self__ attribute, but it will have a
__func__ attribute referencing the original function.

4) As a convention, a callable that wraps another callable will copy
the __self__ attribute (or lack thereof), and the __func__ attribute.
Thus, the signature will be preserved up the chain.

Thus, the signature for a callable can be tested as follows:

if hasattr(obj, '__self__'):
   if obj.__self__ is None:
       ..."unbound" method...
   else:
       ....bound method...
else:
   ....static method....

Note that class methods always fall into the category of a bound
method, whether or not instance binding is used.  If there is a need
to differentiate between an instance method and a class method, then
the __self__ object can be examined to see if it a class.

From mwm at mired.org  Wed Mar  5 22:27:45 2008
From: mwm at mired.org (Mike Meyer)
Date: Wed, 5 Mar 2008 16:27:45 -0500
Subject: [Python-3000] 3.0 alpha builds break on FreeBSD.
Message-ID: <20080305162745.66f98009@bhuda.mired.org>

The 3.0 alphas don't seem to build on FreeBSD. I've tried on both
6.2-stable and 7.0-RELEASE, using both make and gmake on each. They
all start complaining about bad commands in the makeilfe, then seem to
be working fine, then complain about a recursion in the dependency
graph, and stop.

The problem appears to be related to configure not being able to find
a shell it's happy with. I'm not sure what's wrong with /bin/sh, but
configure complains about it not supporting functions. Changing the #!
line to use bash (after installing bash) solved the problem.

I'm sure there's more details those interested in fixing this would
like, I'm just not sure what they are - so please ask.

      Thanks,
      <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From mwm at mired.org  Thu Mar  6 01:29:00 2008
From: mwm at mired.org (Mike Meyer)
Date: Wed, 5 Mar 2008 19:29:00 -0500
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <87k5kgvgha.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
	<18383.8020.234900.192145@montanaro-dyndns-org.local>
	<87k5kgvgha.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20080305192900.1fc1776b@bhuda.mired.org>

On Thu, 06 Mar 2008 09:33:21 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> skip at pobox.com writes:
> 
>  > I still think it worthwhile to have *some* target in the Makefile
>  > which depends on altinstall and does the bininstall and maninstall
>  > steps.  Something like "makeprimary"?
> How about "install-as-python" or "install-as-default"?

How about the install target smart? If there's a $PREFIX/bin/python,
it doesn't clobber it. If there's not, it does.

    <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From martin at v.loewis.de  Sat Mar  8 09:17:48 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 08 Mar 2008 09:17:48 +0100
Subject: [Python-3000] 3.0 alpha builds break on FreeBSD.
In-Reply-To: <20080305162745.66f98009@bhuda.mired.org>
References: <20080305162745.66f98009@bhuda.mired.org>
Message-ID: <47D24BAC.5060201@v.loewis.de>

> The 3.0 alphas don't seem to build on FreeBSD.

That's not what the buildbot says:

http://www.python.org/dev/buildbot/3.0/x86%20FreeBSD%203.0/builds/530/step-configure/0
http://www.python.org/dev/buildbot/3.0/x86%20FreeBSD%203.0/builds/530/step-compile/0

> The problem appears to be related to configure not being able to find
> a shell it's happy with. I'm not sure what's wrong with /bin/sh, but
> configure complains about it not supporting functions. Changing the #!
> line to use bash (after installing bash) solved the problem.
> 
> I'm sure there's more details those interested in fixing this would
> like, I'm just not sure what they are - so please ask.

A specific error message, literally copied from the configure output,
would be helpful (assuming there really is an error message from
configure, rather than configure complaining by some other means
than an error message). Along with that, the snippet from config.log
immediately preceding that error message might also be needed.

Regards,
Martin

From ncoghlan at gmail.com  Sat Mar  8 09:30:12 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 08 Mar 2008 18:30:12 +1000
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
Message-ID: <47D24E94.8090006@gmail.com>

Anthony Tolle wrote:
> On Thu, Mar 6, 2008 at 11:59 PM, Guido van Rossum <guido at python.org> wrote:
>> Would you mind giving an "executive summary" of your argument that
>>  doesn't require scanning 40 lines of code?
>>
> 
> Let me put it this way: if unbound methods are gone for good, then I
> think it would nice to develop some guidance on checking the signature
> of callable objects, to enable decorators to play nice with each
> other--especially if they intend to modify the argument list.

The short-short version (as PJE already summarised it) of the underlying 
problem: functools.partial style functionality doesn't always play well 
with methods, because the first argument may need special handling once 
__get__ has been invoked, but there's not always any easy way to tell if 
this is the case. With the removal of unbound methods in Py3k, there's 
no longer any reliable way at all to tell the difference between an 
unbound method and a static method.

functools.partial actually ducks the issue entirely by always creating 
an object that behaves like a static method - it has no __get__ method, 
so acts like any other class attribute rather than trying to act as a 
descriptor. The downside of this is that you can't use it to wrap an 
unbound method, since you want to insert the later supplied 'self' 
argument before the positional args rather than after.

Descriptor wrapping is actually quite a complicated topic - I think the 
original poster has a valid complaint, but I'm not sure that restoring 
unbound methods is the right answer (unfortunately, I don't have a 
better answer to offer).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From steven.bethard at gmail.com  Sat Mar  8 21:28:09 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 8 Mar 2008 13:28:09 -0700
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
Message-ID: <d11dcfba0803081228j72eee849xab5cf8a3ae394b69@mail.gmail.com>

On Fri, Mar 7, 2008 at 8:47 PM, Anthony Tolle <artomegus at gmail.com> wrote:
>  Let me put it this way: if unbound methods are gone for good, then I
>  think it would nice to develop some guidance on checking the signature
>  of callable objects, to enable decorators to play nice with each
>  other--especially if they intend to modify the argument list.
[snip]
>  For a static method:
>    return self.callable(newarg, *args, **kwargs)
>
>  For an instance method with instance binding (i.e. a bound method):
>    return self.callable(newarg, *args, **kwargs)
>
>  For an instance method with class binding (i.e. an unbound method):
>    return self.callable(args[0], newarg, args[1:], **kwargs)

Why is it so crucial that "self" is the first argument?  If I use a
decorator that adds a new element to the beginning of the argument
list, I wouldn't be surprised that I now have to write my methods as::

    @add_initial_argument
    def method(new_arg, self, ...):
        ...

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From artomegus at gmail.com  Sun Mar  9 00:33:40 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Sat, 8 Mar 2008 18:33:40 -0500
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <d11dcfba0803081228j72eee849xab5cf8a3ae394b69@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<d11dcfba0803081228j72eee849xab5cf8a3ae394b69@mail.gmail.com>
Message-ID: <47857e720803081533i4129ca52i91843cfde765bdd8@mail.gmail.com>

On Sat, Mar 8, 2008 at 3:28 PM, Steven Bethard <steven.bethard at gmail.com> wrote:
>  Why is it so crucial that "self" is the first argument?  If I use a
>  decorator that adds a new element to the beginning of the argument
>  list, I wouldn't be surprised that I now have to write my methods as::
>
>     @add_initial_argument
>     def method(new_arg, self, ...):
>         ...

That would work with class binding in Python 3.0 (i.e. "unbound"
methods).  In Python 2.5, doing that with an unbound method would
throw an error.

However, bound methods still force the first argument to be self.  If
I want to change this behavior, then I need to grab the __func__
attribute of the method and send the parameters directly.  That means
re-implementing the behavior of bound methods; i.e. inserting __self__
into the argument list.

Unfortunately, that destroys the "magic" of the bound method,
bypassing it altogether, and it could only be done once.  Thus, if
another decorator wrapped this one, then the inner one would have to
present itself as a plain function (no __self__ or __func__
attributes) to the outer one.  Any information about the original
method type would be lost; and I'm not sure that is a good thing.

Anyway, this isn't just about inserting arguments.  It is also about
being able to inspect callables to determine their origin (static
method, bound method, unbound method), to facilitate designing
decorators that play well with one another.  In my opinion, the ideal
situation is to allow information about the original method to pass
all the way up the chain of decorators.

Of course, there may be cases one would want to mask the underlying
signature (which is essentially what staticmethod does).  In most
cases, however, preserving the attribute signature would be indicative
of well-behaved decorators.

From steven.bethard at gmail.com  Sun Mar  9 01:38:45 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 8 Mar 2008 17:38:45 -0700
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803081533i4129ca52i91843cfde765bdd8@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<d11dcfba0803081228j72eee849xab5cf8a3ae394b69@mail.gmail.com>
	<47857e720803081533i4129ca52i91843cfde765bdd8@mail.gmail.com>
Message-ID: <d11dcfba0803081638g7aa7ae32p8006bbee2c3033c4@mail.gmail.com>

On Sat, Mar 8, 2008 at 4:33 PM, Anthony Tolle <artomegus at gmail.com> wrote:
> On Sat, Mar 8, 2008 at 3:28 PM, Steven Bethard <steven.bethard at gmail.com> wrote:
>  >  Why is it so crucial that "self" is the first argument?  If I use a
>  >  decorator that adds a new element to the beginning of the argument
>  >  list, I wouldn't be surprised that I now have to write my methods as::
>  >
>  >     @add_initial_argument
>  >     def method(new_arg, self, ...):
>  >         ...
>
>  That would work with class binding in Python 3.0 (i.e. "unbound"
>  methods).  In Python 2.5, doing that with an unbound method would
>  throw an error.

>>> def add_initial_argument(func):
...     def f(*args, **kwargs):
...         return func('newarg', *args, **kwargs)
...     return f
...
>>> class C(object):
...     @add_initial_argument
...     def foo(newarg, self):
...         print newarg
...
>>> C().foo()
newarg
>>> C.foo(C())
newarg

I don't see an error thrown with either the bound or unbound methods...

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From guido at python.org  Sun Mar  9 01:47:50 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 8 Mar 2008 16:47:50 -0800
Subject: [Python-3000] should Python 3's executable install as 'python'?
In-Reply-To: <20080305192900.1fc1776b@bhuda.mired.org>
References: <fqltd8$ih0$1@ger.gmane.org>
	<79990c6b0803050328m536e0ecsddbc9960f1b6c84e@mail.gmail.com>
	<20080305113102.GA10232@phd.pp.ru>
	<ca471dc20803050939w7f66263fo4a3e28e95b1bbeff@mail.gmail.com>
	<18382.57958.331087.10882@montanaro-dyndns-org.local>
	<ca471dc20803051019i6591a254r79f3441140b757d5@mail.gmail.com>
	<18383.8020.234900.192145@montanaro-dyndns-org.local>
	<87k5kgvgha.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080305192900.1fc1776b@bhuda.mired.org>
Message-ID: <ca471dc20803081647h1f334c4bi9d3a12de7633613a@mail.gmail.com>

On Wed, Mar 5, 2008 at 4:29 PM, Mike Meyer <mwm at mired.org> wrote:
>
> On Thu, 06 Mar 2008 09:33:21 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>
>  > skip at pobox.com writes:
>  >
>  >  > I still think it worthwhile to have *some* target in the Makefile
>  >  > which depends on altinstall and does the bininstall and maninstall
>  >  > steps.  Something like "makeprimary"?
>  > How about "install-as-python" or "install-as-default"?
>
>  How about the install target smart? If there's a $PREFIX/bin/python,
>  it doesn't clobber it. If there's not, it does.

That's not enough -- this might hide a "python" on the shell's $PATH
in a later spot.

During the next 3 years or so, installing Py3k as the default "python"
will be a deed of utter irresponsibility and is likely to break your
system in subtle ways (both OSX and Linux these days use Python for
certain system tasks). If you *really* want to shoot yourself in the
foot this way, go ahead and explicitly use "make altinstall
bininstall" or link it yourself.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Sun Mar  9 10:54:23 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Mar 2008 22:54:23 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803070506r35b345d7w9748d01a835b3008@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803070506r35b345d7w9748d01a835b3008@mail.gmail.com>
Message-ID: <47D3B3CF.7040204@canterbury.ac.nz>

Anthony Tolle wrote:
> As for a more concrete example, imagine the wrapper using the inspect
> module to gather some information about the stack frame and passing it
> along to selected methods.

That's still not very concrete. It doesn't demonstrate
why you would want to find out that particular piece of
information.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar  9 11:02:01 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Mar 2008 23:02:01 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <20080307145103.6403D3A40AC@sparrow.telecommunity.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<20080307145103.6403D3A40AC@sparrow.telecommunity.com>
Message-ID: <47D3B599.4030303@canterbury.ac.nz>

Phillip J. Eby wrote:
> He's writing a variant of 'partial' that inserts an argument *after* 
> the 'self', if there is one

I'll need convincing that the user of such a function
isn't able to know whether the function he's wrapping
takes a self, and use an appropriate variation of
the partial function.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar  9 11:31:27 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Mar 2008 23:31:27 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
Message-ID: <47D3BC7F.9090800@canterbury.ac.nz>

Anthony Tolle wrote:

> So how does wrapper1 know whether it is wrapping a static method, a
> bound method, or an unbound method?  Well, one way it could do this is
> to examine the type of the descriptor it is wrapping.

No, a wrapper can't distinguish between a plain function and
an unbound method this way, because it gets called before the
function is put into a class. So it's always wrapping a plain
function, not an unbound method object.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar  9 11:37:14 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Mar 2008 23:37:14 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47D24E94.8090006@gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<47D24E94.8090006@gmail.com>
Message-ID: <47D3BDDA.4060600@canterbury.ac.nz>

Nick Coghlan wrote:
> functools.partial style functionality doesn't always play well 
> with methods,

I can see it not working well with *unbound* methods. Bound
methods shouldn't be any problem, since from the outside
they're called just like any other function.

But applying partial to an unbound method seems like a
screwy thing to do in the first place. I'm going to need
to see a concrete use case for *that* which can't be
fixed by explicitly using a special version of partial
that inserts after the first argument.

-- 
Greg

From artomegus at gmail.com  Mon Mar 10 00:53:49 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Sun, 9 Mar 2008 19:53:49 -0400
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47D3BC7F.9090800@canterbury.ac.nz>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<47D3BC7F.9090800@canterbury.ac.nz>
Message-ID: <47857e720803091653m4a427818w2227200885340977@mail.gmail.com>

On Sun, Mar 9, 2008 at 6:31 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
>  No, a wrapper can't distinguish between a plain function and
>  an unbound method this way, because it gets called before the
>  function is put into a class. So it's always wrapping a plain
>  function, not an unbound method object.
>

Witness:

>>> def wraptest(func):
...     print "I'm wrapping an instance of ", type(func)
...     return func
...
>>> class C(object):
...     @wraptest
...     @staticmethod
...     def s():
...         pass
...     @wraptest
...     @classmethod
...     def c():
...         pass
...     @wraptest
...     def i():
...         pass
...
I'm wrapping an instance of  <type 'staticmethod'>
I'm wrapping an instance of  <type 'classmethod'>
I'm wrapping an instance of  <type 'function'>
>>>

From artomegus at gmail.com  Mon Mar 10 01:07:54 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Sun, 9 Mar 2008 20:07:54 -0400
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803091653m4a427818w2227200885340977@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<47D3BC7F.9090800@canterbury.ac.nz>
	<47857e720803091653m4a427818w2227200885340977@mail.gmail.com>
Message-ID: <47857e720803091707k69649c67y9ae19ed19e021987@mail.gmail.com>

On Sun, Mar 9, 2008 at 7:53 PM, Anthony Tolle <artomegus at gmail.com> wrote:
> On Sun, Mar 9, 2008 at 6:31 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>  >
>  >  No, a wrapper can't distinguish between a plain function and
>  >  an unbound method this way, because it gets called before the
>  >  function is put into a class. So it's always wrapping a plain
>  >  function, not an unbound method object.
>  >
>
>  Witness:
>
>  >>> def wraptest(func):
>  ...     print "I'm wrapping an instance of ", type(func)
>  ...     return func
>  ...
>  >>> class C(object):
>  ...     @wraptest
>  ...     @staticmethod
>  ...     def s():
>  ...         pass
>  ...     @wraptest
>  ...     @classmethod
>  ...     def c():
>  ...         pass
>  ...     @wraptest
>  ...     def i():
>  ...         pass
>  ...
>  I'm wrapping an instance of  <type 'staticmethod'>
>  I'm wrapping an instance of  <type 'classmethod'>
>  I'm wrapping an instance of  <type 'function'>
>  >>>
>

Sorry about replying to myself, but I should clarify:  That particular
point in my post was about checking the type of wrapped object
*before* calling __get__ on it, to see whether or not I'm wrapping a
static method.  The theory is, if I don't see 'staticmethod' or
'classmethod', then simple deduction tells me I'm going to get either
a bound method or an unbound method.  Whether it is bound or unbound
won't be known until I check what is returned by __get__.

Of course, the other point was that this would only work on the first
wrapper around @staticmethod or @classmethod.  I wasn't offering it as
a real solution.

From artomegus at gmail.com  Mon Mar 10 03:22:47 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Sun, 9 Mar 2008 22:22:47 -0400
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47D3B3CF.7040204@canterbury.ac.nz>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803070506r35b345d7w9748d01a835b3008@mail.gmail.com>
	<47D3B3CF.7040204@canterbury.ac.nz>
Message-ID: <47857e720803091922q11cbfb2fna8fbfd7d493c96d3@mail.gmail.com>

On Sun, Mar 9, 2008 at 5:54 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Anthony Tolle wrote:
>  > As for a more concrete example, imagine the wrapper using the inspect
>  > module to gather some information about the stack frame and passing it
>  > along to selected methods.
>
>  That's still not very concrete. It doesn't demonstrate
>  why you would want to find out that particular piece of
>  information.
>

Ok, I have something that I hope is concrete enough.  It is (yet
another) version of autosuper that I put together for Python 2.5,
since it doesn't have the magic version of super() from 3.0.  Rather
than write a new super function, I wanted to write something that
would work by inserting the correct value of super into the argument
list.  In fact, this script is why I brought up the whole discussion.

Now, while the point of the script itself is moot in version 3.0, it
is still a concrete example of what I've been discussing.  When I
realized that the check for a static method wouldn't work in 3.0, I
began to wonder if anyone else had run across the same problem, or if
they even cared.

Here's the script, which includes some assertions to test its behavior:

------------------------------------------------------------

class autosuper_method(object):
    def __init__(self, desc, cls=None):
        self.desc = desc
        self.cls = cls

    def __get__(self, obj, type=None):
        return autosuper_callable(self.desc,
                                  self.cls,
                                  self.desc.__get__(obj, type))

class autosuper_callable(autosuper_method):
    def __init__(self, desc, cls, callable):
        self.desc = desc
        self.cls = cls
        self.callable = callable

    def __call__(self, *args, **kwargs):
        if self.cls is None:
            raise TypeError('must inherit from autosuper')
        try:
            obj = self.callable.im_self
        except AttributeError:
            raise TypeError('autosuper used with static method')
        if obj is None:
            obj = args[0]
            return self.callable.__call__(obj,
                                          super(self.cls, obj),
                                          *args[1:],
                                          **kwargs)
        return self.callable.__call__(super(self.cls, obj),
                                      *args,
                                      **kwargs)

class autosuper_meta(type):
    def __init__(cls, name, bases, clsdict):
        # fix up all autosuper_method instances in class
        for attr in clsdict.keys():
            value = clsdict[attr]
            if isinstance(value, autosuper_method):
                type.__setattr__(cls,
                                 attr,
                                 autosuper_method(value.desc, cls))

    def __setattr__(cls, attr, value):
        # catch assignment after class definition
        if isinstance(value, autosuper_method):
            value = autosuper_method(value.desc, cls)
        type.__setattr__(cls, attr, value)

class autosuper(object):
    __metaclass__ = autosuper_meta

if __name__ == '__main__':
    class A(autosuper):
        @classmethod
        def cm(cls):
            return 'A(%s)' % cls.name

        def im(self):
            return 'A(%s)' % self.name

    # Demo - standard use
    class B(A):
        @autosuper_method
        @classmethod
        def cm(cls, super):
            return 'B' + super.cm()

        @autosuper_method
        def im(self, super):
            return 'B' + super.im()

    # Demo - reference super in inner function
    class C(A):
        @autosuper_method
        @classmethod
        def cm(cls, super):
            def inner():
                return 'C' + super.cm()
            return inner()

        @autosuper_method
        def im(self, super):
            def inner():
                return 'C' + super.im()
            return inner()

    # Demo - define function before class definition
    @autosuper_method
    @classmethod
    def D_cm(cls, super):
        return 'D' + super.cm()

    @autosuper_method
    def D_im(self, super):
        return 'D' + super.im()

    class D(B, C):
        name = 'D'
        def __init__(self, name):
            self.name = name
        cm = D_cm
        im = D_im

    # Demo - define functions after class definition
    class E(B, C):
        name = 'E'
        def __init__(self, name):
            self.name = name

    @autosuper_method
    @classmethod
    def E_cm(cls, super):
        return 'E' + super.cm()

    @autosuper_method
    def E_im(self, super):
        return 'E' + super.im()

    E.cm = E_cm
    E.im = E_im

    # Test D
    d = D('d')
    assert d.cm() == 'DBCA(D)'  # class method, instance binding
    assert D.cm() == 'DBCA(D)'  # class method, class binding
    assert d.im() == 'DBCA(d)'  # instance method, instance binding
    assert D.im(d) == 'DBCA(d)' # instance method, class binding

    # Test E
    e = E('e')
    assert e.cm() == 'EBCA(E)'  # class method, instance binding
    assert E.cm() == 'EBCA(E)'  # class method, class binding
    assert e.im() == 'EBCA(e)'  # instance method, instance binding
    assert E.im(e) == 'EBCA(e)' # instance method, class binding

    # Give E cm and im from D
    E.cm = D.cm
    E.im = D.im
    assert e.cm() == 'DBCA(E)'  # class method, instance binding
    assert E.cm() == 'DBCA(E)'  # class method, class binding
    assert e.im() == 'DBCA(e)'  # instance method, instance binding
    assert E.im(e) == 'DBCA(e)' # instance method, class binding

------------------------------------------------------------

I can imagine the next question: If this version of autosuper doesn't
work for static methods (it doesn't make sense that it would, since
super only works when bound), then why would I care if it couldn't
check for static methods?  Why not just assume it will be used for
class methods and instance methods, and adjust the code accordingly?

Well, that was my question from the beginning: When writing a wrapper
like this, would anyone care if it could no longer distinguish between
static methods and unbound methods, in Python 3.0?

So far, it sounds like the answer is 'no', which is fine with me.  I
just thought I'd bring it to everyone's attention.

From artomegus at gmail.com  Mon Mar 10 03:28:18 2008
From: artomegus at gmail.com (Anthony Tolle)
Date: Sun, 9 Mar 2008 22:28:18 -0400
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <d11dcfba0803081638g7aa7ae32p8006bbee2c3033c4@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<d11dcfba0803081228j72eee849xab5cf8a3ae394b69@mail.gmail.com>
	<47857e720803081533i4129ca52i91843cfde765bdd8@mail.gmail.com>
	<d11dcfba0803081638g7aa7ae32p8006bbee2c3033c4@mail.gmail.com>
Message-ID: <47857e720803091928p2712b5cas6c7aff136539f786@mail.gmail.com>

On Sat, Mar 8, 2008 at 8:38 PM, Steven Bethard <steven.bethard at gmail.com> wrote:
>
>  I don't see an error thrown with either the bound or unbound methods...
>

Sorry, I should have clarified. The error occurs when wrapping the
function as a descriptor, not when wrapping it with another function.
Here's an example in Python 2.5:

class add_initial_argument(object):
    def __init__(self, descriptor, callable=None):
        self.descriptor = descriptor
        self.callable = callable
    def __get__(self, obj, type=None):
        return add_initial_argument(self.descriptor,
                                    self.descriptor.__get__(obj, type))
    def __call__(self, *args, **kwargs):
        return self.callable.__call__('newarg',
                                      *args,
                                      **kwargs)

class C(object):
    @add_initial_argument
    def foo(newarg, self):
        print 'arg1: ', newarg
        print 'arg2: ', self

>>> C().foo()
arg1:  <__main__.C object at 0x00A900D0>
arg2:  newarg
>>> C.foo(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 11, in __call__
TypeError: unbound method foo() must be called with C instance as first argument
 (got str instance instead)

Also notice that the bound method still got self as the first argument.

See the script example in my recent reply to Greg Ewing for why I'm
using descriptor wrapping:
http://mail.python.org/pipermail/python-3000/2008-March/012428.html

From greg.ewing at canterbury.ac.nz  Mon Mar 10 22:49:14 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 11 Mar 2008 10:49:14 +1300
Subject: [Python-3000] The case for unbound methods?
In-Reply-To: <47857e720803091653m4a427818w2227200885340977@mail.gmail.com>
References: <47857e720803061943j16568798k750d62636fe4a719@mail.gmail.com>
	<ca471dc20803062059v2097adoce67dfd15f3b31f8@mail.gmail.com>
	<47857e720803071947s3be5fc55r872fd09eadad6db1@mail.gmail.com>
	<47D3BC7F.9090800@canterbury.ac.nz>
	<47857e720803091653m4a427818w2227200885340977@mail.gmail.com>
Message-ID: <47D5ACDA.1060402@canterbury.ac.nz>

Anthony Tolle wrote:
> I'm wrapping an instance of  <type 'staticmethod'>
> I'm wrapping an instance of  <type 'classmethod'>
> I'm wrapping an instance of  <type 'function'>

Hmmm, so what you're really worried about is that
people will be able to create static methods without
using staticmethod().

I think the solution to this has already been
mentioned. If you're wrapping a method in something
that inserts an extra argument at the beginning,
then you write it as

   @somewrapper
   def meth(extra_arg, self, arg1, arg2, ...)
     ...

Simple, explicit, non-magical, no introspection
required.

-- 
Greg

From greg at krypto.org  Fri Mar 14 18:45:11 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 14 Mar 2008 12:45:11 -0500
Subject: [Python-3000] PyBUF_LOCK fails on bytes objects. they're read-only,
	why should it fail?
Message-ID: <52dc1c820803141045k43636b65w946fa552c03b9dc@mail.gmail.com>

bytes objects are by their definition immutable and read only.  but when
passing one to a buffer api that tries to use the PyBUF_LOCK flag it raises
BufferError "Cannot lock this object." from PyBuffer_FillInfo in
Objects/abstract.c as called by Objects/bytesobject.c's bytes_getbuffer
method.

I think the problem is a >= 0 where a != 0 was intended in
PyBuffer_FillInfo:

--- Objects/abstract.c  (revision 61375)
+++ Objects/abstract.c  (working copy)
@@ -673,7 +673,7 @@
 {
        if (view == NULL) return 0;
        if (((flags & PyBUF_LOCK) == PyBUF_LOCK) &&
-           readonly >= 0) {
+           readonly != 0) {
                PyErr_SetString(PyExc_BufferError,
                                "Cannot lock this object.");
                return -1;


All tests pass for me with this patch applied.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080314/1a8c3be3/attachment.htm 

From oliphant.travis at ieee.org  Sat Mar 15 06:46:58 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Sat, 15 Mar 2008 00:46:58 -0500
Subject: [Python-3000] PyBUF_LOCK fails on bytes objects. they're
 read-only, why should it fail?
In-Reply-To: <52dc1c820803141045k43636b65w946fa552c03b9dc@mail.gmail.com>
References: <52dc1c820803141045k43636b65w946fa552c03b9dc@mail.gmail.com>
Message-ID: <frfnsi$maq$1@ger.gmane.org>

Gregory P. Smith wrote:
> bytes objects are by their definition immutable and read only.  but when 
> passing one to a buffer api that tries to use the PyBUF_LOCK flag it 
> raises BufferError "Cannot lock this object." from PyBuffer_FillInfo in 
> Objects/abstract.c as called by Objects/bytesobject.c's bytes_getbuffer 
> method.
> 
> I think the problem is a >= 0 where a != 0 was intended in 
> PyBuffer_FillInfo:
> 
> --- Objects/abstract.c  (revision 61375)
> +++ Objects/abstract.c  (working copy)
> @@ -673,7 +673,7 @@
>  {
>         if (view == NULL) return 0;
>         if (((flags & PyBUF_LOCK) == PyBUF_LOCK) &&
> -           readonly >= 0) {
> +           readonly != 0) {
>                 PyErr_SetString(PyExc_BufferError,
>                                 "Cannot lock this object.");
>                 return -1;
> 
>

Good catch.  This looks like a good fix.

-Travis O.


From guido at python.org  Sat Mar 15 17:15:02 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 15 Mar 2008 11:15:02 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
Message-ID: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>

Thomas Wouters suggests some new syntax:

http://bugs.python.org/issue2292

>>> a, b, *c = range(5)

>>> *a, b, c = a, b, *c
>>> a, b, c
([0, 1, 2], 3, 4)
>>> [ *a, b, c ]
[0, 1, 2, 3, 4]
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> [ *item for item in L ]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Also, yielding everything from an iterator:

>>> def flatten(iterables):
...     for it in iterables:
...         yield *it
...
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> flatten(L)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

What do people think?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From thomas at python.org  Sat Mar 15 17:51:30 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 09:51:30 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <9e804ac0803150951o144a32ccx84615991174e654d@mail.gmail.com>

On Sat, Mar 15, 2008 at 9:15 AM, Guido van Rossum <guido at python.org> wrote:

> Thomas Wouters suggests some new syntax:
>
> http://bugs.python.org/issue2292
>
> >>> a, b, *c = range(5)
>
> >>> *a, b, c = a, b, *c
> >>> a, b, c
> ([0, 1, 2], 3, 4)
> >>> [ *a, b, c ]
> [0, 1, 2, 3, 4]
> >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
> >>> [ *item for item in L ]
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> Also, yielding everything from an iterator:
>
> >>> def flatten(iterables):
> ...     for it in iterables:
> ...         yield *it
> ...
> >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
> >>> flatten(L)
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>

As you mentioned in the ticket, that's actually a cut-and-paste error:

>>> flatten(L)
<generator object at 0xb7cc5fb4>
>>> list(flatten(L))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Also, it does sets and setcomps too:

>>> { *a, 0, 4}
{0, 1, 2, 4}
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> { *item for item in L }
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/5b65c86b/attachment.htm 

From brett at python.org  Sat Mar 15 18:23:59 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 15 Mar 2008 12:23:59 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <bbaeab100803151023p54630dbfoecb4acb708376379@mail.gmail.com>

On Sat, Mar 15, 2008 at 11:15 AM, Guido van Rossum <guido at python.org> wrote:
> Thomas Wouters suggests some new syntax:
>
>  http://bugs.python.org/issue2292
>
>  >>> a, b, *c = range(5)
>
>  >>> *a, b, c = a, b, *c
>  >>> a, b, c
>  ([0, 1, 2], 3, 4)
>  >>> [ *a, b, c ]
>  [0, 1, 2, 3, 4]
>  >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>  >>> [ *item for item in L ]
>  [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
>  Also, yielding everything from an iterator:
>
>  >>> def flatten(iterables):
>  ...     for it in iterables:
>  ...         yield *it
>  ...
>  >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>  >>> flatten(L)
>  [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
>  What do people think?

I am +1 since it is a nice generalization, especially the yield usage.

-Brett

From p.f.moore at gmail.com  Sat Mar 15 18:33:33 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 15 Mar 2008 17:33:33 +0000
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <79990c6b0803151033n6a4ed8bfh3556f235ed362847@mail.gmail.com>

On 15/03/2008, Guido van Rossum <guido at python.org> wrote:
> Thomas Wouters suggests some new syntax:
>
>  http://bugs.python.org/issue2292
[...]
>  What do people think?

I like it. It's on the border of being too obscure (the examples are
logical, but I need to think to apply the logic - if you see what I
mean), but overall I think it's a reasonable generalisation. As Brett
says, the yield example is compelling. I like "yield *it" much better
than the current somewhat clumsy idiom "for val in it: yield val".

Paul.

From ncoghlan at gmail.com  Sat Mar 15 19:21:19 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 16 Mar 2008 04:21:19 +1000
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <47DC139F.5000800@gmail.com>

Guido van Rossum wrote:
> What do people think?

I think this idea (or variants thereof) has been suggested a few times 
over the years, and I don't think the arguments against it have ever 
been particularly compelling. The difference this time is that PEP 3132 
has done the work of thrashing out some of the semantic details, and 
Thomas has provided an actual working patch to make it happen :)

So +1 here, even though I expect style guides will end up discouraging 
some of the more obscure possible uses.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From nevillegrech at gmail.com  Sat Mar 15 20:44:19 2008
From: nevillegrech at gmail.com (Neville Grech Neville Grech)
Date: Sat, 15 Mar 2008 20:44:19 +0100
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DC139F.5000800@gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC139F.5000800@gmail.com>
Message-ID: <de9ae4950803151244y751e2c40j7eb09be1c161d8c6@mail.gmail.com>

What about co-routines?

>>> def coroutine():
...     a, b = (yield *[1,2])
...    print (a)
...    print (b)
...
>>> cr=coroutine()
>>> next(cr)
1
>>> cr.send(3)
2
>>> cr.send(4)
3
4
>>>


On Sat, Mar 15, 2008 at 7:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Guido van Rossum wrote:
> > What do people think?
>
> I think this idea (or variants thereof) has been suggested a few times
> over the years, and I don't think the arguments against it have ever
> been particularly compelling. The difference this time is that PEP 3132
> has done the work of thrashing out some of the semantic details, and
> Thomas has provided an actual working patch to make it happen :)
>
> So +1 here, even though I expect style guides will end up discouraging
> some of the more obscure possible uses.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>             http://www.boredomandlaziness.org
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com
>



-- 
Regards,
Neville Grech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/cae04e58/attachment.htm 

From g.brandl at gmx.net  Sat Mar 15 20:55:23 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 15 Mar 2008 20:55:23 +0100
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <frh9iu$nmf$1@ger.gmane.org>

Guido van Rossum schrieb:
> Thomas Wouters suggests some new syntax:
> 
> http://bugs.python.org/issue2292
> 
>>>> a, b, *c = range(5)
> 
>>>> *a, b, c = a, b, *c
>>>> a, b, c
> ([0, 1, 2], 3, 4)
>>>> [ *a, b, c ]
> [0, 1, 2, 3, 4]
>>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>>> [ *item for item in L ]
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> 
> Also, yielding everything from an iterator:
> 
>>>> def flatten(iterables):
> ....     for it in iterables:
> ....         yield *it
> ....
>>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>>> flatten(L)
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> 
> What do people think?

As Brett says, it's a good generalization. +1 from me.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From thomas at python.org  Sat Mar 15 22:03:23 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 14:03:23 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <de9ae4950803151244y751e2c40j7eb09be1c161d8c6@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC139F.5000800@gmail.com>
	<de9ae4950803151244y751e2c40j7eb09be1c161d8c6@mail.gmail.com>
Message-ID: <9e804ac0803151403x4c6342b1n1fa41b1d6b0c2b37@mail.gmail.com>

On Sat, Mar 15, 2008 at 12:44 PM, Neville Grech Neville Grech <
nevillegrech at gmail.com> wrote:

> What about co-routines?
>

They're out of luck. Your code below doesn't work (the 'yield *it' syntax
always results in None; any sends are discarded.) I do not think collecting
a (potentially ever-growing) list of results is really the right thing to
do, do you? :-) Something that *might* make sense is to forward any sends on
to the inner iterator, but that means it would always have to be a
generator, and at that point you're really much better off explicitly
defining the behaviour (by looping yourself.)


>
> >>> def coroutine():
> ...     a, b = (yield *[1,2])
> ...    print (a)
> ...    print (b)
> ...
> >>> cr=coroutine()
> >>> next(cr)
> 1
> >>> cr.send(3)
> 2
> >>> cr.send(4)
> 3
> 4
> >>>
>
>
> On Sat, Mar 15, 2008 at 7:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> > Guido van Rossum wrote:
> > > What do people think?
> >
> > I think this idea (or variants thereof) has been suggested a few times
> > over the years, and I don't think the arguments against it have ever
> > been particularly compelling. The difference this time is that PEP 3132
> > has done the work of thrashing out some of the semantic details, and
> > Thomas has provided an actual working patch to make it happen :)
> >
> > So +1 here, even though I expect style guides will end up discouraging
> > some of the more obscure possible uses.
> >
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> > ---------------------------------------------------------------
> >             http://www.boredomandlaziness.org
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com
> >
>
>
>
> --
> Regards,
> Neville Grech
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/thomas%40python.org
>
>


-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/c272f61e/attachment-0001.htm 

From bjourne at gmail.com  Sat Mar 15 22:05:08 2008
From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=)
Date: Sat, 15 Mar 2008 21:05:08 +0000
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <740c3aec0803151405n19323a69sd42ba8effd5d52f5@mail.gmail.com>

On Sat, Mar 15, 2008 at 4:15 PM, Guido van Rossum <guido at python.org> wrote:
>  >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>  >>> [ *item for item in L ]
>  [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Can you mix freely?

>>> [*(*item, *item) for item in L]
[0, 1, 2, 0, 1, 2, 3, 4, 3, 4, 5, 5, 6, 6, 7, 8, 9, 7, 8, 9]

-- 
mvh Bj?rn

From thomas at python.org  Sat Mar 15 22:18:10 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 14:18:10 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <740c3aec0803151405n19323a69sd42ba8effd5d52f5@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<740c3aec0803151405n19323a69sd42ba8effd5d52f5@mail.gmail.com>
Message-ID: <9e804ac0803151418v1b908a96p3ffc842239b003c7@mail.gmail.com>

On Sat, Mar 15, 2008 at 2:05 PM, BJ?rn Lindqvist <bjourne at gmail.com> wrote:

> On Sat, Mar 15, 2008 at 4:15 PM, Guido van Rossum <guido at python.org>
> wrote:
> >  >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
> >  >>> [ *item for item in L ]
> >  [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> Can you mix freely?
>
> >>> [*(*item, *item) for item in L]
> [0, 1, 2, 0, 1, 2, 3, 4, 3, 4, 5, 5, 6, 6, 7, 8, 9, 7, 8, 9]
>

Of course. It's just a generalization of *, it's not a special case.
[*(*item, *item)] is automatically parsed correctly. Of course, since L
contains a generator, the output isn't entirely like you suggested:

 >>> a = [0, 1, 2]
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> [*(*item, *item) for item in L]
[0, 1, 2, 0, 1, 2, 3, 4, 3, 4, 5, 5, 6, 6, 7, 8, 9]

The only thing that doesn't work (yet) is:

list(*item for item in L)

because the grammar gets confused about the '*item'. This is caused by the
specialcasing that *args and **kwargs in functioncalls and -definitions
really is. Since Guido wants to be able to do 'f(*a, b, c)' (and presumably
'f(*a, *b, *c)' too) that will all have to change anyway. However, changing
this part of the grammar is, uhm, "not as easy", so I need a couple of days.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/f645792c/attachment.htm 

From tjreedy at udel.edu  Sat Mar 15 22:58:11 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 15 Mar 2008 17:58:11 -0400
Subject: [Python-3000] Using *a for packing in lists and other places
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <frhgpf$k84$1@ger.gmane.org>


"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20803150915l27750346g8655f596f5035c69 at mail.gmail.com...
| Thomas Wouters suggests some new syntax:

I see this as two suggestions:
1. Complete the extension of the validity of *expression syntax from 
function call/definition to expression/assignment.
2. Give *expression a related meaning in yield statements.

|
| http://bugs.python.org/issue2292
|
| >>> a, b, *c = range(5)
|
| >>> *a, b, c = a, b, *c
| >>> a, b, c
| ([0, 1, 2], 3, 4)
| >>> [ *a, b, c ]
| [0, 1, 2, 3, 4]

I understand 'f(*a)' to mean 'execute the expression as if the items of 
iterable a has been written literally in the code (with 'as if' 
optimizations allowed for special cases).  The above follow the same rule.
+1
A tutorial written for Py3 without regard to history should then introduce 
*expressions in examples like the above first, and only later the usage for 
functions, as if things had been this way all along.

| >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
| >>> [ *item for item in L ]
| [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Since above will become equivalent to list(gen_exp), I see this as being 
tied to yield *exp.

| Also, yielding everything from an iterator:
|
| >>> def flatten(iterables):
| ...     for it in iterables:
| ...         yield *it

Following the general rule above for *exp, that would be the same as yield
tuple(it).  But that is nearly useless, whereas the the implicit inner for 
loop meaning is quite useful, with, perhaps, a speedup over an explicit 
inner loop.  Since yield is already pretty magical,a bit more might not 
hurt.

But, ... what do you do with
    yield *a,b,c # a,b,c as above?
Yield a 5-tuple?  That would clash badly with 'yield *a' not yielding a 
3-tuple.
Raise an exception?  That establishes/requires a new grammatical 
category -- yield_expression.  But I would see this as preferable to the 
clash.

Terry Jan Reedy




From thomas at python.org  Sat Mar 15 23:13:54 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 15:13:54 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <frhgpf$k84$1@ger.gmane.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
Message-ID: <9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>

On Sat, Mar 15, 2008 at 2:58 PM, Terry Reedy <tjreedy at udel.edu> wrote:

>
> | Also, yielding everything from an iterator:
> |
> | >>> def flatten(iterables):
> | ...     for it in iterables:
> | ...         yield *it
>
> Following the general rule above for *exp, that would be the same as yield
> tuple(it).


No. *exp by itself is not valid syntax:

>>> a, b = *c
  File "<stdin>", line 1
SyntaxError: can use starred expression only as assignment target

It needs something to unpack *into*, in the immediate context. So,

>>> a, b = (*c,)

(or [*c]) works, but is effectively the same thing as

>>> a, b = c


>  But that is nearly useless, whereas the the implicit inner for
> loop meaning is quite useful, with, perhaps, a speedup over an explicit
> inner loop.  Since yield is already pretty magical,a bit more might not
> hurt.
>


> But, ... what do you do with
>    yield *a,b,c # a,b,c as above?
> Yield a 5-tuple?  That would clash badly with 'yield *a' not yielding a
> 3-tuple.


It yields a 5-tuple, yes. Does it help your confusion if you write it as:

 >>> yield (*a, b, c)

? The context of the unpacking operation isn't 'yield', it's the tuple you
create with the commas. If you want it to yield all the elements in a,
followed by b and c, you would need:

>>> yield *(*a, b, c)

It's quite like function arguments (except you can only specify *args after
all positional arguments, right now; Guido wants that to change anyway.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/a15d52bc/attachment.htm 

From guido at python.org  Sat Mar 15 23:21:12 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 15 Mar 2008 17:21:12 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <frhgpf$k84$1@ger.gmane.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
Message-ID: <ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>

This post does point out an inconistency in Thomas's patch:

def f():
  yield 1, 2, 3

Yields a single three-tuple.

But

def f():
  yield *[1, 2], 3

Yields three separate values.  I think this is inconsistent, since

(1, 2, 3)

and

(*[1, 2], 3)

are equivalent, and so are

yield 1, 2, 3

and

yield (1, 2, 3)

I'm not sure how to solve this except by adopting a different syntax
for the multiple-yield. Perhaps

*yield x

instead of

yield *x

???

On Sat, Mar 15, 2008 at 4:58 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>  "Guido van Rossum" <guido at python.org> wrote in message
>  news:ca471dc20803150915l27750346g8655f596f5035c69 at mail.gmail.com...
>
> | Thomas Wouters suggests some new syntax:
>
>  I see this as two suggestions:
>  1. Complete the extension of the validity of *expression syntax from
>  function call/definition to expression/assignment.
>  2. Give *expression a related meaning in yield statements.
>
>
>  |
>  | http://bugs.python.org/issue2292
>  |
>  | >>> a, b, *c = range(5)
>  |
>  | >>> *a, b, c = a, b, *c
>  | >>> a, b, c
>  | ([0, 1, 2], 3, 4)
>  | >>> [ *a, b, c ]
>  | [0, 1, 2, 3, 4]
>
>  I understand 'f(*a)' to mean 'execute the expression as if the items of
>  iterable a has been written literally in the code (with 'as if'
>  optimizations allowed for special cases).  The above follow the same rule.
>  +1
>  A tutorial written for Py3 without regard to history should then introduce
>  *expressions in examples like the above first, and only later the usage for
>  functions, as if things had been this way all along.
>
>
>  | >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>  | >>> [ *item for item in L ]
>  | [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
>  Since above will become equivalent to list(gen_exp), I see this as being
>  tied to yield *exp.
>
>
>  | Also, yielding everything from an iterator:
>  |
>  | >>> def flatten(iterables):
>  | ...     for it in iterables:
>  | ...         yield *it
>
>  Following the general rule above for *exp, that would be the same as yield
>  tuple(it).  But that is nearly useless, whereas the the implicit inner for
>  loop meaning is quite useful, with, perhaps, a speedup over an explicit
>  inner loop.  Since yield is already pretty magical,a bit more might not
>  hurt.
>
>  But, ... what do you do with
>     yield *a,b,c # a,b,c as above?
>  Yield a 5-tuple?  That would clash badly with 'yield *a' not yielding a
>  3-tuple.
>  Raise an exception?  That establishes/requires a new grammatical
>  category -- yield_expression.  But I would see this as preferable to the
>  clash.
>
>  Terry Jan Reedy
>
>
>
>
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From thomas at python.org  Sun Mar 16 00:01:38 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 16:01:38 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
Message-ID: <9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>

On Sat, Mar 15, 2008 at 3:21 PM, Guido van Rossum <guido at python.org> wrote:

> This post does point out an inconistency in Thomas's patch:
>
> def f():
>  yield 1, 2, 3
>
> Yields a single three-tuple.
>
> But
>
> def f():
>  yield *[1, 2], 3
>
> Yields three separate values.


Uhm, what? It doesn't, and it shouldn't, and I'm not sure what makes you
think it does.

>>> def f():
...     yield *[1, 2], 3
...
>>> list(f())
[(1, 2, 3)]

The comma makes the argument to 'yield' a single item (a tuple) and the '*'
is part of the item in the tuple. In other words, the * binds more tightly
than the comma (which is not something I changed; the parser already worked
this way and it's necessary for '*a, b, c = ..' to even work.  'yield *[1,
2], 3' is parsed as 'yield (*[1, 2], 3)', not 'yield *([1, 2], 3)'. What you
suggest (three separate values) requires 'yield *(*[1, 2], 3)'.

>>> def f1():
...     yield (*[1, 2], 3)
...
>>> list(f1())
[(1, 2, 3)]

>>> def f2():
...     yield *([1, 2], 3)
...
>>> list(f2())
[[1, 2], 3]

>>> def f3():
...     yield *(*[1, 2], 3)
...
>>> list(f3())
[1, 2, 3]

  I think this is inconsistent, since
>
> (1, 2, 3)
>
> and
>
> (*[1, 2], 3)
>
> are equivalent, and so are
>
> yield 1, 2, 3
>
> and
>
> yield (1, 2, 3)


Yes, they are indeed all equivalent :-)


>
>
> I'm not sure how to solve this except by adopting a different syntax
> for the multiple-yield. Perhaps
>
> *yield x
>
> instead of
>
> yield *x
>
> ???


If there really were an inconsistency here, I would certainly not suggest
fixing it that way, yuuueghh.


>
> On Sat, Mar 15, 2008 at 4:58 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> >
> >  "Guido van Rossum" <guido at python.org> wrote in message
> >  news:ca471dc20803150915l27750346g8655f596f5035c69 at mail.gmail.com...
> >
> > | Thomas Wouters suggests some new syntax:
> >
> >  I see this as two suggestions:
> >  1. Complete the extension of the validity of *expression syntax from
> >  function call/definition to expression/assignment.
> >  2. Give *expression a related meaning in yield statements.
> >
> >
> >  |
> >  | http://bugs.python.org/issue2292
> >  |
> >  | >>> a, b, *c = range(5)
> >  |
> >  | >>> *a, b, c = a, b, *c
> >  | >>> a, b, c
> >  | ([0, 1, 2], 3, 4)
> >  | >>> [ *a, b, c ]
> >  | [0, 1, 2, 3, 4]
> >
> >  I understand 'f(*a)' to mean 'execute the expression as if the items of
> >  iterable a has been written literally in the code (with 'as if'
> >  optimizations allowed for special cases).  The above follow the same
> rule.
> >  +1
> >  A tutorial written for Py3 without regard to history should then
> introduce
> >  *expressions in examples like the above first, and only later the usage
> for
> >  functions, as if things had been this way all along.
> >
> >
> >  | >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
> >  | >>> [ *item for item in L ]
> >  | [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> >
> >  Since above will become equivalent to list(gen_exp), I see this as
> being
> >  tied to yield *exp.
> >
> >
> >  | Also, yielding everything from an iterator:
> >  |
> >  | >>> def flatten(iterables):
> >  | ...     for it in iterables:
> >  | ...         yield *it
> >
> >  Following the general rule above for *exp, that would be the same as
> yield
> >  tuple(it).  But that is nearly useless, whereas the the implicit inner
> for
> >  loop meaning is quite useful, with, perhaps, a speedup over an explicit
> >  inner loop.  Since yield is already pretty magical,a bit more might not
> >  hurt.
> >
> >  But, ... what do you do with
> >     yield *a,b,c # a,b,c as above?
> >  Yield a 5-tuple?  That would clash badly with 'yield *a' not yielding a
> >  3-tuple.
> >  Raise an exception?  That establishes/requires a new grammatical
> >  category -- yield_expression.  But I would see this as preferable to
> the
> >  clash.
> >
> >  Terry Jan Reedy
> >
> >
> >
> >
> >  _______________________________________________
> >  Python-3000 mailing list
> >  Python-3000 at python.org
> >  http://mail.python.org/mailman/listinfo/python-3000
> >  Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/thomas%40python.org
>



-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/7368a957/attachment-0001.htm 

From murman at gmail.com  Sun Mar 16 00:33:53 2008
From: murman at gmail.com (Michael Urman)
Date: Sat, 15 Mar 2008 18:33:53 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
Message-ID: <dcbbbb410803151633q13a43905kc9487dc97909e3c3@mail.gmail.com>

> > I'm not sure how to solve this except by adopting a different syntax
> > for the multiple-yield. Perhaps
> >
> > *yield x
>
> If there really were an inconsistency here, I would certainly not suggest
> fixing it that way, yuuueghh.

Agreed about *yield looking yucky. In a previous thread somewhere
around http://mail.python.org/pipermail/python-dev/2006-January/059955.html
a construct like "yield from x" was offered. It certainly helps
clarify the difference between iteratively yielding the values from
another iterator and yielding the values of an iterator as a tuple.
While parsing rules do differentiate, I don't find the behavior
obvious, and expect the differences between
    yield *x; yield *x(); yield *x,; yield (*x,); and yield *(x,)
would become one of python's warts in a few years, if adopted. In
short, I don't think * should be the syntax for iterative-yielding.

That said, all these star extensions call to me, especially
arbitrarily positioned *args in function calls and iteratively
yielding items from another iterator. But I can't offer any use new
cases.
-- 
Michael Urman

From pje at telecommunity.com  Sun Mar 16 00:55:11 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 15 Mar 2008 19:55:11 -0400
Subject: [Python-3000] Using *a for packing in lists and other  places
In-Reply-To: <dcbbbb410803151633q13a43905kc9487dc97909e3c3@mail.gmail.co
 m>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<dcbbbb410803151633q13a43905kc9487dc97909e3c3@mail.gmail.com>
Message-ID: <20080315235627.076D13A40D7@sparrow.telecommunity.com>

At 06:33 PM 3/15/2008 -0500, Michael Urman wrote:
> > > I'm not sure how to solve this except by adopting a different syntax
> > > for the multiple-yield. Perhaps
> > >
> > > *yield x
> >
> > If there really were an inconsistency here, I would certainly not suggest
> > fixing it that way, yuuueghh.
>
>Agreed about *yield looking yucky. In a previous thread somewhere
>around http://mail.python.org/pipermail/python-dev/2006-January/059955.html
>a construct like "yield from x" was offered. It certainly helps
>clarify the difference between iteratively yielding the values from
>another iterator and yielding the values of an iterator as a tuple.
>While parsing rules do differentiate, I don't find the behavior
>obvious, and expect the differences between
>     yield *x; yield *x(); yield *x,; yield (*x,); and yield *(x,)
>would become one of python's warts in a few years, if adopted.

After following this thread for a bit, I think it's a wart 
already.  :)  The potential for confusion with the other *assign 
target idea is too high.

I don't have a problem with "item for *item,val in blah", but "*item 
for item in blah" makes my head hurt.  Why not just say "i2 for i1 in 
blah for i2 in i1"?  Yes, it's a bit more verbose, but not frequent 
enough to justify the *, and you can tell what's going on by 
textually transposing to the nested for loops.  Plus, it works for 
any depth.  What are you going to do if it's triple-nested?  Use 
**?  What about ***?  Where does it end?

So I think "yield *" and "*item for item in..." are broken for the 
same reason.  In the function call use case, and in simple 
assignment, it is treated as a literal quasi-textual 
expansion.  However, such an expansion in the yield case would yield 
a tuple, and the literal expansion in the comprehension case would 
make no sense.  (If done by true textual substitution, it would have 
to be a syntax error.)

And I think that a quasi-textual substitution is the right mental 
model for * expressions, as it's simple to explain and easy to reason 
out what happens.


From lists at cheimes.de  Sun Mar 16 01:00:23 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 16 Mar 2008 01:00:23 +0100
Subject: [Python-3000] svnmerge - three broken tests
Message-ID: <frhnuu$64u$1@ger.gmane.org>

Hi guys!

I hope you all have fun at PyCon! I hope I'll be able to attend to PyCon
next year.

I've spent the better part of the evening to merge changes from the
trunk into py3k for the sprint. I got all tests except of three to pass:

   test_datetime test_struct test_tokenize

Have fun!

Christian


From charles.merriam at gmail.com  Sun Mar 16 02:06:51 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sat, 15 Mar 2008 20:06:51 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <20080315235627.076D13A40D7@sparrow.telecommunity.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<dcbbbb410803151633q13a43905kc9487dc97909e3c3@mail.gmail.com>
	<20080315235627.076D13A40D7@sparrow.telecommunity.com>
Message-ID: <b8c6f6c40803151806r439e1e56g8099c9f5c091e780@mail.gmail.com>

-1.

While the syntax has a basic beauty, it requires too much odd explanation.
"*" and "**" are already binary operators.
The '*' unary operator can confuse migrating programmers already.
It makes puzzles too easy, e.g.,  yield **[2**3*i, for i in range(2*3**4)]




On Sat, Mar 15, 2008 at 6:55 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 06:33 PM 3/15/2008 -0500, Michael Urman wrote:
>  > > > I'm not sure how to solve this except by adopting a different syntax
>  > > > for the multiple-yield. Perhaps
>  > > >
>  > > > *yield x
>  > >
>  > > If there really were an inconsistency here, I would certainly not suggest
>  > > fixing it that way, yuuueghh.
>  >
>  >Agreed about *yield looking yucky. In a previous thread somewhere
>  >around http://mail.python.org/pipermail/python-dev/2006-January/059955.html
>  >a construct like "yield from x" was offered. It certainly helps
>  >clarify the difference between iteratively yielding the values from
>  >another iterator and yielding the values of an iterator as a tuple.
>  >While parsing rules do differentiate, I don't find the behavior
>  >obvious, and expect the differences between
>  >     yield *x; yield *x(); yield *x,; yield (*x,); and yield *(x,)
>  >would become one of python's warts in a few years, if adopted.
>
>  After following this thread for a bit, I think it's a wart
>  already.  :)  The potential for confusion with the other *assign
>  target idea is too high.
>
>  I don't have a problem with "item for *item,val in blah", but "*item
>  for item in blah" makes my head hurt.  Why not just say "i2 for i1 in
>  blah for i2 in i1"?  Yes, it's a bit more verbose, but not frequent
>  enough to justify the *, and you can tell what's going on by
>  textually transposing to the nested for loops.  Plus, it works for
>  any depth.  What are you going to do if it's triple-nested?  Use
>  **?  What about ***?  Where does it end?
>
>  So I think "yield *" and "*item for item in..." are broken for the
>  same reason.  In the function call use case, and in simple
>  assignment, it is treated as a literal quasi-textual
>  expansion.  However, such an expansion in the yield case would yield
>  a tuple, and the literal expansion in the comprehension case would
>  make no sense.  (If done by true textual substitution, it would have
>  to be a syntax error.)
>
>  And I think that a quasi-textual substitution is the right mental
>  model for * expressions, as it's simple to explain and easy to reason
>  out what happens.
>
>
>
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>

From greg.ewing at canterbury.ac.nz  Sun Mar 16 02:07:30 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 13:07:30 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151403x4c6342b1n1fa41b1d6b0c2b37@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC139F.5000800@gmail.com>
	<de9ae4950803151244y751e2c40j7eb09be1c161d8c6@mail.gmail.com>
	<9e804ac0803151403x4c6342b1n1fa41b1d6b0c2b37@mail.gmail.com>
Message-ID: <47DC72D2.8060100@canterbury.ac.nz>

Thomas Wouters wrote:
> 
> I do not think 
> collecting a (potentially ever-growing) list of results is really the 
> right thing to do, do you?

For those cases where it is, perhaps one should be
able to write

   [yield *it]

and have it treated as a kind of list comprehension.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar 16 02:07:24 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 13:07:24 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <47DC72CC.4050603@canterbury.ac.nz>

Guido van Rossum wrote:
> Thomas Wouters suggests some new syntax:

>>>>a, b, *c = range(5)

+1 on this.

>>>>*a, b, c = a, b, *c

+0 on allowing * in other than the last position.

> ...     for it in iterables:
> ...         yield *it

+0.5 (due to consistency problems pointed out in others'
comments).

A thought - part of me wants to rewrite the above as

   yield **it

i.e. each * wraps an implicit for loop around
the yield.

-- 
Greg

From thomas at python.org  Sun Mar 16 02:46:58 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 15 Mar 2008 18:46:58 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DC72CC.4050603@canterbury.ac.nz>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC72CC.4050603@canterbury.ac.nz>
Message-ID: <9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>

On Sat, Mar 15, 2008 at 6:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Guido van Rossum wrote:
> > Thomas Wouters suggests some new syntax:
>
> >>>>a, b, *c = range(5)
>
> +1 on this.
>
> >>>>*a, b, c = a, b, *c
>
> +0 on allowing * in other than the last position.
>

The left-hand side of all this is already in. Only the rhs is new.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080315/e0652e97/attachment.htm 

From talin at acm.org  Sun Mar 16 02:51:21 2008
From: talin at acm.org (Talin)
Date: Sat, 15 Mar 2008 18:51:21 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <47DC7D19.6080406@acm.org>



Guido van Rossum wrote:
> Also, yielding everything from an iterator:
> 
>>>> def flatten(iterables):
> ...     for it in iterables:
> ...         yield *it
> ...
>>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>>> flatten(L)
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> 
> What do people think?

(re-sending to the correct place - thanks Guido)

I've suggested something similar a while back:

http://mail.python.org/pipermail/python-list/2005-October/348485.html

At one point I was working on a algorithmic solver for mathematical 
equations using recursive generators to do backtracking search; being 
able to yield an entire generator's worth of output would have 
simplified it considerably.

Also, there's a potential optimization - if a generator is yielding the 
entire output of another generator, it might be possible to 'cut out the 
middleman' and have the ultimate consumer of the values read the 
innermost generator directly. I don't know how feasible that is, however.

All that being said: Using generators to implement backtracking search 
is much nicer than trying to do it with regular recursion and callbacks; 
But even nicer would be true coroutines.

Take for example the solver I mentioned, which basically is a unifier. 
What it does is take two trees (composed of nested tuples) and 
recursively walks them, matching as it goes. At each level, there may be 
several possible ways of doing a match; The algorithm iterates through 
each of these possibilities, invoking the lower-level matchers once for 
each possibility. The lower-level matcher may in turn find several 
possible matches, or may find none (meaning that the upper-level 
possibility didn't pan out.)

When the algorithm gets to a leaf, it yields a result. The caller of the 
algorithm receives essentially a stream of answers, which it can read as 
many or as few as it wishes.

Since generators can't operate across multiple stack frames, the way to 
construct this algorithm is to have each sub-matcher yield all of its 
answers to its parent. This is where the 'yield *' syntax comes in.

In the case of the equation solver, the 'answers' consist of possible 
variable bindings. So given the inputs 'x? + y?' and '1 + 2 + 3', the 
stream of answers is (applying the associative rule):

     (x = 1, y = 2 + 3)
     (x = 1 + 2, y = 3)
     ...and so on

Now, one final comment: PEP 342 promises that the new yield semantics 
can be used to implement true coroutines. But I don't see how to 
actually make that work. Has anyone actually done this?

-- Talin

From skip at pobox.com  Sun Mar 16 04:57:27 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 15 Mar 2008 22:57:27 -0500
Subject: [Python-3000] svnmerge - three broken tests
In-Reply-To: <frhnuu$64u$1@ger.gmane.org>
References: <frhnuu$64u$1@ger.gmane.org>
Message-ID: <18396.39591.925075.453159@montanaro-dyndns-org.local>


    Christian> I've spent the better part of the evening to merge changes
    Christian> from the trunk into py3k for the sprint. I got all tests
    Christian> except of three to pass:

    Christian>    test_datetime test_struct test_tokenize

Christian,

I checked in a change to datetime today.  Might that have caused your
problems with test_datetime?  Is your merge checked in so I can have a look?

Skip


From greg.ewing at canterbury.ac.nz  Sun Mar 16 02:07:36 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 13:07:36 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
Message-ID: <47DC72D8.3010909@canterbury.ac.nz>

Thomas Wouters wrote:
>  >>> a, b = *c
>   File "<stdin>", line 1
> SyntaxError: can use starred expression only as assignment target

That error message isn't really accurate, since in

>  >>> a, b = (*c,)

the *c is not an assignment target.

Also, the message implies that

   *c = a, b

should be valid -- is it?

-- 
Greg

From dickinsm at gmail.com  Sun Mar 16 05:45:19 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 16 Mar 2008 00:45:19 -0400
Subject: [Python-3000] svnmerge - three broken tests
In-Reply-To: <frhnuu$64u$1@ger.gmane.org>
References: <frhnuu$64u$1@ger.gmane.org>
Message-ID: <5c6f2a5d0803152145l1bed6601l269cbf5778fd0d2c@mail.gmail.com>

On Sat, Mar 15, 2008 at 8:00 PM, Christian Heimes <lists at cheimes.de> wrote:

>
>   test_datetime test_struct test_tokenize
>

I think I've fixed test_datetime and test_struct.  I'm less sure what to do
for test_tokenize;  the main cause of failure seems to be doctests
containing syntax that was valid for 2.x but is invalid for 3.0 (e.g.
integer literals with a leading '0' or trailing 'L', 2.x style unicode
literals, ...).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/f0938f44/attachment.htm 

From ntoronto at cs.byu.edu  Sun Mar 16 05:51:34 2008
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Sat, 15 Mar 2008 22:51:34 -0600
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
Message-ID: <47DCA756.2040907@cs.byu.edu>

Thomas Wouters wrote:
> 
> On Sat, Mar 15, 2008 at 2:58 PM, Terry Reedy <tjreedy at udel.edu 
> <mailto:tjreedy at udel.edu>> wrote:
> 
>     | Also, yielding everything from an iterator:
>     |
>     | >>> def flatten(iterables):
>     | ...     for it in iterables:
>     | ...         yield *it
> 
>     Following the general rule above for *exp, that would be the same as
>     yield
>     tuple(it).
> 
> No. *exp by itself is not valid syntax:

Why isn't it? I'd rather have one meaning for the *-prefix operator with 
a single special case for assignment targets, than have a bunch of 
special cases scattered across the grammar.

Besides, as the SmugLispWeenies have noted, Python is becoming more like 
Lisp all the time:

     (setq obj '(an ex-parrot))  ; (AN EX-PARROT)
     `(I have ,obj)              ; (I HAVE (AN EX-PARROT))
     `(I have , at obj)             ; (I HAVE AN EX-PARROT)

Why not hasten the transformation? :p

(Only kidding!)

Neil


From dickinsm at gmail.com  Sun Mar 16 06:08:21 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 16 Mar 2008 01:08:21 -0400
Subject: [Python-3000] svnmerge - three broken tests
In-Reply-To: <frhnuu$64u$1@ger.gmane.org>
References: <frhnuu$64u$1@ger.gmane.org>
Message-ID: <5c6f2a5d0803152208m28f5792ckd21914319584336e@mail.gmail.com>

I think test_tokenize is now fixed, too.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/150d5594/attachment.htm 

From greg.ewing at canterbury.ac.nz  Sun Mar 16 06:57:23 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 17:57:23 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <b8c6f6c40803151806r439e1e56g8099c9f5c091e780@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<dcbbbb410803151633q13a43905kc9487dc97909e3c3@mail.gmail.com>
	<20080315235627.076D13A40D7@sparrow.telecommunity.com>
	<b8c6f6c40803151806r439e1e56g8099c9f5c091e780@mail.gmail.com>
Message-ID: <47DCB6C3.9090105@canterbury.ac.nz>

Charles Merriam wrote:
> -1.
> 
> While the syntax has a basic beauty, it requires too much odd explanation.

On further reflection, I think I would only be in
favour of 'yield *it' if it permitted an optimisation
allowing it to run more efficently than an explicit
for-loop.

In the absence of any such optimisation, writing the
for-loop out explicitly seems preferable. Not only
does it make it perfectly clear what is being done,
it avoids hiding the cost of the for-loop behind a
deceptively compact piece of syntax.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar 16 07:26:13 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 18:26:13 +1200
Subject: [Python-3000] Optimising nested generators
In-Reply-To: <47DC7D19.6080406@acm.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC7D19.6080406@acm.org>
Message-ID: <47DCBD85.6090604@canterbury.ac.nz>

Talin wrote:
> 
> if a generator is yielding the 
> entire output of another generator, it might be possible to 'cut out the 
> middleman' and have the ultimate consumer of the values read the 
> innermost generator directly.

On the face of things, it certainly seems as though such a thing
*ought* to be possible. It would require keeping a stack of
generators somewhere, although I'm not sure exactly where.

Perhaps each generator frame could have a "referral" slot
which can contain a reference to another iterator. When a
generator hits a "yield *" statement, it puts the argument
into its referral slot.

Then, the next() method of a generator would first run
down the chain of referral slots until it gets to the
end (either a generator with nothing in its referral slot,
or a non-generator iterator), and resume the iterator found
there. If it's found to be exhausted, you would back up to
the previous one and resume that, etc., until you either
get a value or the outermost generator is exhausted.

Does that sound like it would be workable?

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Mar 16 07:26:20 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 16 Mar 2008 18:26:20 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC72CC.4050603@canterbury.ac.nz>
	<9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>
Message-ID: <47DCBD8C.5000307@canterbury.ac.nz>

Thomas Wouters wrote:
> 
> On Sat, Mar 15, 2008 at 6:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz 
> <mailto:greg.ewing at canterbury.ac.nz>> wrote:
> 
>      >>>>*a, b, c = a, b, *c
> 
>     +0 on allowing * in other than the last position.
> 
> The left-hand side of all this is already in. Only the rhs is new.

I'm worried that allowing things like

   x = a, b, *c, d, *e, f

is going to make people want to do this in a function
call as well. Does your patch permit that, or only
when constructing a tuple?

-- 
Greg

From arnodel at googlemail.com  Sun Mar 16 07:58:24 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Sun, 16 Mar 2008 06:58:24 +0000
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
Message-ID: <A580DC8A-1719-494C-A3F1-4BB809122855@gmail.com>


On 15 Mar 2008, at 16:15, Guido van Rossum wrote:

> Thomas Wouters suggests some new syntax:
>
> http://bugs.python.org/issue2292
>
>>>> a, b, *c = range(5)
>
>>>> *a, b, c = a, b, *c
>>>> a, b, c
> ([0, 1, 2], 3, 4)
>>>> [ *a, b, c ]
> [0, 1, 2, 3, 4]
>>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>>> [ *item for item in L ]
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> Also, yielding everything from an iterator:
>
>>>> def flatten(iterables):
> ...     for it in iterables:
> ...         yield *it
> ...
>>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>>> flatten(L)
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> What do people think?

With this syntax, one will be able to write:

 >>> t = (1, 2, 3)
 >>> [*t]
[1, 2, 3]
 >>> {*t}
{1, 2, 3}

Will these become idioms replacing list(), tuple(), set()?

Moreover the '*' also competes with the '+' operator:

 >>> t = (1, 2)
 >>> l = [1, 3]
 >>> [*t, *l] # replaces list(t) + l
[1, 2, 1, 3]
 >>> {*t, *l} # replaces set(t) + set(l)
{1, 2, 3}
 >>> (*t, *l) # replaces t + tuple(l)
(1, 2, 1, 3)

It is more versatile because, for example, t + l wouldn't work.  I
don't know how desirable it is.

-- 
Arnaud


From g.brandl at gmx.net  Sun Mar 16 11:20:16 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 16 Mar 2008 11:20:16 +0100
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DCA756.2040907@cs.byu.edu>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>	<frhgpf$k84$1@ger.gmane.org>	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<47DCA756.2040907@cs.byu.edu>
Message-ID: <fris8i$fv0$1@ger.gmane.org>

Neil Toronto schrieb:

> Besides, as the SmugLispWeenies have noted, Python is becoming more like 
> Lisp all the time:
> 
>      (setq obj '(an ex-parrot))  ; (AN EX-PARROT)
>      `(I have ,obj)              ; (I HAVE (AN EX-PARROT))
>      `(I have , at obj)             ; (I HAVE AN EX-PARROT)

Only prettier.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Sun Mar 16 13:58:43 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 16 Mar 2008 13:58:43 +0100
Subject: [Python-3000] getargs.c
Message-ID: <frj5hm$91a$1@ger.gmane.org>

(See also Issue 2298)

String/Unicode/Bytes handling in getargs.c is in dire need of some
love; also the docs need to be made consistent with the implementation
w.r.t. where a string/unicode is needed, whether null bytes are allowed,
etc.

Perhaps something for the PyCon sprint?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From pje at telecommunity.com  Sun Mar 16 13:57:40 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 16 Mar 2008 08:57:40 -0400
Subject: [Python-3000] True Coroutines (was Re: Using *a for packing in
 lists and other places)
In-Reply-To: <47DC7D19.6080406@acm.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC7D19.6080406@acm.org>
Message-ID: <20080316125942.5B3783A40C1@sparrow.telecommunity.com>

At 06:51 PM 3/15/2008 -0700, Talin wrote:
>Now, one final comment: PEP 342 promises that the new yield semantics
>can be used to implement true coroutines. But I don't see how to
>actually make that work. Has anyone actually done this?

http://peak.telecommunity.com/DevCenter/TrellisActivity#co-operative-multitasking

http://peak.telecommunity.com/DevCenter/TrellisActivity#invoking-subtasks


There are other packages in the Cheeseshop that do something like 
this too, I believe. 


From guido at python.org  Sun Mar 16 14:51:20 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 08:51:20 -0500
Subject: [Python-3000] 2.6 and 3.0 project management
Message-ID: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>

Python 3.0 and 2.6 are coming along really nice. I am optimistic that
we can make the projected August date for the final releases of 2.6
and 3.0. As you may remember, Barry (the new release manager for both)
suggested that we synchronize releases of 2.6 and 3.0. Not only could
this potentially save the release manager and his assistants some
time, doing the final releases together sends a clear signal to the
community that both versions will receive equal support.

However, looking at the calendar, I think we need to do a little more
planning and management than we've typically done for Python releases.
A final release in August means that we should plan to release a first
beta in June and a second one in July. That means we have time for
only two more alpha releases (April and May). I'm thinking of 1-2
release candidates 1-2 weeks ahead of the final release. Barry can
make up a more detailed timetable. I'm fine with some slippage
(especially if planned ahead) of individual releases due to
availability of release personnel; but I don't want to be held up by
features or bugs unless they are of absolutely dramatic show-stopping
nature.

In order to make such a tight release schedule we should try to come
up with a list of tasks that need to be done, and prioritize them.
This should include documentation, and supporting tools like 2to3. It
should include features, backports of features, cleanup, bugs, and
whatever else needs to be done (e.g. bugbot maintenance).

In the past we've used shared spreadsheets in Google for this purpose,
but seeing that these haven't been updated in ages, I'm skeptical that
they are a sufficient tool. In my day job at Google we've started to
do all task management for our project in the bug tracker (but that
tracker has some features that make it particularly easy). Does anyone
have a suggestion for an online open shared task management system
that we cold adopt? Or should we bite the bullet and put everything in
the bug tracker? Other suggestions? Anything's better than just
email...

PS. I realize that I've been rather absent from the day to day
activities in the Python 3000 world lately. This is a temporary
condition due to an important impending launch in my day job; I expect
to have much more time for Python again starting in April.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From facundobatista at gmail.com  Sun Mar 16 15:01:27 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sun, 16 Mar 2008 09:01:27 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>

2008/3/16, Guido van Rossum <guido at python.org>:

>  they are a sufficient tool. In my day job at Google we've started to
>  do all task management for our project in the bug tracker (but that
>  tracker has some features that make it particularly easy). Does anyone

Like which? Something that could be added to our tracker in a short time?

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From guido at python.org  Sun Mar 16 15:18:27 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 09:18:27 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>
Message-ID: <ca471dc20803160718k4255a73eg68238da2570c056b@mail.gmail.com>

On Sun, Mar 16, 2008 at 9:01 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/3/16, Guido van Rossum <guido at python.org>:
>  >  they are a sufficient tool. In my day job at Google we've started to
>  >  do all task management for our project in the bug tracker (but that
>  >  tracker has some features that make it particularly easy). Does anyone
>
>  Like which? Something that could be added to our tracker in a short time?

It has a much more detailed set of categories, organized as a tree.
Our project alone probably has 20-30 different bug categories. New
bugs in those categories are automatically CC'ed to our group's
mailing list (which isn't the same as auto-assignment).

There are also more "bug states" you can use to track progress of a
bug through the system: unassigned, assigned, accepted (meaning the
assignee is actually working on it). (There are also a whole bunch
that I don't find so useful, and severam that roundup already
supports.)

But perhaps the best feature is "hot lists" -- arbitrary, ordered,
groupings of selected bugs. Each bug can be assigned to as many hot
lists as you want. Seeing the list of all bugs in a particular hot
list is one click away. We use this for overlaying project management
categories and priorities, such as "code", "documentation",
"configuration" as well as "next internal release", "must have", "post
launch" etc.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From skip at pobox.com  Sun Mar 16 15:31:25 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 16 Mar 2008 09:31:25 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160718k4255a73eg68238da2570c056b@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>
	<ca471dc20803160718k4255a73eg68238da2570c056b@mail.gmail.com>
Message-ID: <18397.12093.765076.737023@montanaro-dyndns-org.local>


    Guido> It has a much more detailed set of categories, organized as a
    Guido> tree.  Our project alone probably has 20-30 different bug
    Guido> categories. New bugs in those categories are automatically CC'ed
    Guido> to our group's mailing list (which isn't the same as
    Guido> auto-assignment).

Adding categories should be easy.  Organized in trees?  Not so sure.

    Guido> There are also more "bug states" you can use to track progress of
    Guido> a bug through the system: unassigned, assigned, accepted (meaning
    Guido> the assignee is actually working on it). (There are also a whole
    Guido> bunch that I don't find so useful, and severam that roundup
    Guido> already supports.)

Again, I think this should be easy.

    Guido> But perhaps the best feature is "hot lists" -- arbitrary,
    Guido> ordered, groupings of selected bugs. Each bug can be assigned to
    Guido> as many hot lists as you want. Seeing the list of all bugs in a
    Guido> particular hot list is one click away. We use this for overlaying
    Guido> project management categories and priorities, such as "code",
    Guido> "documentation", "configuration" as well as "next internal
    Guido> release", "must have", "post launch" etc.

A hot list sounds like a saved search, which Roundup already supports.  It
also supports making these saved searches public.  I suspect you could
define one or more saved public searches which correspond to desired hot
lists.

Aside: Today's my last day here.  I'd like to say hi sometime today.  Free
for lunch?  Maybe this would be a good lunchtime discussion.

Skip

From thomas at python.org  Sun Mar 16 15:32:20 2008
From: thomas at python.org (Thomas Wouters)
Date: Sun, 16 Mar 2008 07:32:20 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DC72D8.3010909@canterbury.ac.nz>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<47DC72D8.3010909@canterbury.ac.nz>
Message-ID: <9e804ac0803160732i13a47a61q5fe0f93e32796701@mail.gmail.com>

On Sat, Mar 15, 2008 at 6:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Thomas Wouters wrote:
> >  >>> a, b = *c
> >   File "<stdin>", line 1
> > SyntaxError: can use starred expression only as assignment target
>
> That error message isn't really accurate, since in
>
> >  >>> a, b = (*c,)


> the *c is not an assignment target.
>

Dear lord, give me a chance to fix up all the details before you trip over
things like that. I wrote the patch for load-context-star in half a day at
pycon, I didn't bother to update the error message yet.


> Also, the message implies that
>
>   *c = a, b
>
> should be valid -- is it?
>

No, but that's not related to this patch (but rather the PEP-3132
implementation.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/5ea82fc7/attachment.htm 

From thomas at python.org  Sun Mar 16 15:35:51 2008
From: thomas at python.org (Thomas Wouters)
Date: Sun, 16 Mar 2008 07:35:51 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DCBD8C.5000307@canterbury.ac.nz>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC72CC.4050603@canterbury.ac.nz>
	<9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>
	<47DCBD8C.5000307@canterbury.ac.nz>
Message-ID: <9e804ac0803160735x62b5e268gc0c6e03c6f6b0338@mail.gmail.com>

On Sat, Mar 15, 2008 at 11:26 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Thomas Wouters wrote:
> >
> > On Sat, Mar 15, 2008 at 6:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz
> > <mailto:greg.ewing at canterbury.ac.nz>> wrote:
> >
> >      >>>>*a, b, c = a, b, *c
> >
> >     +0 on allowing * in other than the last position.
> >
> > The left-hand side of all this is already in. Only the rhs is new.
>
> I'm worried that allowing things like
>
>   x = a, b, *c, d, *e, f
>
> is going to make people want to do this in a function
> call as well. Does your patch permit that, or only
> when constructing a tuple?
>

The patch does not, yet. Guido did ask that it would work. (To be precise,
he asked for 'f(*a, b, c)' to be valid, but it only makes sense to allow,
say, 'f(*a, b, *c)' too, and he hasn't said 'no' to that.) However, the
grammar for functiondefinitions and -calls is entirely separate from the
other unpacking contexts, and modifying the grammer is hard; I'm not done
with it yet.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/731feb62/attachment-0001.htm 

From lists at cheimes.de  Sun Mar 16 15:42:21 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 16 Mar 2008 15:42:21 +0100
Subject: [Python-3000] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <47DD31CD.9030008@cheimes.de>

Guido van Rossum wrote:
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).

I did a quick brainstorming with me, myself and I. I came up with a list
of (IMHO) important tasks.

* Stabilize the C API of Python 3.0. I like to rename several prefixes
to reduce the confusing: PyBytes -> PyByteArray, PyString -> PyBytes ...

* Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
and he said he is trying to get it done during the PyCon sprint. Maybe
somebody can assist him?
When the new buffer protocol is available in 2.6 we can start back
porting bytesarray and the new IO framework.

* Replace Windows API calls with wide versions to support unicode for
file names, environment etc.

* Get the stdlib reorg done and add the fixers to 2to3

* Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
but it may be too late when we plan to ship out 3.0 in August.

Christian

From thomas at python.org  Sun Mar 16 15:54:28 2008
From: thomas at python.org (Thomas Wouters)
Date: Sun, 16 Mar 2008 07:54:28 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DCA756.2040907@cs.byu.edu>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<47DCA756.2040907@cs.byu.edu>
Message-ID: <9e804ac0803160754o56712fbejc67e097ed53dc5d0@mail.gmail.com>

On Sat, Mar 15, 2008 at 9:51 PM, Neil Toronto <ntoronto at cs.byu.edu> wrote:

> Thomas Wouters wrote:
> >
> > On Sat, Mar 15, 2008 at 2:58 PM, Terry Reedy <tjreedy at udel.edu
> > <mailto:tjreedy at udel.edu>> wrote:
> >
> >     | Also, yielding everything from an iterator:
> >     |
> >     | >>> def flatten(iterables):
> >     | ...     for it in iterables:
> >     | ...         yield *it
> >
> >     Following the general rule above for *exp, that would be the same as
> >     yield
> >     tuple(it).
> >
> > No. *exp by itself is not valid syntax:
>
> Why isn't it? I'd rather have one meaning for the *-prefix operator with
> a single special case for assignment targets, than have a bunch of
> special cases scattered across the grammar.
>

Ehm, the only specialcases in the grammar are for *args and **kwargs in
functiondefinitions and functioncalls. There is no specialcase for *exp in
either store-context or load-context -- as a matter of fact, the patch to
add unpacking in load-context doesn't change the grammar at all.

That *exp by itself is not valid syntax is not new in this patch (PEP-3132
specifies it that way,) and it's easily explained: what the heck would it
mean? How does

t = a, b, c

differ from

*t = a, b, c

? In the exact same way, a lone '*exp' in load-context doesn't mean
anything. The 'unpacking' unpacks into the surrounding context, and without
context it's unclear what the result will be. To clarify,

{*a, b, c, *d} -> a set (dupes removed, order lost)
{*a} -> same
[*a, b, c, *d] -> a list (dupes intact, order intact)
[*a] -> same
(*a, b, c, *d) -> a tuple (dupes intact, order intact)
*a, b, c, *d -> same
(*a,) -> same
*a, -> same (but horrible style)
*a -> ?

The final reduction of (*a, b) is not *a, it's (*a,), just like is the case
for (a, b) and (a,). You can say '*exp by itself always unpacks into a
list', which Guido argued last night over beer, but that leave that

*a = z
a = *z

do the exact same thing (and the exact same thing as 'a = list(z)' but
something quite subtly but importantly different from 'a = z'), and

a, b, c = *z

differs in no way from

a, b, c = z

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/da1c598e/attachment.htm 

From guido at python.org  Sun Mar 16 16:00:36 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 10:00:36 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
Message-ID: <ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>

On Sat, Mar 15, 2008 at 6:01 PM, Thomas Wouters <thomas at python.org> wrote:
> On Sat, Mar 15, 2008 at 3:21 PM, Guido van Rossum <guido at python.org> wrote:
> > This post does point out an inconistency in Thomas's patch:
> >
> > def f():
> >  yield 1, 2, 3
> >
> > Yields a single three-tuple.
> >
> > But
> >
> > def f():
> >  yield *[1, 2], 3
> >
> > Yields three separate values.
>
> Uhm, what? It doesn't, and it shouldn't, and I'm not sure what makes you
> think it does.

Sorry, I misread the output. I *expected* it to do this based on an
incomplete understanding of what you've implemented. Since I made this
mistake, I expect others will too; I think *something* needs to
change.

A strict proposal would be to change the syntax of yield so that it
only accepts a single expression, optionally prefixed with a '*'. This
would render

  yield 1, 2, 3

illegal -- you'd have to rewrite this as

  yield (1, 2, 3)

That's a minor inconvenience and can be taken care of by 2to3 easily.

A less strict proposal would be to allow

  yield *expr

and

  yield expr, expr, ...

but not

  yield *expr, expr, ...

nor

  yield expr, *expr, ...  # etc.

While we discussed this over drinks last night, it also made me think
about the end-case of *expr in other contexts. We have the following
series of similar assignments:

  a, b, *c = x
  b, *c = x
  *c = x      # disallowed
  *c, = x      # use this instead

This is defensible by analogy to the following:

  a, b, c = x   # unpack 3-tuple
  b, c = x   # unpack 2-tuple
  c = x   # not a tuple unpacking!
  c, = x   # must unpack 1-tuple this way

However while in the latter case "c = x" there is no syntactic hint
that a tuple might be intended, one could say that in "*c = x" the
star is plenty enough of a hint.  (The semantics would be clear by
taking the limit of the first series of examples; "*c = x" is
equivalent to "c = list(x)".)

I don't think I actually *like* this; it would make "yield *expr" even
more of an exception, and it doesn't have any attractive use cases.
However I believe that the analogy between regular tuple unpacking and
extended tuple unpacking is a relatively weak argument to forbid "*c =
x", and I expect that this gray area is likely to cause users to trip
up in their understanding of this proposed new syntax; especially if
they think too hard about it. :)

Two other comments on Thomas's proposal:

(a) *if* we're going to do this, it should also be done for function
calls (though not for function defs). I'd like all of these to be
legal (and their interpretation is obvious):

  f(a, b, *x, k=val)
  f(a, *x, b, k=val)
  f(*x, a, b, k=val, **kw=stuff)

(b) I noticed that the following are equivalent:

  a, *b
  a, (*b)

I think the latter should not be allowed; the * should be present at
the same level as the commas to which it belongs. (This may be an
issue for the existing extended tuple unpacking as well?)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From gregor.lingl at aon.at  Sun Mar 16 16:13:03 2008
From: gregor.lingl at aon.at (Gregor Lingl)
Date: Sun, 16 Mar 2008 16:13:03 +0100
Subject: [Python-3000] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <47DD38FF.9010004@aon.at>


Hi everyone,

with this posting I refer to a paragraph in PEP 361, which says:

"""Each non-trivial feature listed here that is not a PEP must be discussed on python-dev.  Other enhancements include:

   - ...
   - turtle.py replacement or enhancements
"""

Some time ago I had offered my xturtle.py as a replacement of or 
supplement to turtle.py. The discussion that followed is here:

http://www.python.org/dev/summary/2006-06-16_2006-06-30/

At Europython 2006 I gave a talk on xturtle and there and since then I 
had quite positive feedback including encouragement to offer it again to 
include it in the python standard distribution by quite a few people 
including Guido van Rossum.

During the last few weeks I did some enhancements to xturtle and put the 
current version on the xturtle website for download in order to get same 
feedback about the API as well as possible bug reports. This version 
still needs some code polishing.

http://www.rg16.at/~python/xturtle/download.html

So I'm interested to know if this is still an issue for you. If so there 
should be initiated some procedure to decide that.

If this decision were negative, things were done (- and I'd continue to 
develop xturtle elsewhere.)

If the decision were positive, I'd be able to prepare two equivalent 
versions for Python2.6 and Python3000 within two or three weeks. (The 
port to Python3000 is nearly ready.) These could include say 85% of the 
documentation, albeit still not in the correct format.

I think these had to be examined my some reviewer(s) and also a 
discussion about features to include or not include would be useful. I'd 
like to intensivly take part in this discussion and development.

After a possible decision to include xturtle into Python, which 
certainly should take place before the first beta release, there would 
be enough time to polish the documentation and to fix bugs. For their 
discovery it would certainly be an advantage to put it in some 
prerelease as early as possible.

Of course I know that xturtle is only a side issue in the current 
development efforts. Unfortunately I'm not familiar with the procedures 
needed to get a new module into Python, so I kindly ask you for your 
advice how to proceed, at the same time offering my cooperation.

With best regards

Gregor Lingl

Guido van Rossum schrieb:
> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
>   

From guido at python.org  Sun Mar 16 16:23:56 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 10:23:56 -0500
Subject: [Python-3000] 2.6 and 3.0 tasks
Message-ID: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>

Moving this to a new subject to keep the discussion of tasks and the
discussion of task tracking tools separate.

On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <lists at cheimes.de> wrote:
>  I did a quick brainstorming with me, myself and I. I came up with a list
>  of (IMHO) important tasks.
>
>  * Stabilize the C API of Python 3.0. I like to rename several prefixes
>  to reduce the confusing: PyBytes -> PyByteArray,

+1 (also +1 to backporting this to 2.6)

> PyString -> PyBytes ...

-1. This will make merging code from 2.6 harder, and causes more work
for porting C extensions.

>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
>  and he said he is trying to get it done during the PyCon sprint. Maybe
>  somebody can assist him?

Does he need assistance?

>  When the new buffer protocol is available in 2.6 we can start back
>  porting bytesarray and the new IO framework.

Are these really so closely tied that they have to wait before they
can be backported?

>  * Replace Windows API calls with wide versions to support unicode for
>  file names, environment etc.

+1. This should be broken into separate tasks for each API.

>  * Get the stdlib reorg done

+1. But again, I think this is many small tasks.

> and add the fixers to 2to3

+1. I think quite a few changes have not had a fixer added. Again, I
think we should maintain a specific list of needed fixers; fixers can
easily be developed independently.

>  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
>  but it may be too late when we plan to ship out 3.0 in August.

While I know that some people are expecting to use a development model
that invokes 2to3 very frequently, I think this is at best a
nice-to-have. (I also don't see how it could be done, but maybe I'm
blind for the obvious, as the original author.)

I have some other tasks to add:

- getargs.c (Georg posted about this; his post actually inspired my post.)

- Tweak structseq to be more like namedtuple. Maybe they could have a
common ABC. I also think we should get rid of the concept of "hidden"
fields (that are accessible by name but not through the tuple API).

- Devise a way to handle str instances pickled in 2.6 and unpickled in
3.0, and also bytes instances pickled in 3.0 and unpickled in 2.6.

- Someone should go over
  https://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg
and extract more tasks.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 16:32:17 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 10:32:17 -0500
Subject: [Python-3000] xturtle and 3.0
Message-ID: <ca471dc20803160832j52879623x2a09da85f8b72bc@mail.gmail.com>

I'm changing the subject to keep this separate from the project
management tools discussion.

On Sun, Mar 16, 2008 at 10:13 AM, Gregor Lingl <gregor.lingl at aon.at> wrote:
>
>  Hi everyone,
>
>  with this posting I refer to a paragraph in PEP 361, which says:
>
>  """Each non-trivial feature listed here that is not a PEP must be discussed on python-dev.  Other enhancements include:
>
>    - ...
>    - turtle.py replacement or enhancements
>  """
>
>  Some time ago I had offered my xturtle.py as a replacement of or
>  supplement to turtle.py. The discussion that followed is here:
>
>  http://www.python.org/dev/summary/2006-06-16_2006-06-30/
>
>  At Europython 2006 I gave a talk on xturtle and there and since then I
>  had quite positive feedback including encouragement to offer it again to
>  include it in the python standard distribution by quite a few people
>  including Guido van Rossum.
>
>  During the last few weeks I did some enhancements to xturtle and put the
>  current version on the xturtle website for download in order to get same
>  feedback about the API as well as possible bug reports. This version
>  still needs some code polishing.
>
>  http://www.rg16.at/~python/xturtle/download.html
>
>  So I'm interested to know if this is still an issue for you. If so there
>  should be initiated some procedure to decide that.

I think that for 3.0, replacing turtle with xturtle is great, *IF*
xturtle doesn't add any additional dependencies *AND* it works well on
Mac OSX, Linux and Windows.

>  If this decision were negative, things were done (- and I'd continue to
>  develop xturtle elsewhere.)
>
>  If the decision were positive, I'd be able to prepare two equivalent
>  versions for Python2.6 and Python3000 within two or three weeks. (The
>  port to Python3000 is nearly ready.) These could include say 85% of the
>  documentation, albeit still not in the correct format.

That sounds cool. In 2.6 I'm reluctant to replace the existing turtle
module; xturtle can be added as xturtle.

>  I think these had to be examined my some reviewer(s) and also a
>  discussion about features to include or not include would be useful. I'd
>  like to intensivly take part in this discussion and development.
>
>  After a possible decision to include xturtle into Python, which
>  certainly should take place before the first beta release, there would
>  be enough time to polish the documentation and to fix bugs. For their
>  discovery it would certainly be an advantage to put it in some
>  prerelease as early as possible.
>
>  Of course I know that xturtle is only a side issue in the current
>  development efforts. Unfortunately I'm not familiar with the procedures
>  needed to get a new module into Python, so I kindly ask you for your
>  advice how to proceed, at the same time offering my cooperation.

I think that for a library module like this, an email like you've sent
is just fine. Maybe Brett has a suggestion on whether it would remain
a toplevel module or could be placed in some umbrella package (is
Tkinter being moved around?).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From musiccomposition at gmail.com  Sun Mar 16 17:19:37 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 11:19:37 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>

On Sun, Mar 16, 2008 at 8:51 AM, Guido van Rossum <guido at python.org> wrote:

> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...

I don't like the idea of task like items in the main bug tracker. I do,
however, like the bug tracker interface for this sort of thing. Could we
start a new instance of the the tracker just for internal development tasks?
We could change the statuses around to "Work in progress", "Completed",
"Incomplete", and such. It'd be easy to search for tasks that have to be
accomplished for a given release.

>
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/ce742145/attachment.htm 

From musiccomposition at gmail.com  Sun Mar 16 17:26:58 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 11:26:58 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
Message-ID: <1afaf6160803160926i37d3f2b9l9bd23953e77f7101@mail.gmail.com>

On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <guido at python.org> wrote:

> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
>
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <lists at cheimes.de>
> wrote:
> >  I did a quick brainstorming with me, myself and I. I came up with a
> list
> >  of (IMHO) important tasks.
> >
> >  * Stabilize the C API of Python 3.0. I like to rename several prefixes
> >  to reduce the confusing: PyBytes -> PyByteArray,
>
> +1 (also +1 to backporting this to 2.6)
>
> > PyString -> PyBytes ...
>
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.

There was a thread about this a few weeks ago:
http://mail.python.org/pipermail/python-dev/2008-March/077339.html
We can still do the renaming, but alias PyString to PyBytes.

>
>
> >  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
> >  and he said he is trying to get it done during the PyCon sprint. Maybe
> >  somebody can assist him?
>
> Does he need assistance?
>
> >  When the new buffer protocol is available in 2.6 we can start back
> >  porting bytesarray and the new IO framework.
>
> Are these really so closely tied that they have to wait before they
> can be backported?
>
> >  * Replace Windows API calls with wide versions to support unicode for
> >  file names, environment etc.
>
> +1. This should be broken into separate tasks for each API.
>
> >  * Get the stdlib reorg done
>
> +1. But again, I think this is many small tasks.
>
> > and add the fixers to 2to3
>
> +1. I think quite a few changes have not had a fixer added. Again, I
> think we should maintain a specific list of needed fixers; fixers can
> easily be developed independently.
>
> >  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
> >  but it may be too late when we plan to ship out 3.0 in August.
>
> While I know that some people are expecting to use a development model
> that invokes 2to3 very frequently, I think this is at best a
> nice-to-have. (I also don't see how it could be done, but maybe I'm
> blind for the obvious, as the original author.)
>
> I have some other tasks to add:
>
> - getargs.c (Georg posted about this; his post actually inspired my post.)
>
> - Tweak structseq to be more like namedtuple. Maybe they could have a
> common ABC. I also think we should get rid of the concept of "hidden"
> fields (that are accessible by name but not through the tuple API).
>
> - Devise a way to handle str instances pickled in 2.6 and unpickled in
> 3.0, and also bytes instances pickled in 3.0 and unpickled in 2.6.
>
> - Someone should go over
>  https://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg
> and extract more tasks.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/79f70334/attachment.htm 

From guido at python.org  Sun Mar 16 17:37:45 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 11:37:45 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
Message-ID: <ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> I don't like the idea of task like items in the main bug tracker.

Why not? Bugs are also tasks, and need to be managed and triaged in
the same way. It might be convenient to have everything in one
tracker. What's your objection? It should be easy enough to search for
tasks or bugs etc.

> I do, however, like the bug tracker interface for this sort of thing. Could we
> start a new instance of the the tracker just for internal development tasks?

I'm not sure how easy it would be to start a new instance, but I
expect setting up the database, configuration etc. would require a
fairly significant amount of work. I'd much rather use existing
infrastructure.

> We could change the statuses around to "Work in progress", "Completed",
> "Incomplete", and such. It'd be easy to search for tasks that have to be
> accomplished for a given release.

That would be good for bugs too, actually.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 17:40:32 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 11:40:32 -0500
Subject: [Python-3000] Fwd: [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160808xe1c2ef2q4c7742cc6fa8c6f9@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>
	<ca471dc20803160718k4255a73eg68238da2570c056b@mail.gmail.com>
	<18397.12093.765076.737023@montanaro-dyndns-org.local>
	<ca471dc20803160808xe1c2ef2q4c7742cc6fa8c6f9@mail.gmail.com>
Message-ID: <ca471dc20803160940h41ce6f57re5eb4274321ea0b9@mail.gmail.com>

Sorry, forgot to CC this to the list.

On Sun, Mar 16, 2008 at 9:31 AM,  <skip at pobox.com> wrote:
 >
 >     Guido> It has a much more detailed set of categories, organized as a
 >     Guido> tree.  Our project alone probably has 20-30 different bug
 >     Guido> categories. New bugs in those categories are automatically CC'ed
 >     Guido> to our group's mailing list (which isn't the same as
 >     Guido> auto-assignment).
 >
 >  Adding categories should be easy.  Organized in trees?  Not so sure.

 The tree is really useful because it means that end users can assign
 bugs to the top-level node for a project and the project members can
 move it to the correct subnode. This can even happen in two triage
 stages for large projects.


 >     Guido> There are also more "bug states" you can use to track progress of
 >     Guido> a bug through the system: unassigned, assigned, accepted (meaning
 >     Guido> the assignee is actually working on it). (There are also a whole
 >     Guido> bunch that I don't find so useful, and severam that roundup
 >     Guido> already supports.)
 >
 >  Again, I think this should be easy.

 It's also the least important one on my list.


 >     Guido> But perhaps the best feature is "hot lists" -- arbitrary,
 >     Guido> ordered, groupings of selected bugs. Each bug can be assigned to
 >     Guido> as many hot lists as you want. Seeing the list of all bugs in a
 >     Guido> particular hot list is one click away. We use this for overlaying
 >     Guido> project management categories and priorities, such as "code",
 >     Guido> "documentation", "configuration" as well as "next internal
 >     Guido> release", "must have", "post launch" etc.
 >
 >  A hot list sounds like a saved search, which Roundup already supports.  It
 >  also supports making these saved searches public.  I suspect you could
 >  define one or more saved public searches which correspond to desired hot
 >  lists.

 Not quite. Items don't automatically end up on a hot list; they must
 explicitly be put on one. I'm not sure how you'd simulate this via
 saved searches. Maybe a combination of a custom keyword *and* a saved
 search would help. However this doesn't scale so well, because
 keywords show up in everybody's UI. Hot lists are only visible to
 users who care to subscribe to them.

[Georg, in a later post]
> Doesn't this match Roundup's keywords?

See above answer.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 17:44:43 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 11:44:43 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <1afaf6160803160926i37d3f2b9l9bd23953e77f7101@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<1afaf6160803160926i37d3f2b9l9bd23953e77f7101@mail.gmail.com>
Message-ID: <ca471dc20803160944h5cc6333p8e55643c182854a6@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <guido at python.org> wrote:
> > > PyString -> PyBytes ...
> >
> > -1. This will make merging code from 2.6 harder, and causes more work
> > for porting C extensions.

> There was a thread about this a few weeks ago:
> http://mail.python.org/pipermail/python-dev/2008-March/077339.html
>  We can still do the renaming, but alias PyString to PyBytes.

That's a rather long thread. Was any conclusion reached? I'm not sure
how introducing a set of aliases will help merging 2.6 code to 3.0.
Can you or Christian describe the proposed approach in more detail?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sun Mar 16 17:46:00 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMwpp3aXMi?=)
Date: Sun, 16 Mar 2008 11:46:00 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <47DD31CD.9030008@cheimes.de>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<47DD31CD.9030008@cheimes.de>
Message-ID: <47DD4EC8.4090600@v.loewis.de>

> * Stabilize the C API of Python 3.0. I like to rename several prefixes
> to reduce the confusing: PyBytes -> PyByteArray, PyString -> PyBytes ...

I'd like to bring up PEP 3121 here as well. I have patches, but still
need to complete them.


Regards
Martin

From collinw at gmail.com  Sun Mar 16 17:50:16 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 16 Mar 2008 09:50:16 -0700
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
Message-ID: <43aa6ff70803160950l736a20ceg1acb4c17251d9a0d@mail.gmail.com>

On Sun, Mar 16, 2008 at 8:23 AM, Guido van Rossum <guido at python.org> wrote:
>  On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <lists at cheimes.de> wrote:
......
>  > and add the fixers to 2to3
>
>  +1. I think quite a few changes have not had a fixer added. Again, I
>  think we should maintain a specific list of needed fixers; fixers can
>  easily be developed independently.

Neal and I are coming up with a list to feed tasks to interested PyCon
sprinters.

>  >  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
>  >  but it may be too late when we plan to ship out 3.0 in August.
>
>  While I know that some people are expecting to use a development model
>  that invokes 2to3 very frequently, I think this is at best a
>  nice-to-have. (I also don't see how it could be done, but maybe I'm
>  blind for the obvious, as the original author.)

The biggest win in terms of performance would be to reimplement the
pattern matching engine used by the fixers.: it by far dominates the
running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
for example. The current design is a heavily-recursive system, and as
such bombs out when it encounters, e.g., files with a thousand
assignment statements in a row. I'd also like something more
expressive: the current DSL can't express recursive patterns.

Collin Winter

From skip at pobox.com  Sun Mar 16 17:49:45 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 16 Mar 2008 11:49:45 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
Message-ID: <18397.20393.103687.882317@montanaro-dyndns-org.local>


    >> I don't like the idea of task like items in the main bug tracker.

    Guido> Why not? Bugs are also tasks, and need to be managed and triaged
    Guido> in the same way.

Agreed.  Both bugs and tasks would be "issues" in Roundup parlance, along
with patches.

A further reason to keep this in Roundup if possible is that people like
Martin have already committed to help maintain the tracker.  We already have
a separate Trac instance for the website, which I would like to see folded
into the Roundup tracker, freeing up limited (human) resources used to
maintain that tracker so they can either spend more time with their families
or work on other things that need doing.

Skip

From musiccomposition at gmail.com  Sun Mar 16 17:51:19 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 11:51:19 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
Message-ID: <1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:37 AM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> > I don't like the idea of task like items in the main bug tracker.
>
> Why not? Bugs are also tasks, and need to be managed and triaged in
> the same way. It might be convenient to have everything in one
> tracker. What's your objection? It should be easy enough to search for
> tasks or bugs etc.

It's just depends on how you see the tracker. It's not just to "bug" tracker
anymore, is it? On other projects I've worked with, we had separate areas
for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
keep organized. However, if this is Python's way, I'm not going to stand in
it.

>
>
> > I do, however, like the bug tracker interface for this sort of thing.
> Could we
> > start a new instance of the the tracker just for internal development
> tasks?
>
> I'm not sure how easy it would be to start a new instance, but I
> expect setting up the database, configuration etc. would require a
> fairly significant amount of work. I'd much rather use existing
> infrastructure.

I'm now fine with that.

>
>
> > We could change the statuses around to "Work in progress", "Completed",
> > "Incomplete", and such. It'd be easy to search for tasks that have to be
> > accomplished for a given release.
>
> That would be good for bugs too, actually.

Well, I'm glad to help somehow! :P

>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/cf09856b/attachment.htm 

From martin at v.loewis.de  Sun Mar 16 17:54:26 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMwpp3aXMi?=)
Date: Sun, 16 Mar 2008 11:54:26 -0500
Subject: [Python-3000] Fwd: [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160940h41ce6f57re5eb4274321ea0b9@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<e04bdf310803160701v2bbce76q7f957b9682c8f1a7@mail.gmail.com>	<ca471dc20803160718k4255a73eg68238da2570c056b@mail.gmail.com>	<18397.12093.765076.737023@montanaro-dyndns-org.local>	<ca471dc20803160808xe1c2ef2q4c7742cc6fa8c6f9@mail.gmail.com>
	<ca471dc20803160940h41ce6f57re5eb4274321ea0b9@mail.gmail.com>
Message-ID: <47DD50C2.1070701@v.loewis.de>

>  Not quite. Items don't automatically end up on a hot list; they must
>  explicitly be put on one. I'm not sure how you'd simulate this via
>  saved searches. Maybe a combination of a custom keyword *and* a saved
>  search would help. However this doesn't scale so well, because
>  keywords show up in everybody's UI. Hot lists are only visible to
>  users who care to subscribe to them.

It would be relatively easy to implement this directly in roundup.
IIUC, there should be a hotlist object, and either
a) an issue has a multilink to multiple hotlists, or
b) a hotlist has a multilink to multiple issues.

I cannot envision the "add to hotlist" user interface, though.
It should be possible to add an issue to a hotlist from the issue's
page, right? So would a comma-separated list be reasonable? (with
a popup menu to checkmark hotlists)

Regards,
Martin

From musiccomposition at gmail.com  Sun Mar 16 17:57:32 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 11:57:32 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160944h5cc6333p8e55643c182854a6@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<1afaf6160803160926i37d3f2b9l9bd23953e77f7101@mail.gmail.com>
	<ca471dc20803160944h5cc6333p8e55643c182854a6@mail.gmail.com>
Message-ID: <1afaf6160803160957v1e15a8c9s1e709a0d47bb52f@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:44 AM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> > On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <guido at python.org>
> wrote:
> > > > PyString -> PyBytes ...
> > >
> > > -1. This will make merging code from 2.6 harder, and causes more work
> > > for porting C extensions.
>
> > There was a thread about this a few weeks ago:
> > http://mail.python.org/pipermail/python-dev/2008-March/077339.html
> >  We can still do the renaming, but alias PyString to PyBytes.
>
> That's a rather long thread. Was any conclusion reached? I'm not sure
> how introducing a set of aliases will help merging 2.6 code to 3.0.
> Can you or Christian describe the proposed approach in more detail?

As far as I can see, no objections were raised in that thread.
Christian explained the probable approach:
http://mail.python.org/pipermail/python-dev/2008-March/077362.html

>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/d18e1550/attachment.htm 

From martin at v.loewis.de  Sun Mar 16 17:58:00 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMwpp3aXMi?=)
Date: Sun, 16 Mar 2008 11:58:00 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
	<1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
Message-ID: <47DD5198.9090001@v.loewis.de>

> It's just depends on how you see the tracker. It's not just to "bug" 
> tracker anymore, is it? On other projects I've worked with, we had 
> separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I 
> found it easier to keep organized. However, if this is Python's way, I'm 
> not going to stand in it.

Actually, one of the main complaints about the SF tracker is that it
splits into several ones.

Something starts out as a bug, but then becomes a patch as soon as
somebody attaches a patch. So on SF, people had to open a *separate*
issue to provide a patch, and leave a message in the original bug
report pointing to the patch. They hated it, and insisted that
the new tracker should have a single list of issues.

Regards,
Martin


From brett at python.org  Sun Mar 16 18:00:01 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 16 Mar 2008 12:00:01 -0500
Subject: [Python-3000] xturtle and 3.0
In-Reply-To: <ca471dc20803160832j52879623x2a09da85f8b72bc@mail.gmail.com>
References: <ca471dc20803160832j52879623x2a09da85f8b72bc@mail.gmail.com>
Message-ID: <bbaeab100803161000t4fc2e39dycfba5f2c03101ff1@mail.gmail.com>

On Sun, Mar 16, 2008 at 10:32 AM, Guido van Rossum <guido at python.org> wrote:
> I'm changing the subject to keep this separate from the project
>  management tools discussion.
>
>
>  >  Of course I know that xturtle is only a side issue in the current
>  >  development efforts. Unfortunately I'm not familiar with the procedures
>  >  needed to get a new module into Python, so I kindly ask you for your
>  >  advice how to proceed, at the same time offering my cooperation.
>
>  I think that for a library module like this, an email like you've sent
>  is just fine. Maybe Brett has a suggestion on whether it would remain
>  a toplevel module or could be placed in some umbrella package (is
>  Tkinter being moved around?).

The current plan is to introduce a tk package and turtle was to become
tk.turtle. xturtle, if picked up, can just take the place of the
current turtle at that location.

-Brett

From martin at v.loewis.de  Sun Mar 16 18:04:29 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMwpp3aXMi?=)
Date: Sun, 16 Mar 2008 12:04:29 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E168AD176@EXMBX04.exchhosting.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<87D3F9C72FBF214DB39FA4E3FE618CDC6E168AD176@EXMBX04.exchhosting.com>
Message-ID: <47DD531D.5030801@v.loewis.de>

>>> * Replace Windows API calls with wide versions to support unicode
>>>  for file names, environment etc.
>> +1. This should be broken into separate tasks for each API.
> 
> What are we referring to here?  Calling the W versions explicitly and
> using wchar_t for everything, or using the TCHAR/TEXT() approach and
> keeping the API calls the same, letting the #define UNICODE do the
> work behind the scenes?

Not sure whose being attributed here, but I think "breaking down"
should be done by "information source": command line, environment,
registry, file names, sys.path, module names, etc.

I have a patch on SF to resolve the command line issue.

I don't think we should use Microsoft's Unicode programming model
around TCHAR/TEXT. It would allow for two different builds, and
given that we don't need to support W9X anymore, an "ANSI" build
is pointless, IMO.

Regards,
Martin

From lists at cheimes.de  Sun Mar 16 18:09:49 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 16 Mar 2008 18:09:49 +0100
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
Message-ID: <47DD545D.6070300@cheimes.de>

Guido van Rossum wrote:
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.

I'm happy to pay the price for the sake of a clean and easy-to-recall C
API.

The for the C extension problem I already proposed a solution in the
thread Benjamin mentioned before.

#include "Python.h"
#if PY_VERSION_HEX > 0x03000000
  #include "python2_compat.h"
#endif

Where python2_compat provides aliases for PyInt and PyString:

#define PyInt_Spam PyLong_Spam
...
#define PyString_Egg PyBytes_Egg

>>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
>>  and he said he is trying to get it done during the PyCon sprint. Maybe
>>  somebody can assist him?
> 
> Does he need assistance?

I don't know.
> 
>>  When the new buffer protocol is available in 2.6 we can start back
>>  porting bytesarray and the new IO framework.
> 
> Are these really so closely tied that they have to wait before they
> can be backported?

Bytesarray depends on the buffer protocol and the new io framework is
much easier to back port when both the buffer protocol and bytesarray is
available.

> While I know that some people are expecting to use a development model
> that invokes 2to3 very frequently, I think this is at best a
> nice-to-have. (I also don't see how it could be done, but maybe I'm
> blind for the obvious, as the original author.)

I'm not sure if and how 2to3 can be speed up. Maybe some profiling and
some C code can increase the speed. It's worth a shot.

Christian

From guido at python.org  Sun Mar 16 18:13:42 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 12:13:42 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
	<1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
Message-ID: <ca471dc20803161013x7dfd5fd6k7da075e90852bbac@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:51 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> It's just depends on how you see the tracker. It's not just to "bug" tracker
> anymore, is it? On other projects I've worked with, we had separate areas
> for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
> keep organized. However, if this is Python's way, I'm not going to stand in
> it.

Ah, sourceforge. I am so glad we're not using that any more. The
random separation between patches and bugs was more a distraction
rather than a feature; often bugs turn into patches or patches turn
out to be useless except for the fact that they highlight a bug...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Sun Mar 16 18:17:00 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 16 Mar 2008 18:17:00 +0100
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <43aa6ff70803160950l736a20ceg1acb4c17251d9a0d@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<43aa6ff70803160950l736a20ceg1acb4c17251d9a0d@mail.gmail.com>
Message-ID: <47DD560C.8090202@cheimes.de>

Collin Winter wrote:
> The biggest win in terms of performance would be to reimplement the
> pattern matching engine used by the fixers.: it by far dominates the
> running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
> for example. The current design is a heavily-recursive system, and as
> such bombs out when it encounters, e.g., files with a thousand
> assignment statements in a row. I'd also like something more
> expressive: the current DSL can't express recursive patterns.

Do you have time to mentor a GSoC project? Or can you mentor a mentor
...? :)

Christian

From barry at python.org  Sun Mar 16 18:24:19 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 16 Mar 2008 12:24:19 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:

> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.

I mentioned this to Guido and got a positive response, so let me state  
my preference for your feedback.  I plan on holding up the final  
releases until both versions are ready to go.  I think this will help  
motivate us to give Python 2.6 the love it needs if it's lagging  
behind 3.0, and I completely agree with Guido that this let's our  
community know that both versions are equally important to us.

The other thing is that I'd really like is a "show stoppers" Roundup  
search.  The idea is that if our core buildbots look good and the  
"show stoppers" search turns up no items, then I know I can cut a  
release (at least for alphas, betas, and rcs).  If there are "show  
stoppers" then I have something that I can triage (and maybe re-assign  
severity) or start publicly harassing people into fixing.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR91XxHEjvBPtnXfVAQIINwQAsaJ8uWb0FXqD9wZV8AuE7CxG2RLEZl42
vz2EUbAs7n/txV/lWs3N4syZvfS7g0Q3rgd65LvpUCi4+r6M3MpKcl9VFxGfheUD
mHf5LajS/wEEXyFpxG9+dGfhPpD7JFx21PKyOpHKnq3LP0fCt3yenOi/nEF5zfHr
Ogc6JOapRiM=
=0f9G
-----END PGP SIGNATURE-----

From barry at python.org  Sun Mar 16 18:25:27 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 16 Mar 2008 12:25:27 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
Message-ID: <65366C3B-A839-454E-A748-9CF24C39A980@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:

> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.

Oh yeah, I'd like to hash a more detailed timeline out at the sprint.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR91YCXEjvBPtnXfVAQJsxQP9FgyAn2JOl/+SShBNgTqlxWBwGAbrjSlS
ySbm/55PKs6bnjx1lkyvptzHFdsfh1LlBVrC5rxQzQIjSX00x8fAPAoseQZ/hDm0
cnVSvPhJhBLsZCmsSRfvDYPdZXnanDd5ff69uV3jd+NLasuJBNrQ5d+eQGiQOTZm
BTgsjt+YKpQ=
=L9yF
-----END PGP SIGNATURE-----

From guido at python.org  Sun Mar 16 18:32:57 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 12:32:57 -0500
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <47DD545D.6070300@cheimes.de>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
Message-ID: <ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>

On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
[Guido]
> > That's a rather long thread. Was any conclusion reached? I'm not sure
> > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > Can you or Christian describe the proposed approach in more detail?

> As far as I can see, no objections were raised in that thread.

Hm. I had wanted to register a complaint, but I guess I was too busy.

> Christian explained the probable approach:
> http://mail.python.org/pipermail/python-dev/2008-March/077362.html

That's not much of a plan. It doesn't discuss any of the effects of
the proposed change on merging code from the 2.6 trunk to the py3k
branch.

On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
>  > -1. This will make merging code from 2.6 harder, and causes more work
>  > for porting C extensions.
>
>  I'm happy to pay the price for the sake of a clean and easy-to-recall C
>  API.
>
>  The for the C extension problem I already proposed a solution in the
>  thread Benjamin mentioned before.
>
>  #include "Python.h"
>  #if PY_VERSION_HEX > 0x03000000
>   #include "python2_compat.h"
>  #endif
>
>  Where python2_compat provides aliases for PyInt and PyString:
>
>  #define PyInt_Spam PyLong_Spam
>  ...
>  #define PyString_Egg PyBytes_Egg

So this doesn't address merges at all. Suppose we have some C code
that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
the gzip codec). It currently uses PyString on both branches, so any
changes to the trunk merge smoothly into the py3k branch. But if you
change PyString -> PyBytes in the py3k branch, every change you make
in the 2.6 code will cause a merge conflict. Is that really what you
want? I worry that it will effectively separate the trunk and the py3k
branch, losing the advantage of doing development that effects both at
once.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pje at telecommunity.com  Sun Mar 16 18:48:25 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 16 Mar 2008 13:48:25 -0400
Subject: [Python-3000] Using *a for packing in lists and other  places
In-Reply-To: <ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.co
 m>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>
Message-ID: <20080316174832.7E4983A40FF@sparrow.telecommunity.com>

At 10:00 AM 3/16/2008 -0500, Guido van Rossum wrote:
>(a) *if* we're going to do this, it should also be done for function
>calls (though not for function defs). I'd like all of these to be
>legal (and their interpretation is obvious):
>
>   f(a, b, *x, k=val)
>   f(a, *x, b, k=val)
>   f(*x, a, b, k=val, **kw=stuff)

What does **kw=stuff do?


From guido at python.org  Sun Mar 16 18:55:46 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 12:55:46 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <20080316174832.7E4983A40FF@sparrow.telecommunity.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>
	<20080316174832.7E4983A40FF@sparrow.telecommunity.com>
Message-ID: <ca471dc20803161055k6051de0an61a59dd758b7e04d@mail.gmail.com>

On Sun, Mar 16, 2008 at 12:48 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:00 AM 3/16/2008 -0500, Guido van Rossum wrote:
>  >(a) *if* we're going to do this, it should also be done for function
>  >calls (though not for function defs). I'd like all of these to be
>  >legal (and their interpretation is obvious):
>  >
>  >   f(a, b, *x, k=val)
>  >   f(a, *x, b, k=val)
>  >   f(*x, a, b, k=val, **kw=stuff)
>
>  What does **kw=stuff do?

Sorry, typo. It's been a long conference. ;-) I meant **kw, not **kw=stuff.

PS too bad you're not here!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From musiccomposition at gmail.com  Sun Mar 16 19:01:29 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 13:01:29 -0500
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
Message-ID: <1afaf6160803161101jed4b63bl3ae599622bb56bfe@mail.gmail.com>

On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> [Guido]
> > > That's a rather long thread. Was any conclusion reached? I'm not sure
> > > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > > Can you or Christian describe the proposed approach in more detail?
>
> > As far as I can see, no objections were raised in that thread.
>
> Hm. I had wanted to register a complaint, but I guess I was too busy.
>
> > Christian explained the probable approach:
> > http://mail.python.org/pipermail/python-dev/2008-March/077362.html
>
> That's not much of a plan. It doesn't discuss any of the effects of
> the proposed change on merging code from the 2.6 trunk to the py3k
> branch.
>
> On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists at cheimes.de>
> wrote:
> > Guido van Rossum wrote:
> >  > -1. This will make merging code from 2.6 harder, and causes more work
> >  > for porting C extensions.
> >
> >  I'm happy to pay the price for the sake of a clean and easy-to-recall C
> >  API.
> >
> >  The for the C extension problem I already proposed a solution in the
> >  thread Benjamin mentioned before.
> >
> >  #include "Python.h"
> >  #if PY_VERSION_HEX > 0x03000000
> >   #include "python2_compat.h"
> >  #endif
> >
> >  Where python2_compat provides aliases for PyInt and PyString:
> >
> >  #define PyInt_Spam PyLong_Spam
> >  ...
> >  #define PyString_Egg PyBytes_Egg
>
> So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But if you
> change PyString -> PyBytes in the py3k branch, every change you make
> in the 2.6 code will cause a merge conflict. Is that really what you
> want? I worry that it will effectively separate the trunk and the py3k
> branch, losing the advantage of doing development that effects both at
> once.

We could backport the python2_compact header.

>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/99e23fbc/attachment-0001.htm 

From lists at cheimes.de  Sun Mar 16 19:04:46 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 16 Mar 2008 19:04:46 +0100
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>	
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
Message-ID: <47DD613E.6090007@cheimes.de>

Guido van Rossum wrote:
 > So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But if you
> change PyString -> PyBytes in the py3k branch, every change you make
> in the 2.6 code will cause a merge conflict. Is that really what you
> want? I worry that it will effectively separate the trunk and the py3k
> branch, losing the advantage of doing development that effects both at
> once.

I'm fully aware of the extra burden. The removal of the PyInt_*
functions is already causing merge conflicts and compile errors. Nearly
every C code merge contains at least one place that requires manual
intervention. The PyInt merge conflicts are trivial to fix - so would
errors caused PyString -> PyBytes rename.

I'm not worried about the extra work since it's usually trivial and fast
to fix. I'm more worried about the API names. Do you *really* want to
drag down dead bodies along the road for the next ten years? The dead
bodies are going to rot and stink sooner than later. By Python 3.2
everybody surely regrets the confusing names. ;)

Christian

From musiccomposition at gmail.com  Sun Mar 16 19:06:18 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 16 Mar 2008 13:06:18 -0500
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <1afaf6160803161101jed4b63bl3ae599622bb56bfe@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
	<1afaf6160803161101jed4b63bl3ae599622bb56bfe@mail.gmail.com>
Message-ID: <1afaf6160803161106o5c06ce6dx7839e0d5decd2cc0@mail.gmail.com>

On Sun, Mar 16, 2008 at 1:01 PM, Benjamin Peterson <
musiccomposition at gmail.com> wrote:

>
>
> On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <guido at python.org>
> wrote:
>
> > On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> > <musiccomposition at gmail.com> wrote:
> > [Guido]
> > > > That's a rather long thread. Was any conclusion reached? I'm not
> > sure
> > > > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > > > Can you or Christian describe the proposed approach in more detail?
> >
> > > As far as I can see, no objections were raised in that thread.
> >
> > Hm. I had wanted to register a complaint, but I guess I was too busy.
> >
> > > Christian explained the probable approach:
> > > http://mail.python.org/pipermail/python-dev/2008-March/077362.html
> >
> > That's not much of a plan. It doesn't discuss any of the effects of
> > the proposed change on merging code from the 2.6 trunk to the py3k
> > branch.
> >
> > On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists at cheimes.de>
> > wrote:
> > > Guido van Rossum wrote:
> > >  > -1. This will make merging code from 2.6 harder, and causes more
> > work
> > >  > for porting C extensions.
> > >
> > >  I'm happy to pay the price for the sake of a clean and easy-to-recall
> > C
> > >  API.
> > >
> > >  The for the C extension problem I already proposed a solution in the
> > >  thread Benjamin mentioned before.
> > >
> > >  #include "Python.h"
> > >  #if PY_VERSION_HEX > 0x03000000
> > >   #include "python2_compat.h"
> > >  #endif
> > >
> > >  Where python2_compat provides aliases for PyInt and PyString:
> > >
> > >  #define PyInt_Spam PyLong_Spam
> > >  ...
> > >  #define PyString_Egg PyBytes_Egg
> >
> > So this doesn't address merges at all. Suppose we have some C code
> > that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> > the gzip codec). It currently uses PyString on both branches, so any
> > changes to the trunk merge smoothly into the py3k branch. But if you
> > change PyString -> PyBytes in the py3k branch, every change you make
> > in the 2.6 code will cause a merge conflict. Is that really what you
> > want? I worry that it will effectively separate the trunk and the py3k
> > branch, losing the advantage of doing development that effects both at
> > once.
>
> We could backport the python2_compact header.
>
Sorry, that needs some explanation. We could do the opposite that we do for
Py3K: Add a header file aliasing PyBytes to PyString.

>
>
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> > )
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/5cd56eed/attachment.htm 

From pje at telecommunity.com  Sun Mar 16 19:31:53 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 16 Mar 2008 14:31:53 -0400
Subject: [Python-3000] Using *a for packing in lists and other  places
In-Reply-To: <ca471dc20803161055k6051de0an61a59dd758b7e04d@mail.gmail.co
 m>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>
	<20080316174832.7E4983A40FF@sparrow.telecommunity.com>
	<ca471dc20803161055k6051de0an61a59dd758b7e04d@mail.gmail.com>
Message-ID: <20080316183200.E63CA3A409D@sparrow.telecommunity.com>

At 12:55 PM 3/16/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 12:48 PM, Phillip J. Eby 
><pje at telecommunity.com> wrote:
> > At 10:00 AM 3/16/2008 -0500, Guido van Rossum wrote:
> >  >(a) *if* we're going to do this, it should also be done for function
> >  >calls (though not for function defs). I'd like all of these to be
> >  >legal (and their interpretation is obvious):
> >  >
> >  >   f(a, b, *x, k=val)
> >  >   f(a, *x, b, k=val)
> >  >   f(*x, a, b, k=val, **kw=stuff)
> >
> >  What does **kw=stuff do?
>
>Sorry, typo. It's been a long conference. ;-) I meant **kw, not **kw=stuff.
>
>PS too bad you're not here!

I will be, next year.  I'll have plenty to present, if the things I'm 
working on haven't already become big enough by then that other 
people are doing presentations on them, instead.  :)

Btw, would you mind pronouncing (or at least commenting) on PEP 365, 
so that I can proceed with the work -- or not.


From guido at python.org  Sun Mar 16 20:46:26 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 14:46:26 -0500
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <47DD613E.6090007@cheimes.de>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
	<47DD613E.6090007@cheimes.de>
Message-ID: <ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>

On Sun, Mar 16, 2008 at 1:04 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
>   > So this doesn't address merges at all. Suppose we have some C code
>  > that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
>  > the gzip codec). It currently uses PyString on both branches, so any
>  > changes to the trunk merge smoothly into the py3k branch. But if you
>  > change PyString -> PyBytes in the py3k branch, every change you make
>  > in the 2.6 code will cause a merge conflict. Is that really what you
>  > want? I worry that it will effectively separate the trunk and the py3k
>  > branch, losing the advantage of doing development that effects both at
>  > once.
>
>  I'm fully aware of the extra burden. The removal of the PyInt_*
>  functions is already causing merge conflicts and compile errors.

Even though the more popular PyInt_ APIs are still available (even if
only as macros).

>  Nearly every C code merge contains at least one place that requires manual
>  intervention. The PyInt merge conflicts are trivial to fix - so would
>  errors caused PyString -> PyBytes rename.

I disagree. Bad merges are already a frequent cause of instability in
3.0. This could easily double the problems. And while I want to reduce
the instability (I really wish you would no commit until all unittests
pass), I also don't want the merges to cost more of your time!

>  I'm not worried about the extra work since it's usually trivial and fast
>  to fix. I'm more worried about the API names. Do you *really* want to
>  drag down dead bodies along the road for the next ten years? The dead
>  bodies are going to rot and stink sooner than later. By Python 3.2
>  everybody surely regrets the confusing names. ;)

It doesn't have to be so black and white. Using the macro approach you
propose we can fix the situation at any time later.

We could also make the changes in 2.6, so that the 2.6 code looks the
same as 3.0. (However for binary compatibility I think it would be
better if in 2.6 the linker sees PyString where in 3.0 it sees
PyBytes.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sun Mar 16 20:47:39 2008
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 14:47:39 -0500
Subject: [Python-3000] Making 2to3 installable
Message-ID: <47DD795B.20507@v.loewis.de>

After talking to Collin, I just committed a change to
2to3 to make it installable as an executable script
called "2to3".

To do so, I had to wrap all the top-level modules
into a package, and move the fixes and tests into
that package. Lacking a better name, I called the
library lib2to3. I also install pgen2 as a separate
package.

In the process, I had to change all the imports,
and I did that by using relative imports. As
a consequence, 2to3 currently won't work on
Python 2.4.

Regards,
Martin

From guido at python.org  Sun Mar 16 20:49:03 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 14:49:03 -0500
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <20080316183200.E63CA3A409D@sparrow.telecommunity.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>
	<20080316174832.7E4983A40FF@sparrow.telecommunity.com>
	<ca471dc20803161055k6051de0an61a59dd758b7e04d@mail.gmail.com>
	<20080316183200.E63CA3A409D@sparrow.telecommunity.com>
Message-ID: <ca471dc20803161249u65b1c0ffl4ddc0bbf09afed0a@mail.gmail.com>

On Sun, Mar 16, 2008 at 1:31 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
>  Btw, would you mind pronouncing (or at least commenting) on PEP 365,
>  so that I can proceed with the work -- or not.

Can you point me to past discussions? ISTR that this is controversial.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 20:51:58 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 14:51:58 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD795B.20507@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
Message-ID: <ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>

Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?

On Sun, Mar 16, 2008 at 2:47 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> After talking to Collin, I just committed a change to
>  2to3 to make it installable as an executable script
>  called "2to3".
>
>  To do so, I had to wrap all the top-level modules
>  into a package, and move the fixes and tests into
>  that package. Lacking a better name, I called the
>  library lib2to3. I also install pgen2 as a separate
>  package.
>
>  In the process, I had to change all the imports,
>  and I did that by using relative imports. As
>  a consequence, 2to3 currently won't work on
>  Python 2.4.
>
>  Regards,
>  Martin
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From collinw at gmail.com  Sun Mar 16 20:57:44 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 16 Mar 2008 12:57:44 -0700
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
Message-ID: <43aa6ff70803161257m295b9cd1rfc3a5bcc35c3d114@mail.gmail.com>

On Sun, Mar 16, 2008 at 12:51 PM, Guido van Rossum <guido at python.org> wrote:
> Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?

That would be fine by me. I'll try to work up some better docs than
just a README.

>  On Sun, Mar 16, 2008 at 2:47 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  > After talking to Collin, I just committed a change to
>  >  2to3 to make it installable as an executable script
>  >  called "2to3".
>  >
>  >  To do so, I had to wrap all the top-level modules
>  >  into a package, and move the fixes and tests into
>  >  that package. Lacking a better name, I called the
>  >  library lib2to3. I also install pgen2 as a separate
>  >  package.
>  >
>  >  In the process, I had to change all the imports,
>  >  and I did that by using relative imports. As
>  >  a consequence, 2to3 currently won't work on
>  >  Python 2.4.
>  >
>  >  Regards,
>  >  Martin
>  >  _______________________________________________
>  >  Python-3000 mailing list
>  >  Python-3000 at python.org
>  >  http://mail.python.org/mailman/listinfo/python-3000
>  >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>  >
>
>
>
>  --
>  --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/collinw%40gmail.com
>

From tnelson at onresolve.com  Sun Mar 16 16:33:49 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Sun, 16 Mar 2008 08:33:49 -0700
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E168AD176@EXMBX04.exchhosting.com>

> >  * Replace Windows API calls with wide versions to support unicode
> >    for file names, environment etc.
>
> +1. This should be broken into separate tasks for each API.

What are we referring to here?  Calling the W versions explicitly and using wchar_t for everything, or using the TCHAR/TEXT() approach and keeping the API calls the same, letting the #define UNICODE do the work behind the scenes?

        Trent.

From collinw at gmail.com  Sun Mar 16 21:08:02 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 16 Mar 2008 13:08:02 -0700
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <47DD560C.8090202@cheimes.de>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<43aa6ff70803160950l736a20ceg1acb4c17251d9a0d@mail.gmail.com>
	<47DD560C.8090202@cheimes.de>
Message-ID: <43aa6ff70803161308u10f97081vf3244927f165ab75@mail.gmail.com>

On Sun, Mar 16, 2008 at 10:17 AM, Christian Heimes <lists at cheimes.de> wrote:
> Collin Winter wrote:
>  > The biggest win in terms of performance would be to reimplement the
>  > pattern matching engine used by the fixers.: it by far dominates the
>  > running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
>  > for example. The current design is a heavily-recursive system, and as
>  > such bombs out when it encounters, e.g., files with a thousand
>  > assignment statements in a row. I'd also like something more
>  > expressive: the current DSL can't express recursive patterns.
>
>  Do you have time to mentor a GSoC project? Or can you mentor a mentor
>  ...? :)

I think I'd have time to mentor a GSoC project. Let's talk off-list about that.

From martin at v.loewis.de  Sun Mar 16 21:11:11 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 15:11:11 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
Message-ID: <47DD7EDF.2070608@v.loewis.de>

> Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?

Next, I want to have distutils (build_py) to invoke 2to3 as a 
command-line tool. I think this will already cover most uses
that people may have.

Moving lib2to3 into the standard library would mean that the
trunk and 3k copies diverge, right?

There is also the question how then pgen2 should be in
the standard library; it could either be a top-level
package, or a subpackage of lib2to3.

Regards,
Martin

From greg at krypto.org  Sun Mar 16 21:22:08 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 16 Mar 2008 15:22:08 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <frjnd8$u5r$1@ger.gmane.org>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<frjnd8$u5r$1@ger.gmane.org>
Message-ID: <52dc1c820803161322r4ed68f30lfc59519b35de47a8@mail.gmail.com>

On 3/16/08, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
> Guido van Rossum wrote:
> > Moving this to a new subject to keep the discussion of tasks and the
> > discussion of task tracking tools separate.
> >
> > On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <lists at cheimes.de>
> wrote:
> >>  I did a quick brainstorming with me, myself and I. I came up with a
> list
> >>  of (IMHO) important tasks.
> >>
> >>  * Stabilize the C API of Python 3.0. I like to rename several prefixes
> >>  to reduce the confusing: PyBytes -> PyByteArray,
> >
> > +1 (also +1 to backporting this to 2.6)
> >
> >> PyString -> PyBytes ...
> >
> > -1. This will make merging code from 2.6 harder, and causes more work
> > for porting C extensions.
> >
> >>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
> >>  and he said he is trying to get it done during the PyCon sprint. Maybe
> >>  somebody can assist him?
> >
> > Does he need assistance?
>
>
> I don't really need help with back-porting the protocol.   However, I do
> need help with the struct module changes.  This is a standard-library
> that I'm hoping to get help with.
>
> -Travis


I'm happy to help with this stuff during the sprint.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/8e2bb33d/attachment.htm 

From g.brandl at gmx.net  Sun Mar 16 21:34:49 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 16 Mar 2008 21:34:49 +0100
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD795B.20507@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
Message-ID: <frk048$q87$1@ger.gmane.org>

Martin v. L?wis schrieb:
> After talking to Collin, I just committed a change to
> 2to3 to make it installable as an executable script
> called "2to3".
> 
> To do so, I had to wrap all the top-level modules
> into a package, and move the fixes and tests into
> that package. Lacking a better name, I called the
> library lib2to3. I also install pgen2 as a separate
> package.

Cool! With that in the 3k stdlib, the auto2to3 hook [1] will
work out of the box...

(It seems you missed a few old-style relative imports
in refactor.py, patcomp.py and pygram.py...)

cheers,
Georg

[1] http://dev.pocoo.org/hg/sandbox/file/tip/auto2to3.py


From guido at python.org  Sun Mar 16 21:42:00 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 15:42:00 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD7EDF.2070608@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
Message-ID: <ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>

On Sun, Mar 16, 2008 at 3:11 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?
>
>  Next, I want to have distutils (build_py) to invoke 2to3 as a
>  command-line tool. I think this will already cover most uses
>  that people may have.

Are you serious?

>  Moving lib2to3 into the standard library would mean that the
>  trunk and 3k copies diverge, right?

Not necessarily. If you check it into 2.6 first, then merge and apply
it to its merged self, afterwards most changes would merge into 3.0
just fine.

>  There is also the question how then pgen2 should be in
>  the standard library; it could either be a top-level
>  package, or a subpackage of lib2to3.

I'd like to clean it up and make it a toplevel package. But I may not
have the time, so until I do (or someone else does) it's best to keep
it inside lib2to3.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 21:54:51 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 15:54:51 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <frjoii$1oc$1@ger.gmane.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
	<1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
	<frjoii$1oc$1@ger.gmane.org>
Message-ID: <ca471dc20803161354j61e36aaetdb71b1b350240ac5@mail.gmail.com>

I don't see a lot of objections left against using the bug tracker. I
just talked to Neal and he's going to transfer all tasks from the 2.6
spreadsheet to the bug tracker.

I'll also be adding various other tasks., as I think of them.

We'll have to think about which keywords to use. We'll probably pick
the initial set of keywords at the sprint tomorrow morning.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sun Mar 16 21:56:52 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 15:56:52 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
Message-ID: <ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>

On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <barry at python.org> wrote:
>  I mentioned this to Guido and got a positive response, so let me state
>  my preference for your feedback.  I plan on holding up the final
>  releases until both versions are ready to go.  I think this will help
>  motivate us to give Python 2.6 the love it needs if it's lagging
>  behind 3.0, and I completely agree with Guido that this let's our
>  community know that both versions are equally important to us.

It's a deal.

>  The other thing is that I'd really like is a "show stoppers" Roundup
>  search.  The idea is that if our core buildbots look good and the
>  "show stoppers" search turns up no items, then I know I can cut a
>  release (at least for alphas, betas, and rcs).  If there are "show
>  stoppers" then I have something that I can triage (and maybe re-assign
>  severity) or start publicly harassing people into fixing.

How about using the "critical" Severity for show stoppers?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sun Mar 16 22:07:06 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 16:07:06 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>	
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>	
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
Message-ID: <47DD8BFA.1020108@v.loewis.de>

>>> Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?
>>  Next, I want to have distutils (build_py) to invoke 2to3 as a
>>  command-line tool. I think this will already cover most uses
>>  that people may have.
> 
> Are you serious?

Wrt. invoking it from distutils: Why not?

Wrt. this covering all uses: Surely the ones that people
would use the library for, no?

>>  Moving lib2to3 into the standard library would mean that the
>>  trunk and 3k copies diverge, right?
> 
> Not necessarily. If you check it into 2.6 first, then merge and apply
> it to its merged self, afterwards most changes would merge into 3.0
> just fine.

Ok, I'll do that.

We should decide which of the copies remains the master, and
which copies use merge-tracking. I would propose the sandbox
copy remains the one where we check in stuff, so that 2to3
can still get distributed as a stand-alone application.

> I'd like to clean it up and make it a toplevel package. But I may not
> have the time, so until I do (or someone else does) it's best to keep
> it inside lib2to3.

Ok, I'll move it into lib2to3 then also.

Regards,
Martin


From guido at python.org  Sun Mar 16 22:11:15 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 16:11:15 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD8BFA.1020108@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
Message-ID: <ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>

On Sun, Mar 16, 2008 at 4:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> >>> Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?
>  >>  Next, I want to have distutils (build_py) to invoke 2to3 as a
>  >>  command-line tool. I think this will already cover most uses
>  >>  that people may have.
>  >
>  > Are you serious?
>
>  Wrt. invoking it from distutils: Why not?

Because it's far from perfect. I'd expect the success rate of running
2to3 over a 2.x package to be close to zero. I think this is one case
where it's better to let the developer run 2to3 and tweak the app
until it actually works.

>  Wrt. this covering all uses: Surely the ones that people
>  would use the library for, no?

I not understand. :-(

>  >>  Moving lib2to3 into the standard library would mean that the
>  >>  trunk and 3k copies diverge, right?
>  >
>  > Not necessarily. If you check it into 2.6 first, then merge and apply
>  > it to its merged self, afterwards most changes would merge into 3.0
>  > just fine.
>
>  Ok, I'll do that.
>
>  We should decide which of the copies remains the master, and
>  which copies use merge-tracking. I would propose the sandbox
>  copy remains the one where we check in stuff, so that 2to3
>  can still get distributed as a stand-alone application.

That makes sense.

>  > I'd like to clean it up and make it a toplevel package. But I may not
>  > have the time, so until I do (or someone else does) it's best to keep
>  > it inside lib2to3.
>
>  Ok, I'll move it into lib2to3 then also.

Great!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sun Mar 16 22:22:37 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 16:22:37 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>	
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>	
	<47DD7EDF.2070608@v.loewis.de>	
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>	
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
Message-ID: <47DD8F9D.2000609@v.loewis.de>

>>  Wrt. invoking it from distutils: Why not?
> 
> Because it's far from perfect. I'd expect the success rate of running
> 2to3 over a 2.x package to be close to zero. I think this is one case
> where it's better to let the developer run 2to3 and tweak the app
> until it actually works.

Ah. I still dream of people being able to use a single source for both
2.x and 3.x. They would maintain their source as 2.x, and convert to
3.0 at deployment time.

Of course, they have to change their source to make that actual work.
Most distutils projects probably won't work when all you do is run
2to3. However, if a project has prepared its source in a proper way
(for some definition of "proper"), it *should* be possible that all
remaining changes are done by 2to3.

People would try the process on their development machines, and change
the code until it actually runs under both versions.

I'll be using my sprinting time to find out whether that approach
can actually work.

>>  Wrt. this covering all uses: Surely the ones that people
>>  would use the library for, no?
> 
> I not understand. :-(

When people requested that 2to3 is a library, I think they
have exactly that use case in mind: programmatically convert
a source code base at deployment/build time. In those cases,
they can achieve the same thing with the command line tool.

Of course, on Windows, it is probably still better to use
the library, since Python will find the library, but may
not find the command line tool.

Regards,
Martin


From greg at krypto.org  Sun Mar 16 22:38:48 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 16 Mar 2008 16:38:48 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803161354j61e36aaetdb71b1b350240ac5@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
	<1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
	<frjoii$1oc$1@ger.gmane.org>
	<ca471dc20803161354j61e36aaetdb71b1b350240ac5@mail.gmail.com>
Message-ID: <52dc1c820803161438wcb14acfw7e5fb2e6b482233d@mail.gmail.com>

On 3/16/08, Guido van Rossum <guido at python.org> wrote:
>
> I don't see a lot of objections left against using the bug tracker. I
> just talked to Neal and he's going to transfer all tasks from the 2.6
> spreadsheet to the bug tracker.
>
> I'll also be adding various other tasks., as I think of them.


yay, thanks Neal!

We'll have to think about which keywords to use. We'll probably pick
> the initial set of keywords at the sprint tomorrow morning.
>
> --
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/c176eeeb/attachment.htm 

From guido at python.org  Sun Mar 16 22:43:03 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 16:43:03 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD8F9D.2000609@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
	<47DD8F9D.2000609@v.loewis.de>
Message-ID: <ca471dc20803161443y273958cctf032fc22f9c23e9e@mail.gmail.com>

On Sun, Mar 16, 2008 at 4:22 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> >>  Wrt. invoking it from distutils: Why not?
>  >
>  > Because it's far from perfect. I'd expect the success rate of running
>  > 2to3 over a 2.x package to be close to zero. I think this is one case
>  > where it's better to let the developer run 2to3 and tweak the app
>  > until it actually works.
>
>  Ah. I still dream of people being able to use a single source for both
>  2.x and 3.x. They would maintain their source as 2.x, and convert to
>  3.0 at deployment time.
>
>  Of course, they have to change their source to make that actual work.
>  Most distutils projects probably won't work when all you do is run
>  2to3. However, if a project has prepared its source in a proper way
>  (for some definition of "proper"), it *should* be possible that all
>  remaining changes are done by 2to3.
>
>  People would try the process on their development machines, and change
>  the code until it actually runs under both versions.
>
>  I'll be using my sprinting time to find out whether that approach
>  can actually work.

That would be good. I agree with the ideal process, but I doubt that
it will realistically work exactly like that, so I expect that calling
2to3 upon install is just going to cost a lot of CPU time and then
produce a non-working install.

>  >>  Wrt. this covering all uses: Surely the ones that people
>  >>  would use the library for, no?
>  >
>  > I not understand. :-(
>
>  When people requested that 2to3 is a library, I think they
>  have exactly that use case in mind: programmatically convert
>  a source code base at deployment/build time. In those cases,
>  they can achieve the same thing with the command line tool.

I don't recall what the person who asked about this after my keynote
had in mind, but it sounds to me like converting code at install time
a minority use case -- especially while 2to3 is as slow as it is.

>  Of course, on Windows, it is probably still better to use
>  the library, since Python will find the library, but may
>  not find the command line tool.

Good point.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sun Mar 16 23:02:38 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 17:02:38 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
Message-ID: <47DD98FE.2040705@v.loewis.de>


> How about using the "critical" Severity for show stoppers?

Alternatively, Priority "immediate" could be used.

The intended use of Severity is that it is assigned by the
submitter, whereas Priority is assigned by triage/developers.

We should really decide whether we want to use it that way.

Regards,
Martin

From guido at python.org  Sun Mar 16 23:13:04 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 17:13:04 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <47DD98FE.2040705@v.loewis.de>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
Message-ID: <ca471dc20803161513m4694246axc9eb0cb555e2b5bd@mail.gmail.com>

On Sun, Mar 16, 2008 at 5:02 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
>  > How about using the "critical" Severity for show stoppers?
>
>  Alternatively, Priority "immediate" could be used.
>
>  The intended use of Severity is that it is assigned by the
>  submitter, whereas Priority is assigned by triage/developers.

Yeah, well, that's the theory. I've never met anyone who understoon
the distinction between priority and severity (you may be the
exception :-). The subjective severity as perceived by the reporter is
not all that useful, and it is probably better expressed in English.
Personally, if we were to "grade" bugs on a second scale besides
priority, I'd much rather have a scale to indicate the expected amount
of work, from "one-char fix" at one end of the scale to "requires
complete rewrite of the universe" at the other end.

>  We should really decide whether we want to use it that way.

Thinking it over, I actually believe that we should use the highest
priority to indicate show-stoppers that hold up a release. So that is
indeed "immediate".

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Sun Mar 16 23:20:56 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 16 Mar 2008 18:20:56 -0400
Subject: [Python-3000] Using *a for packing in lists and other places
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com><frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
Message-ID: <frk6g8$dpt$1@ger.gmane.org>


"Thomas Wouters" <thomas at python.org> wrote in message 
news:9e804ac0803151513j495be5d8h22bba219148cf491 at mail.gmail.com...
| On Sat, Mar 15, 2008 at 2:58 PM, Terry Reedy <tjreedy at udel.edu> wrote:
|
| >
| > | Also, yielding everything from an iterator:
| > |
| > | >>> def flatten(iterables):
| > | ...     for it in iterables:
| > | ...         yield *it
| >
| > Following the general rule above for *exp, that would be the same as 
yield
| > tuple(it).
|
|
| No. *exp by itself is not valid syntax:

That may be a fact for your patch but not for all possible patches ;-)

| >>> a, b = *c
|  File "<stdin>", line 1
| SyntaxError: can use starred expression only as assignment target
|
| It needs something to unpack *into*, in the immediate context.

Ditto.

My main desire is that *iterable have a simple (easily learnable) 
consistent meaning.  (Part of consistency is having it work the same both 
in and out of function calls).

The rule I suggested is 'execute the statement the same *as if*  the 
iterable items had been written in the code as a comma sequence'.  In the 
above, the result would be a tuple.  (For targets, the meaning is similar: 
*x means, in effect, x[0], x[1], etc, with x sized as needed at runtime.)

The fact that the '*' would be redundant in some contexts and therefore 
useless should not necessarily make it syntax error in that context.

if bool(e): pass # and
if bool(e) is True: pass

are both allowed even thought equivalent to 'if e: pass'.




From stephen at xemacs.org  Sun Mar 16 23:52:56 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 17 Mar 2008 07:52:56 +0900
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<1afaf6160803160919qbf49800n584ea4f965ebc6b2@mail.gmail.com>
	<ca471dc20803160937r7678eab3p2e75ebd50d2ba6a9@mail.gmail.com>
	<1afaf6160803160951l7a580ee8i796bcfe77d424cf8@mail.gmail.com>
Message-ID: <87myoyi8mv.fsf@uwakimon.sk.tsukuba.ac.jp>

Benjamin Peterson writes:

 > It's just depends on how you see the tracker. It's not just to "bug" tracker
 > anymore, is it? On other projects I've worked with, we had separate areas
 > for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
 > keep organized. However, if this is Python's way, I'm not going to stand in
 > it.

You (as an ordinary user) can have it both ways in the same instance.

If Martin adds a "task" issue type (which is easy to do in Roundup),
then you personally can create and save queries for "task", "bug",
"feature", etc.  Your view of the database will then be more like
sourceforge.

On the other hand, cross-referencing and creating dependencies across
issue types becomes a lot easier if they're in the same database.
That's important for some issues.

 > > > We could change the statuses around to "Work in progress", "Completed",
 > > > "Incomplete", and such. It'd be easy to search for tasks that have to be
 > > > accomplished for a given release.

I've done this for XEmacs's tracker.  It's definitely feasible.  I'm
subscribed to tracker-discuss, so I'll not go into detail here.


From ncoghlan at gmail.com  Sun Mar 16 23:57:55 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 17 Mar 2008 08:57:55 +1000
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <ca471dc20803161443y273958cctf032fc22f9c23e9e@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>	<47DD7EDF.2070608@v.loewis.de>	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>	<47DD8BFA.1020108@v.loewis.de>	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>	<47DD8F9D.2000609@v.loewis.de>
	<ca471dc20803161443y273958cctf032fc22f9c23e9e@mail.gmail.com>
Message-ID: <47DDA5F3.8090207@gmail.com>

Guido van Rossum wrote:
> On Sun, Mar 16, 2008 at 4:22 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>  People would try the process on their development machines, and change
>>  the code until it actually runs under both versions.
>>
>>  I'll be using my sprinting time to find out whether that approach
>>  can actually work.
> 
> That would be good. I agree with the ideal process, but I doubt that
> it will realistically work exactly like that, so I expect that calling
> 2to3 upon install is just going to cost a lot of CPU time and then
> produce a non-working install.

I was thinking that a comment based "directives" approach ala doctest 
might help with some of the trickier 2->3 migrations. For example, 
allowing someone to write an explicit conversion for a particular line:

   for x, y, in my_izip(s1, s2): # 2to3: for x, y, in zip(s1, s2):

(Dodgy example I know, but it gives the general idea)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg at krypto.org  Mon Mar 17 00:12:34 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 16 Mar 2008 18:12:34 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DDA5F3.8090207@gmail.com>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
	<47DD8F9D.2000609@v.loewis.de>
	<ca471dc20803161443y273958cctf032fc22f9c23e9e@mail.gmail.com>
	<47DDA5F3.8090207@gmail.com>
Message-ID: <52dc1c820803161612u244dc42bq35dcadf5475c21d2@mail.gmail.com>

On 3/16/08, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> Guido van Rossum wrote:
> > On Sun, Mar 16, 2008 at 4:22 PM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
>
> >>  People would try the process on their development machines, and change
> >>  the code until it actually runs under both versions.
> >>
> >>  I'll be using my sprinting time to find out whether that approach
> >>  can actually work.
> >
> > That would be good. I agree with the ideal process, but I doubt that
> > it will realistically work exactly like that, so I expect that calling
> > 2to3 upon install is just going to cost a lot of CPU time and then
> > produce a non-working install.
>
>
> I was thinking that a comment based "directives" approach ala doctest
> might help with some of the trickier 2->3 migrations. For example,
> allowing someone to write an explicit conversion for a particular line:
>
>    for x, y, in my_izip(s1, s2): # 2to3: for x, y, in zip(s1, s2):
>
> (Dodgy example I know, but it gives the general idea)


thats a good idea.  do we want a comment to contain the alternate code or
should the comment just indicate which way a particular predefined set of
known 2to3 difficult things should be interpreted during conversion?

parallel code is nice.  but long lines will become annoying.  this should
allow for the comment to be on the line below as well maybe?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/87754f0d/attachment-0001.htm 

From guido at python.org  Mon Mar 17 00:20:59 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 16 Mar 2008 18:20:59 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <52dc1c820803161612u244dc42bq35dcadf5475c21d2@mail.gmail.com>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
	<47DD8F9D.2000609@v.loewis.de>
	<ca471dc20803161443y273958cctf032fc22f9c23e9e@mail.gmail.com>
	<47DDA5F3.8090207@gmail.com>
	<52dc1c820803161612u244dc42bq35dcadf5475c21d2@mail.gmail.com>
Message-ID: <ca471dc20803161620j4ed950f1ja94f9de83d716bdb@mail.gmail.com>

On Sun, Mar 16, 2008 at 6:12 PM, Gregory P. Smith <greg at krypto.org> wrote:
> On 3/16/08, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Guido van Rossum wrote:
> > > On Sun, Mar 16, 2008 at 4:22 PM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> >
> > >>  People would try the process on their development machines, and change
> > >>  the code until it actually runs under both versions.
> > >>
> > >>  I'll be using my sprinting time to find out whether that approach
> > >>  can actually work.
> > >
> > > That would be good. I agree with the ideal process, but I doubt that
> > > it will realistically work exactly like that, so I expect that calling
> > > 2to3 upon install is just going to cost a lot of CPU time and then
> > > produce a non-working install.
> >
> >
> > I was thinking that a comment based "directives" approach ala doctest
> > might help with some of the trickier 2->3 migrations. For example,
> > allowing someone to write an explicit conversion for a particular line:
> >
> >    for x, y, in my_izip(s1, s2): # 2to3: for x, y, in zip(s1, s2):
> >
> > (Dodgy example I know, but it gives the general idea)
>
> thats a good idea.  do we want a comment to contain the alternate code or
> should the comment just indicate which way a particular predefined set of
> known 2to3 difficult things should be interpreted during conversion?
>
> parallel code is nice.  but long lines will become annoying.  this should
> allow for the comment to be on the line below as well maybe?

I think the parallel code idea is too complex. 2to3 doesn't really
think in terms of lines anyway. I think we should just have a
directive to prevent 2to3 from applying a certain fixer to the line
containing the directive.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Mon Mar 17 00:25:09 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 18:25:09 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803161513m4694246axc9eb0cb555e2b5bd@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>	
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>	
	<47DD98FE.2040705@v.loewis.de>
	<ca471dc20803161513m4694246axc9eb0cb555e2b5bd@mail.gmail.com>
Message-ID: <47DDAC55.7030206@v.loewis.de>

> Thinking it over, I actually believe that we should use the highest
> priority to indicate show-stoppers that hold up a release. So that is
> indeed "immediate".

We just decided to eliminate the Severity from the tracker; it wasn't
much used and always confused people. It's still in the database, just
not displayed anymore.

Regards,
Martin


From greg.ewing at canterbury.ac.nz  Mon Mar 17 00:33:11 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 17 Mar 2008 11:33:11 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <9e804ac0803160735x62b5e268gc0c6e03c6f6b0338@mail.gmail.com>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC72CC.4050603@canterbury.ac.nz>
	<9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>
	<47DCBD8C.5000307@canterbury.ac.nz>
	<9e804ac0803160735x62b5e268gc0c6e03c6f6b0338@mail.gmail.com>
Message-ID: <47DDAE37.7070702@canterbury.ac.nz>

Thomas Wouters wrote:
> 
> [Guido] asked for 'f(*a, b, c)' to be valid, but it only makes sense 
> to allow, say, 'f(*a, b, *c)' too, and he hasn't said 'no' to that.

And then, of course, people are going to want
to have multiple ** arguments, too...

-- 
Greg

From pje at telecommunity.com  Mon Mar 17 00:43:36 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 16 Mar 2008 19:43:36 -0400
Subject: [Python-3000] Using *a for packing in lists and other  places
In-Reply-To: <ca471dc20803161249u65b1c0ffl4ddc0bbf09afed0a@mail.gmail.co
 m>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<ca471dc20803151521k45b3117asc18e9b038605c890@mail.gmail.com>
	<9e804ac0803151601k9d6dfd8u973d3dec52d5ef0a@mail.gmail.com>
	<ca471dc20803160800w18d7abb4u8734c8c6e50adab4@mail.gmail.com>
	<20080316174832.7E4983A40FF@sparrow.telecommunity.com>
	<ca471dc20803161055k6051de0an61a59dd758b7e04d@mail.gmail.com>
	<20080316183200.E63CA3A409D@sparrow.telecommunity.com>
	<ca471dc20803161249u65b1c0ffl4ddc0bbf09afed0a@mail.gmail.com>
Message-ID: <20080316234347.5018C3A409D@sparrow.telecommunity.com>

At 02:49 PM 3/16/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 1:31 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> >  Btw, would you mind pronouncing (or at least commenting) on PEP 365,
> >  so that I can proceed with the work -- or not.
>
>Can you point me to past discussions? ISTR that this is controversial.

The original discussion thread is here...

http://mail.python.org/pipermail/python-dev/2007-May/thread.html#72891

It mainly discusses why MAL's counterproposals to revamp the API, 
split into multiple modules, etc.,  did not address any of the PEP's 
goals or rationale.

And here is the second thread, which is mostly support/encouragement 
for adding setuptools to the stdlib, or at least pkg_resources:

http://mail.python.org/pipermail/python-dev/2008-January/thread.html#76379

The thread subject is "PEP: per-user site-packages directory", but 
beginning with that message from Steve Holden, the entire thread is 
about PEP 365.

As far as I can tell, the proposal has seen much more Usenet Nod 
Syndrome than controversy.  None, actually, outside of MAL's 
objections.  Even MvL voiced support for actually expanding the 
proposal to include an 'easy_install' stub:

http://mail.python.org/pipermail/python-dev/2008-January/076391.html

Oh, and there is one additional discussion here, sort of...

http://mail.python.org/pipermail/python-dev/2008-January/075922.html

but despite the subject line, it wasn't really about the PEP at 
all!  The entire discussion ended up being about whether namespace 
packages should be used in the stdlib, and the consensus was "no", 
because (among other things) the real benefit of namespace packages 
is to allow an *organization* to claim a package space (e.g. zope.*), 
not to "make all the doctors in town live on the same street", as you 
put it.  :)  Here's a good summary:

http://mail.python.org/pipermail/python-dev/2008-January/075952.html


From barry at python.org  Mon Mar 17 00:46:50 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 16 Mar 2008 18:46:50 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
Message-ID: <5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 16, 2008, at 3:56 PM, Guido van Rossum wrote:

> On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <barry at python.org>  
> wrote:
>> I mentioned this to Guido and got a positive response, so let me  
>> state
>> my preference for your feedback.  I plan on holding up the final
>> releases until both versions are ready to go.  I think this will help
>> motivate us to give Python 2.6 the love it needs if it's lagging
>> behind 3.0, and I completely agree with Guido that this let's our
>> community know that both versions are equally important to us.
>
> It's a deal.

Excellent.

>> The other thing is that I'd really like is a "show stoppers" Roundup
>> search.  The idea is that if our core buildbots look good and the
>> "show stoppers" search turns up no items, then I know I can cut a
>> release (at least for alphas, betas, and rcs).  If there are "show
>> stoppers" then I have something that I can triage (and maybe re- 
>> assign
>> severity) or start publicly harassing people into fixing.
>
> How about using the "critical" Severity for show stoppers?

'critical' is fine (or 'immediate').  My problem before was that I  
couldn't do one query that gave me all the critical issues for both  
2.6 and 3.0.  That certainly could have been pebkac though.  Neal  
mentioned that that kind of query should be possible, if it's not  
already there.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR92xb3EjvBPtnXfVAQLZGQP+O+FQwlXDXAT5lz+DKPer7+5n9ivy/YmD
94RYUnHEsVLA5aWpZB0O23/wVavS5FdUfJxuCvMOwHhZ6i58GHF4i6gfrtWDefX7
BWSfm82rIOAw/UX10JiUpkPp7vRlqfPdPOteqzFq0yo0vM49HOqFOL5fIU02MbRj
unVdo8uYJ5c=
=SB9I
-----END PGP SIGNATURE-----

From barry at python.org  Mon Mar 17 00:48:48 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 16 Mar 2008 18:48:48 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <47DD98FE.2040705@v.loewis.de>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
Message-ID: <4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:

>> How about using the "critical" Severity for show stoppers?
>
> Alternatively, Priority "immediate" could be used.
>
> The intended use of Severity is that it is assigned by the
> submitter, whereas Priority is assigned by triage/developers.
>
> We should really decide whether we want to use it that way.

That would certainly work for me.  Could we add some description of  
this separation to the Roundup pages?  And/or is there a way that only  
developers or the triage specialists are allowed to change the priority?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
WwlDBlduW0g=
=/42B
-----END PGP SIGNATURE-----

From thomas at python.org  Mon Mar 17 01:15:55 2008
From: thomas at python.org (Thomas Wouters)
Date: Sun, 16 Mar 2008 17:15:55 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <47DDAE37.7070702@canterbury.ac.nz>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<47DC72CC.4050603@canterbury.ac.nz>
	<9e804ac0803151846k6baec5dch34bf550791dab9b7@mail.gmail.com>
	<47DCBD8C.5000307@canterbury.ac.nz>
	<9e804ac0803160735x62b5e268gc0c6e03c6f6b0338@mail.gmail.com>
	<47DDAE37.7070702@canterbury.ac.nz>
Message-ID: <9e804ac0803161715x245a89b1y701b4fb4b3ab0ea4@mail.gmail.com>

On Sun, Mar 16, 2008 at 4:33 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Thomas Wouters wrote:
> >
> > [Guido] asked for 'f(*a, b, c)' to be valid, but it only makes sense
> > to allow, say, 'f(*a, b, *c)' too, and he hasn't said 'no' to that.
>
> And then, of course, people are going to want
> to have multiple ** arguments, too...
>

Of course. Anything worth doing is worth doing right. The grammar changes
are done (and it turns out much simpler without these restrictions), if it
weren't for this horrible cold I would have a patch for it up already.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080316/ac3f2d97/attachment.htm 

From greg.ewing at canterbury.ac.nz  Mon Mar 17 01:35:58 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 17 Mar 2008 12:35:58 +1200
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DD8F9D.2000609@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
	<47DD8F9D.2000609@v.loewis.de>
Message-ID: <47DDBCEE.3050807@canterbury.ac.nz>

Martin v. L?wis wrote:
> When people requested that 2to3 is a library, I think they
> have exactly that use case in mind: programmatically convert
> a source code base at deployment/build time.

For importability as a library, would it be better
to call it two2three?

-- 
Greg

From greg.ewing at canterbury.ac.nz  Mon Mar 17 01:39:15 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 17 Mar 2008 12:39:15 +1200
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <frk6g8$dpt$1@ger.gmane.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<frk6g8$dpt$1@ger.gmane.org>
Message-ID: <47DDBDB3.40703@canterbury.ac.nz>

Terry Reedy wrote:
> The fact that the '*' would be redundant in some contexts and therefore 
> useless should not necessarily make it syntax error in that context.

It does allow a lone *exp to be given a special
meaning in some contexts, such as yield *exp.
Although I'm still not sure that's a good idea.

-- 
Greg

From martin at v.loewis.de  Mon Mar 17 05:34:51 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 23:34:51 -0500
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DDBCEE.3050807@canterbury.ac.nz>
References: <47DD795B.20507@v.loewis.de>	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>	<47DD7EDF.2070608@v.loewis.de>	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>	<47DD8BFA.1020108@v.loewis.de>	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>	<47DD8F9D.2000609@v.loewis.de>
	<47DDBCEE.3050807@canterbury.ac.nz>
Message-ID: <47DDF4EB.4020501@v.loewis.de>

>> When people requested that 2to3 is a library, I think they
>> have exactly that use case in mind: programmatically convert
>> a source code base at deployment/build time.
> 
> For importability as a library, would it be better
> to call it two2three?

Not sure whom you are asking. It's currently called lib2to3,
so I can't see why two2three would be better (I just notice
that it is more difficult to type for me than lib2to3).

Regards,
Martin


From abpillai at gmail.com  Mon Mar 17 08:48:21 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Mon, 17 Mar 2008 13:18:21 +0530
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
Message-ID: <8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>

Hi py3k,

     First of all, excuse me for taking your time. I am new to the list
so, not familiar with the processes specific to the list, if any.

     I am new to the list (joined a week back) but not new to Python having
coded in it for a fair bit of time and contributed open source code in Python,
but not yet to the Python project.

    I have been reading the py3k archives and some recent mails. I
would like to help out in some way. I am familiar with the Python
development process and has read most of the PEPs related to
Py3k. Perhaps there are some bugs to fix, some documentation to
be done, testing ... ?

    Excuse me if I sound naive, but I am not sure where to start.
I checked out py3k branch, built it and have it running on my Fedora box.
Is there a URL showing a list of tasks to start with so I can start on
something ?

Did not want to start a new thread for my post, so replying to a thread
which seemed relevant.

Thanks a lot for your patience.

Best Regards

--Anand

http://harvestmanontheweb.com


On Mon, Mar 17, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
> On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:
>
>  >> How about using the "critical" Severity for show stoppers?
>  >
>  > Alternatively, Priority "immediate" could be used.
>  >
>  > The intended use of Severity is that it is assigned by the
>  > submitter, whereas Priority is assigned by triage/developers.
>  >
>  > We should really decide whether we want to use it that way.
>
>  That would certainly work for me.  Could we add some description of
>  this separation to the Roundup pages?  And/or is there a way that only
>  developers or the triage specialists are allowed to change the priority?
>
>
>  - -Barry
>
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.8 (Darwin)
>
>  iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
>  6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
>  eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
>  WwlDBlduW0g=
>  =/42B
>  -----END PGP SIGNATURE-----
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>



-- 
-Anand

From greg.ewing at canterbury.ac.nz  Mon Mar 17 09:34:01 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 17 Mar 2008 20:34:01 +1200
Subject: [Python-3000] Making 2to3 installable
In-Reply-To: <47DDF4EB.4020501@v.loewis.de>
References: <47DD795B.20507@v.loewis.de>
	<ca471dc20803161251jcc9e7dft950df8ed5ea85dc3@mail.gmail.com>
	<47DD7EDF.2070608@v.loewis.de>
	<ca471dc20803161342l733022cer36b1357840843311@mail.gmail.com>
	<47DD8BFA.1020108@v.loewis.de>
	<ca471dc20803161411y7997dbb5rafc3e559620e84d8@mail.gmail.com>
	<47DD8F9D.2000609@v.loewis.de> <47DDBCEE.3050807@canterbury.ac.nz>
	<47DDF4EB.4020501@v.loewis.de>
Message-ID: <47DE2CF9.4050609@canterbury.ac.nz>

Martin v. L?wis wrote:
> It's currently called lib2to3,
> so I can't see why two2three would be better

I was just thinking that '2to3' wouldn't be a valid
module name. I guess 'lib2to3' works too (or 2),
and is easier 2 type 2.

-- 
Greg

From qrczak at knm.org.pl  Mon Mar 17 11:56:52 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Mon, 17 Mar 2008 11:56:52 +0100
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <frk6g8$dpt$1@ger.gmane.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<frk6g8$dpt$1@ger.gmane.org>
Message-ID: <1205751413.13377.11.camel@qrnik>

Dnia 16-03-2008, N o godzinie 18:20 -0400, Terry Reedy pisze:

> The rule I suggested is 'execute the statement the same *as if*  the 
> iterable items had been written in the code as a comma sequence'.

One reason I don't like this rule is that it works on the level of the
token sequence rather than the AST. It's too low-level, relying on
peculiarities of the syntax rather than the meaning (does a=*b really
convert b to a tuple only because the tuple syntax uses lone commas?).
And it doesn't directly work for 0 or 1 items, in which case the
behavior must be extrapolated from the behavior for more items.

In my view the expression-level *a should be allowed in explicitly
listed contexts, mostly where there is already a sequence of expressions
to splice into: lists, tuples, sets, argument lists. And also in yield
and comprehensions, where it would be something new, allowing to
actually create the sequence which always had a single element before.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From musiccomposition at gmail.com  Mon Mar 17 13:52:29 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 17 Mar 2008 07:52:29 -0500
Subject: [Python-3000] New to Python-dev (was Re: [Python-Dev] 2.6 and 3.0
	project management)
Message-ID: <1afaf6160803170552g6583d548m2641e8afbf1b10d8@mail.gmail.com>

On Mon, Mar 17, 2008 at 2:48 AM, Anand Balachandran Pillai <
abpillai at gmail.com> wrote:

> Hi py3k,
>
>     First of all, excuse me for taking your time. I am new to the list
> so, not familiar with the processes specific to the list, if any.



>
>
>     I am new to the list (joined a week back) but not new to Python having
> coded in it for a fair bit of time and contributed open source code in
> Python,
> but not yet to the Python project.

Welcome

>
>
>    I have been reading the py3k archives and some recent mails. I
> would like to help out in some way. I am familiar with the Python
> development process and has read most of the PEPs related to
> Py3k. Perhaps there are some bugs to fix, some documentation to
> be done, testing ... ?
>
>    Excuse me if I sound naive, but I am not sure where to start.
> I checked out py3k branch, built it and have it running on my Fedora box.
> Is there a URL showing a list of tasks to start with so I can start on
> something ?

Have you read all the information at http://python.org/dev/?
Have you looked at the bug tracker, http://bugs.python.org?

>
>
> Did not want to start a new thread for my post, so replying to a thread
> which seemed relevant.

It would have been fine to start a new thread as I just did. It helps keep
the conversation organized.

>
>
> Thanks a lot for your patience.
>
> Best Regards
>
> --Anand
>
> http://harvestmanontheweb.com
>
>
> On Mon, Mar 17, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >  Hash: SHA1
> >
> >
> > On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:
> >
> >  >> How about using the "critical" Severity for show stoppers?
> >  >
> >  > Alternatively, Priority "immediate" could be used.
> >  >
> >  > The intended use of Severity is that it is assigned by the
> >  > submitter, whereas Priority is assigned by triage/developers.
> >  >
> >  > We should really decide whether we want to use it that way.
> >
> >  That would certainly work for me.  Could we add some description of
> >  this separation to the Roundup pages?  And/or is there a way that only
> >  developers or the triage specialists are allowed to change the
> priority?
> >
> >
> >  - -Barry
> >
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.8 (Darwin)
> >
> >  iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
> >  6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
> >  eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
> >  WwlDBlduW0g=
> >  =/42B
> >  -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> >  Python-3000 mailing list
> >  Python-3000 at python.org
> >  http://mail.python.org/mailman/listinfo/python-3000
> >  Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
> >
>
>
>
> --
> -Anand
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080317/5d73a611/attachment.htm 

From guido at python.org  Mon Mar 17 14:38:23 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 17 Mar 2008 08:38:23 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
	<8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>
Message-ID: <ca471dc20803170638v4704ab63g2539d9c1f0d9d6fe@mail.gmail.com>

Glad you want to help!

You can find plenty of things to do in the bug tracker at
bugs.python.org. Note that 2.6 needs as much (or more!) love as 3.0 at
this point. (2.6 is being developed in the svn trunk.) Feel free to
tentatively pick a project and send mail here asking if that's
something we'd like to have fixed.

Again, thanks!

--Guido

On Mon, Mar 17, 2008 at 2:48 AM, Anand Balachandran Pillai
<abpillai at gmail.com> wrote:
> Hi py3k,
>
>      First of all, excuse me for taking your time. I am new to the list
>  so, not familiar with the processes specific to the list, if any.
>
>      I am new to the list (joined a week back) but not new to Python having
>  coded in it for a fair bit of time and contributed open source code in Python,
>  but not yet to the Python project.
>
>     I have been reading the py3k archives and some recent mails. I
>  would like to help out in some way. I am familiar with the Python
>  development process and has read most of the PEPs related to
>  Py3k. Perhaps there are some bugs to fix, some documentation to
>  be done, testing ... ?
>
>     Excuse me if I sound naive, but I am not sure where to start.
>  I checked out py3k branch, built it and have it running on my Fedora box.
>  Is there a URL showing a list of tasks to start with so I can start on
>  something ?
>
>  Did not want to start a new thread for my post, so replying to a thread
>  which seemed relevant.
>
>  Thanks a lot for your patience.
>
>  Best Regards
>
>  --Anand
>
>  http://harvestmanontheweb.com
>
>
>
>
>  On Mon, Mar 17, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  >  Hash: SHA1
>  >
>  >
>  > On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:
>  >
>  >  >> How about using the "critical" Severity for show stoppers?
>  >  >
>  >  > Alternatively, Priority "immediate" could be used.
>  >  >
>  >  > The intended use of Severity is that it is assigned by the
>  >  > submitter, whereas Priority is assigned by triage/developers.
>  >  >
>  >  > We should really decide whether we want to use it that way.
>  >
>  >  That would certainly work for me.  Could we add some description of
>  >  this separation to the Roundup pages?  And/or is there a way that only
>  >  developers or the triage specialists are allowed to change the priority?
>  >
>  >
>  >  - -Barry
>  >
>  >  -----BEGIN PGP SIGNATURE-----
>  >  Version: GnuPG v1.4.8 (Darwin)
>  >
>  >  iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
>  >  6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
>  >  eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
>  >  WwlDBlduW0g=
>  >  =/42B
>  >  -----END PGP SIGNATURE-----
>  >
>  >
>
> > _______________________________________________
>  >  Python-3000 mailing list
>  >  Python-3000 at python.org
>  >  http://mail.python.org/mailman/listinfo/python-3000
>  >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>  >
>
>
>
>  --
>  -Anand
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Mon Mar 17 15:27:23 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 17 Mar 2008 09:27:23 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
Message-ID: <81BCED86-19FC-4BDC-9A2D-136FE484B3A6@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 16, 2008, at 6:46 PM, Barry Warsaw wrote:
>
> 'critical' is fine (or 'immediate').  My problem before was that I
> couldn't do one query that gave me all the critical issues for both
> 2.6 and 3.0.  That certainly could have been pebkac though.  Neal
> mentioned that that kind of query should be possible, if it's not
> already there.

So, I just looked again and that wasn't quite my problem.  When you  
search, it seems like you have a choice of version "don't care" or you  
can pick a single version.  But it looks like once you're on the  
search results you can further refine the version filter via the list  
box.  It's a little clunky, but it'll work.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR95/y3EjvBPtnXfVAQKlmgQAg+1azln0Ljb32iyoreALUwepHwrN0XLp
Fg6OVPp70iYIhctFhT3QYAN+59wzqy8x2PKsuZV/k48ebsJWwLsbU1yHH0WImHoo
56Dso3sfbsj2GzK7i3cF903RiIVE4geQRbnttDnrQVmI9U3jrs9iyWMjw/5Znohz
DtLTEEf2fQs=
=mQXt
-----END PGP SIGNATURE-----

From douglas at openplans.org  Mon Mar 17 15:54:06 2008
From: douglas at openplans.org (Douglas Mayle)
Date: Mon, 17 Mar 2008 10:54:06 -0400
Subject: [Python-3000] New to Python-dev (was Re: [Python-Dev] 2.6 and
	3.0 project management)
In-Reply-To: <1afaf6160803170552g6583d548m2641e8afbf1b10d8@mail.gmail.com>
References: <1afaf6160803170552g6583d548m2641e8afbf1b10d8@mail.gmail.com>
Message-ID: <22E35BF0-4E34-47A9-B4CB-2DFE6A1F5A48@openplans.org>

I accidentally sent this reply to Benjamin, sorry for the two copies:

I'm brand new on this list as well, so take what I say with a grain of  
salt, but a group of us here at PyCon are about to start sprinting,  
and they've given us some very good resources to help us get started.   
Brett Cannon is leading us, and he's put up some good info meant for  
the sprinters, but that should just apply anyway.  You can find the  
slides from his talk at:
http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf

Some important information that I took away from the slides is that  
there is a view into the python bug list where you have more control  
over display at:
http://www.taniquetil.com.ar/cgi-bin/pytickets.py

If you don't know what bugs to tackle, the python developers slap the  
'easy' keyword on the low hanging fruit, which should help you to pick  
something out.

Aside from that, they stressed that we should test test test before  
submitting patches to the bugtracker...

Douglas Mayle
The Open Planning Project

On Mar 17, 2008, at 8:52 AM, Benjamin Peterson wrote:

>
>
> On Mon, Mar 17, 2008 at 2:48 AM, Anand Balachandran Pillai <abpillai at gmail.com 
> > wrote:
> Hi py3k,
>
>     First of all, excuse me for taking your time. I am new to the list
> so, not familiar with the processes specific to the list, if any.
>
>
>
>     I am new to the list (joined a week back) but not new to Python  
> having
> coded in it for a fair bit of time and contributed open source code  
> in Python,
> but not yet to the Python project.
> Welcome
>
>
>    I have been reading the py3k archives and some recent mails. I
> would like to help out in some way. I am familiar with the Python
> development process and has read most of the PEPs related to
> Py3k. Perhaps there are some bugs to fix, some documentation to
> be done, testing ... ?
>
>    Excuse me if I sound naive, but I am not sure where to start.
> I checked out py3k branch, built it and have it running on my Fedora  
> box.
> Is there a URL showing a list of tasks to start with so I can start on
> something ?
> Have you read all the information at http://python.org/dev/?
> Have you looked at the bug tracker, http://bugs.python.org?
>
>
> Did not want to start a new thread for my post, so replying to a  
> thread
> which seemed relevant.
> It would have been fine to start a new thread as I just did. It  
> helps keep the conversation organized.
>
>
> Thanks a lot for your patience.
>
> Best Regards
>
> --Anand
>
> http://harvestmanontheweb.com
>
>
> On Mon, Mar 17, 2008 at 5:18 AM, Barry Warsaw <barry at python.org>  
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >  Hash: SHA1
> >
> >
> > On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:
> >
> >  >> How about using the "critical" Severity for show stoppers?
> >  >
> >  > Alternatively, Priority "immediate" could be used.
> >  >
> >  > The intended use of Severity is that it is assigned by the
> >  > submitter, whereas Priority is assigned by triage/developers.
> >  >
> >  > We should really decide whether we want to use it that way.
> >
> >  That would certainly work for me.  Could we add some description of
> >  this separation to the Roundup pages?  And/or is there a way that  
> only
> >  developers or the triage specialists are allowed to change the  
> priority?
> >
> >
> >  - -Barry
> >
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.8 (Darwin)
> >
> >  iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
> >  6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
> >  eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
> >  WwlDBlduW0g=
> >  =/42B
> >  -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> >  Python-3000 mailing list
> >  Python-3000 at python.org
> >  http://mail.python.org/mailman/listinfo/python-3000
> >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
> >
>
>
>
> --
> -Anand
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
> !DSPAM:4037,47de69a142047082231907!  
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/douglas%40openplans.org
>
>
> !DSPAM:4037,47de69a142047082231907!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080317/1f386b38/attachment-0001.htm 

From musiccomposition at gmail.com  Mon Mar 17 18:21:17 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 17 Mar 2008 12:21:17 -0500
Subject: [Python-3000] I/O stuff
Message-ID: <1afaf6160803171021p4b234ff9kb36a439ce32ddc8c@mail.gmail.com>

Hi,
What's the current status of I/O in Py3k?
Are plans there to implement some if not all of io.py in C. (If not, I can
work on this.)
Also, is I/O going to be backported to 2.6?

Thanks,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080317/9f6ea166/attachment.htm 

From guido at python.org  Mon Mar 17 18:25:47 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 17 Mar 2008 12:25:47 -0500
Subject: [Python-3000] I/O stuff
In-Reply-To: <1afaf6160803171021p4b234ff9kb36a439ce32ddc8c@mail.gmail.com>
References: <1afaf6160803171021p4b234ff9kb36a439ce32ddc8c@mail.gmail.com>
Message-ID: <ca471dc20803171025y21d68531we6f1da2ecafdc69@mail.gmail.com>

On Mon, Mar 17, 2008 at 12:21 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> What's the current status of I/O in Py3k?

Ping is looking at it. There are quite a few things broken in the
handling of seek/tell on text files.

> Are plans there to implement some if not all of io.py in C. (If not, I can
> work on this.)

IMO the text decoding (and perhaps encoding) should be redone in C,
it's way too slow. I'm not sure if Ping is planning to attack this
too.

> Also, is I/O going to be backported to 2.6?

Yes, but it's probably better to wait until the 3.0 version has stabilized.

PS. Are you at PyCon?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rhamph at gmail.com  Mon Mar 17 18:56:36 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Mon, 17 Mar 2008 11:56:36 -0600
Subject: [Python-3000] python-safethread project status
Message-ID: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>

Guido's asked me to give a quick status report, so here I go..

The critical parts of the design and implementation are basically
done.  I've implemented monitors to contain objects without an
explicit thread-safe API, which then let me remove the GIL.  I've
created a synchronous/asynchronous refcounting scheme that reuses our
existing INCREF/DECREF API, but also minimizes contention when used by
more than one thread.  The net result is that although there's a
significant amount of overhead, I can demonstrate scalability to more
than one thread (I've only been able to test with two cores though.)

I've replaced __del__ API (which resurrected objects) with a
__finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
in __finalizeattrs__ are proxied into a core object, a finalizer
thread is given a reference to the core, and when the main object is
deleted the GC asynchronously notifies the finalizer thread so that it
can call core.__finalize__().  The net result is an API very similar
to __del__ (you need to list attributes it might use), but it's now
impossible for the GC to run arbitrary code (I even enforce this).

Missing there is generator cleanup.  I don't allow the GC to run a
generator long enough to raise GeneratorExit, so an alternative will
be needed.

I'm currently working on flushing out the design.  I recently rewrote
and reenabled the tracing GC, next up is the automatic deadlock
detection/breaking.

As for merging back into CPython, I could build smaller patches, but
the design can't be completely separated.  For example, __finalize__
is called from another thread, so Monitor's @monitormethod should be
applied.  I don't specifically require Monitor, just that the object
(and therefor its methods) be shareable, and Monitor is the easiest
way to provide that.

-- 
Adam Olsen, aka Rhamphoryncus

From guido at python.org  Mon Mar 17 20:02:26 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 17 Mar 2008 14:02:26 -0500
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
Message-ID: <ca471dc20803171202g2e0a0187o76f98c9915e7c137@mail.gmail.com>

Thanks! Would you care to give us a hint on how a typical
multi-threaded application would be written using this approach? How
much pre-existing code would break do you expect?

On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <rhamph at gmail.com> wrote:
> Guido's asked me to give a quick status report, so here I go..
>
>  The critical parts of the design and implementation are basically
>  done.  I've implemented monitors to contain objects without an
>  explicit thread-safe API, which then let me remove the GIL.  I've
>  created a synchronous/asynchronous refcounting scheme that reuses our
>  existing INCREF/DECREF API, but also minimizes contention when used by
>  more than one thread.  The net result is that although there's a
>  significant amount of overhead, I can demonstrate scalability to more
>  than one thread (I've only been able to test with two cores though.)
>
>  I've replaced __del__ API (which resurrected objects) with a
>  __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>  in __finalizeattrs__ are proxied into a core object, a finalizer
>  thread is given a reference to the core, and when the main object is
>  deleted the GC asynchronously notifies the finalizer thread so that it
>  can call core.__finalize__().  The net result is an API very similar
>  to __del__ (you need to list attributes it might use), but it's now
>  impossible for the GC to run arbitrary code (I even enforce this).
>
>  Missing there is generator cleanup.  I don't allow the GC to run a
>  generator long enough to raise GeneratorExit, so an alternative will
>  be needed.
>
>  I'm currently working on flushing out the design.  I recently rewrote
>  and reenabled the tracing GC, next up is the automatic deadlock
>  detection/breaking.
>
>  As for merging back into CPython, I could build smaller patches, but
>  the design can't be completely separated.  For example, __finalize__
>  is called from another thread, so Monitor's @monitormethod should be
>  applied.  I don't specifically require Monitor, just that the object
>  (and therefor its methods) be shareable, and Monitor is the easiest
>  way to provide that.
>
>  --
>  Adam Olsen, aka Rhamphoryncus
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rhamph at gmail.com  Mon Mar 17 20:42:42 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Mon, 17 Mar 2008 13:42:42 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <ca471dc20803171202g2e0a0187o76f98c9915e7c137@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<ca471dc20803171202g2e0a0187o76f98c9915e7c137@mail.gmail.com>
Message-ID: <aac2c7cb0803171242s16f2bd47j7f1872a839fc8b68@mail.gmail.com>

On Mon, Mar 17, 2008 at 1:02 PM, Guido van Rossum <guido at python.org> wrote:
>  On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  > Guido's asked me to give a quick status report, so here I go..
>  >
>  >  The critical parts of the design and implementation are basically
>  >  done.  I've implemented monitors to contain objects without an
>  >  explicit thread-safe API, which then let me remove the GIL.  I've
>  >  created a synchronous/asynchronous refcounting scheme that reuses our
>  >  existing INCREF/DECREF API, but also minimizes contention when used by
>  >  more than one thread.  The net result is that although there's a
>  >  significant amount of overhead, I can demonstrate scalability to more
>  >  than one thread (I've only been able to test with two cores though.)
>  >
>  >  I've replaced __del__ API (which resurrected objects) with a
>  >  __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>  >  in __finalizeattrs__ are proxied into a core object, a finalizer
>  >  thread is given a reference to the core, and when the main object is
>  >  deleted the GC asynchronously notifies the finalizer thread so that it
>  >  can call core.__finalize__().  The net result is an API very similar
>  >  to __del__ (you need to list attributes it might use), but it's now
>  >  impossible for the GC to run arbitrary code (I even enforce this).
>  >
>  >  Missing there is generator cleanup.  I don't allow the GC to run a
>  >  generator long enough to raise GeneratorExit, so an alternative will
>  >  be needed.
>  >
>  >  I'm currently working on flushing out the design.  I recently rewrote
>  >  and reenabled the tracing GC, next up is the automatic deadlock
>  >  detection/breaking.
>  >
>  >  As for merging back into CPython, I could build smaller patches, but
>  >  the design can't be completely separated.  For example, __finalize__
>  >  is called from another thread, so Monitor's @monitormethod should be
>  >  applied.  I don't specifically require Monitor, just that the object
>  >  (and therefor its methods) be shareable, and Monitor is the easiest
>  >  way to provide that.
>
> Thanks! Would you care to give us a hint on how a typical
>  multi-threaded application would be written using this approach? How
>  much pre-existing code would break do you expect?

Since I forgot it in my original post, here's my project site:

http://code.google.com/p/python-safethread/

A key advantage of using Monitors, rather than actors or some other
event-driven scheme, is that you retain the traditional style of
blocking function calls.  Most stdlib modules should remain basically
the same.

The first conflict will be in importing.  To be accessible to another
thread a module object must be shareable, which means everything it
references must also be shareable.  This is enabled on a per-module
basis using "from __future__ import shared_module".  It shouldn't
affect users of that module though, unless they modify its globals or
class attributes, so I expect we can apply it to most of the stdlib.

Module globals and class dicts use a shareddict, which is still
mutable, but requires its keys and values to be shareable.  Once you
stop modifying it it will switch to an unlocked mode, allowing
uncontended reads.  Writes at this point still work, but the first one
will be expensive, so such behaviour should be discouraged.

The bigger problem is having something like a list in the module
globals or class dict.  list isn't thread-safe and isn't shareable, so
it will be rejected.  If you're just using it as a constant you can
probably replace with a tuple (or frozenset?), but if you are
modifying it you'll need to wrap it with a Monitor or the like.

Another big problem is that I've scrapped the existing
thread/threading modules.  Getting their semantics right would require
I retain the GIL (at least for the main MonitorSpace), they wouldn't
get deadlock detection, I wouldn't support daemon threads, etc.  I can
do it, but only grudgingly. ;)

*****

Now, a simple example of how to spawn threads is given here:
http://code.google.com/p/python-safethread/wiki/Branching

    with branch() as children:
        children.add(func1, 42, name='bob')
        children.add(func2, *args, **kwargs)
        some_io_func()

Basically you use "with branch() as children:" to create a branching
point, then "children.add(func, *args, **kwargs)" to create a child
thread.  It automatically joins the threads when you try to leave the
context.  If one raises an exception, all others (including the base
thread) are cancelled, encouraging them to stop.  Once they have all
stopped the exceptions are bundled together (using
PyException_SetCause() and possibly MultipleError), then propagated up
to their caller.

If you want to collect their results you can use
"children.addresult(func)" instead, then follow with "data =
children.getresults()" after you leave the context.  This must be done
explicitly to avoid unintentionally keeping results alive in a
long-running server.

If you're operating only on immutable data and returning an immutable
result then that's sufficient.  However, to build a shared mutable
object you need to turn to Monitors:
http://code.google.com/p/python-safethread/wiki/Monitors

class Counter(Monitor):
    # implicit @monitormethod for __init__ (and __new__)
    def __init__(self):
        self.count = 0

    @monitormethod
    def tick(self):
        self.count += 1

    @monitormethod
    def value(self):
        return self.count

The basic idea here is that it acquires the Monitor's lock when a
monitormethod is called.  What you don't see in this example is that
it checks if all the arguments are shareable too, as well as the
return value.  You can still write staticmethods or classmethods -
only self.__dict__ is inaccessible if you're not in the Monitor.

Also not seen is a .wait(func) (to leave the Monitor), the
.enter(func) used internally by monitormethod, or other options to
give explicit control over recursive-locking situations.  Much of that
hasn't been implemented and still needs a final design.  Likewise, I
haven't added conditions yet.

-- 
Adam Olsen, aka Rhamphoryncus

From tjreedy at udel.edu  Mon Mar 17 23:37:05 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 17 Mar 2008 18:37:05 -0400
Subject: [Python-3000] Using *a for packing in lists and other places
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com><frhgpf$k84$1@ger.gmane.org><9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com><frk6g8$dpt$1@ger.gmane.org>
	<1205751413.13377.11.camel@qrnik>
Message-ID: <frmrqf$9bl$1@ger.gmane.org>


"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message 
news:1205751413.13377.11.camel at qrnik...
| Dnia 16-03-2008, N o godzinie 18:20 -0400, Terry Reedy pisze:
|
| > The rule I suggested is 'execute the statement the same *as if*  the
| > iterable items had been written in the code as a comma sequence'.
|
| One reason I don't like this rule is that it works on the level of the
| token sequence

The tokenization of Python code is part of the language spec

| rather than the AST.

Whereas no particular AST is, that I know of.

| It's too low-level, relying on
| peculiarities of the syntax rather than the meaning (does a=*b really
| convert b to a tuple only because the tuple syntax uses lone commas?).
| And it doesn't directly work for 0 or 1 items, in which case the
| behavior must be extrapolated from the behavior for more items.

Can you give another rule that you prefer and that I can comprehend and 
that I can explain to Python newcomers?  The OP only gave a few examples of 
* usage and (initially) no rule that I saw.







From guido at python.org  Tue Mar 18 01:30:20 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 17 Mar 2008 19:30:20 -0500
Subject: [Python-3000] 3rd party developers: don't change your APIs when
	porting to Py3k!
Message-ID: <ca471dc20803171730p569580f4x12c0bd1ac967d46f@mail.gmail.com>

For those who don't read blogs, I just blogged the slides for my
keynote, and added an important admonishment to 3rd party developers.
Here's the full text of the blog:

The slides of my `keynote`_ are now up on python.org.  There's both a
`PowerPoint`_ and a `PDF`_ file.

.. _keynote: http://www.python.org/doc/essays/ppt/
.. _PowerPoint: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.ppt
.. _PDF: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.pdf

I'd like to take this opportunity to remind you of a really important
issue that I neglected to mention in the talk: **Don't change your
APIs incompatibly when porting to Py3k.**

Yes, you heard that right: even though Python 3.0 is changing
incompatibly, I implore you (especially if you're maintaining a
library that's used by others) *not* to make incompatible changes to
your API.  If you *have* make API changes, do them *before* you port
to 3.0 -- release a version with the new API for Python 2.5, or 2.6 if
you must.  (Or do it later, *after* you've released a port to 3.0
without adding new features.)

Why?  Think of your users.  Suppose Ima Lumberjack has implemented a
web 2.0 app for managing his sawmill.  Ima is a happy user of your
most excellent web 2.0 framework.  Now Ima wants to upgrade his app to
Py3k.  He waits until you have ported your framework to Py3k.  He does
everything by the books, runs his source code through the 2to3 tool,
and starts testing.  Imagine his despair when the tests fail: how is
he going to tell whether the breakage is due to your API changes or
due to his own code not being Py3k-ready?

On the other hand, if port your web 2.0 framework to Py3k *without*
making API changes, Ima's task is much more focused: the bugs he is
left with after running 2to3 are definitely in his own code, which
(presumably :-) he knows how to debug and fix.

The same recommendation applies even more strongly if your library is
a dependency for other libraries -- due to the fan-out the pain caused
to others multiplies.  If one of those packages gives up (even
temporarily) its Py3k porting effort, this may prevent many other
libraries and apps from being ported at all!

So, once more for emphasis: **Don't change your APIs at the same time
as porting to Py3k!**

*PS.* The 3.0final release is now scheduled for September 3, 2008.
See `PEP 361`_.

.. _PEP 361: http://python.org/dev/peps/pep-0361/

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Tue Mar 18 01:49:43 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 17 Mar 2008 19:49:43 -0500
Subject: [Python-3000] PEP 361: Python 2.6/3.0 release schedule
Message-ID: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>

Greetings from Pycon 2008!

Neal Norwitz and I have worked out the schedule for Python 2.6 and  
3.0, which will be released in lockstep.  We will be following a  
monthly release schedule, with releases to occur on the first  
Wednesday of the month.  We'll move to a 2 week schedule for the  
release candidates.

Executive summary: Python 2.6 and 3.0 finals are planned for September  
3, 2008.

PEP 361 contains all the gory details; from the PEP:

         Feb 29 2008: Python 2.6a1 and 3.0a3 are released
         Apr 02 2008: Python 2.6a2 and 3.0a4 planned
         May 07 2008: Python 2.6a3 and 3.0a5 planned
         Jun 04 2008: Python 2.6b1 and 3.0b1 planned
         Jul 02 2008: Python 2.6b2 and 3.0b2 planned
         Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned
         Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned
         Sep 03 2008: Python 2.6 and 3.0 final

http://www.python.org/dev/peps/pep-0361/

This schedule gives everybody plenty of advanced notice, so you should  
be able to get  your code in on time.  Please be very careful about  
not breaking the branches.  Neal and I will be cracking the whip of  
public shame when your commit turns the buildbots red.  Embarrassing  
Pycon pictures of you will be posted if such broken revisions cause us  
to slip a release, and remember, we know how to use GIMP.

On behalf of everyone, here's to an awesome release!

-Barry
Python 2.6/3.0 release manager

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pep-0361.txt
Url: http://mail.python.org/pipermail/python-3000/attachments/20080317/c34e843c/attachment-0001.txt 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20080317/c34e843c/attachment-0001.pgp 

From janssen at parc.com  Tue Mar 18 02:41:22 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 17 Mar 2008 18:41:22 PDT
Subject: [Python-3000] [Python-Dev] 3rd party developers: don't change
	your APIs when porting to Py3k!
In-Reply-To: <ca471dc20803171730p569580f4x12c0bd1ac967d46f@mail.gmail.com> 
References: <ca471dc20803171730p569580f4x12c0bd1ac967d46f@mail.gmail.com>
Message-ID: <08Mar17.184131pdt."58696"@synergy1.parc.xerox.com>

Now I apparently need an email reader that understands reStructuredText :-).

Bill

From zooko at zooko.com  Tue Mar 18 02:40:25 2008
From: zooko at zooko.com (zooko)
Date: Mon, 17 Mar 2008 19:40:25 -0600
Subject: [Python-3000] [Python-Dev] 3rd party developers: don't change
	your APIs when porting to Py3k! (but consider using ctypes)
In-Reply-To: <ca471dc20803171730p569580f4x12c0bd1ac967d46f@mail.gmail.com>
References: <ca471dc20803171730p569580f4x12c0bd1ac967d46f@mail.gmail.com>
Message-ID: <CCBB6D55-E435-4993-BE6C-7A4450641111@zooko.com>

I'm the maintainer of a few Python packages which wrap native C or C+ 
+ code.

At Pycon, I learned that PyPy and Jython support ctypes or have plans  
to do so in the near future.  I don't know about IronPython.

However, having CPython, PyPy, and Jython all supporting ctypes makes  
it the obvious choice for interfacing to native code in the future.

Regards,

Zooko O'Whielacronx

From oliphant.travis at ieee.org  Tue Mar 18 08:04:41 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Tue, 18 Mar 2008 02:04:41 -0500
Subject: [Python-3000] PEP 361: Python 2.6/3.0 release schedule
In-Reply-To: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
Message-ID: <47DF6989.1010808@ieee.org>

Barry Warsaw wrote:
> Greetings from Pycon 2008!
> 
> Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0, 
> which will be released in lockstep.  We will be following a monthly 
> release schedule, with releases to occur on the first Wednesday of the 
> month.  We'll move to a 2 week schedule for the release candidates.
> 

Hey Barry,

Thanks for putting this PEP together.  This is really helpful.

I didn't see discussion of PEP 3118 and it's features back-ported to 
Python 2.6.  I've already back-ported the new buffer API as an addition 
to the old buffer protocol.

In addition, I've planned to back-port the improvements to the struct 
module and the addition of the memoryview object (both in PEP 3118).

If you have questions, we can talk tomorrow.

Best regards,

-Travis Oliphant


From p.f.moore at gmail.com  Tue Mar 18 11:14:11 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 18 Mar 2008 10:14:11 +0000
Subject: [Python-3000] A question about Py3K migration
Message-ID: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>

This is something that I've been pondering over for a while now, but I
haven't been able to come to any strong conclusions. I'd appreciate
some comment, and possibly a bit of clarification in the documentation
for migrating to 3.0.

I'm basically an end user of Python. I don't write libraries or
frameworks, but I do depend on a number of 3rd party libraries. As a
Windows user, I'm probably more dependent on binary installers than
the average Unix/MacOS user.

As far as my own code is concerned, I am able to follow the standard
migration path (move to 2.6, fix issues in 3.0-warning mode, use 2to3
and test, repeat as needed). As my code is generally not complex, I
don't expect this to be a particularly lengthy process. But I'm going
to be stuck until 3.0-compatible installers are available for the
extensions I use. And that's even true for pure-Python packages, as
they will need to do the 2to3 dance as well.

So there's a bottleneck in 3.0 adoption, with end users not being able
to move to 3.0 until package maintainers have done their bit. In the
long run, this will happen, but it could slow down adoption of 3.0. I
see this already - as 99.9% of my code depends on either pywin32 or
cx_Oracle, and with neither having 3.0 compatible binaries yet, I
can't make any practical use of the 3.0 alphas.

As I said at the start, I don't have any good answers. But would it be
worth maintaining something like a wiki page of key libraries and
their expectations for moving to 3.0? It might at least make people
aware of reasonable timescales, and set some expectations for chronic
early adopters like me :-)

Paul.

From ncoghlan at gmail.com  Tue Mar 18 11:32:50 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 18 Mar 2008 20:32:50 +1000
Subject: [Python-3000] A question about Py3K migration
In-Reply-To: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>
References: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>
Message-ID: <47DF9A52.5080507@gmail.com>

Paul Moore wrote:
> As I said at the start, I don't have any good answers. But would it be
> worth maintaining something like a wiki page of key libraries and
> their expectations for moving to 3.0? It might at least make people
> aware of reasonable timescales, and set some expectations for chronic
> early adopters like me :-)

My personal expectation is that 3.0 will serve mainly to provide the 
developers of those 3rd-party frameworks and libraries with a solid 
target to aim for, and that the more likely adoption point for end-user 
production usage would be around the 3.1 timeframe. I might be 
pleasantly surprised by the actual rate of adoption, but I wouldn't put 
any money on that prospect ;)

Even with 2.x releases it usually takes a few months after the 
python.org release for all the 3rd parties to get their binary 
installers up to date and released (some of the bigger projects that 
have the resources to closely track the alpha/beta releases may get 
something out quickly, but I'm other projects will wait for at least the 
release candidates before looking at what needs to be done)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From qrczak at knm.org.pl  Tue Mar 18 13:39:28 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 18 Mar 2008 13:39:28 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
Message-ID: <1205843968.23745.9.camel@qrnik>

Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:

> I've replaced __del__ API (which resurrected objects) with a
> __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
> in __finalizeattrs__ are proxied into a core object, a finalizer
> thread is given a reference to the core, and when the main object is
> deleted the GC asynchronously notifies the finalizer thread so that it
> can call core.__finalize__().  The net result is an API very similar
> to __del__ (you need to list attributes it might use), but it's now
> impossible for the GC to run arbitrary code (I even enforce this).

Ah! Irrespective of other issues, I like this very much. This design
agrees with my understanding of how finalization should behave, except
that I haven't had details in mind which would fit Python. My abstract
design needs the finalization function to somehow access parts of the
dying object, but not the object itself, and this design shows how to
actually do it in a convenient way.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From martin at v.loewis.de  Tue Mar 18 14:51:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 18 Mar 2008 08:51:30 -0500
Subject: [Python-3000] A question about Py3K migration
In-Reply-To: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>
References: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>
Message-ID: <47DFC8E2.2080009@v.loewis.de>

> This is something that I've been pondering over for a while now, but I
> haven't been able to come to any strong conclusions. I'd appreciate
> some comment, and possibly a bit of clarification in the documentation
> for migrating to 3.0.

As Nick says: Don't worry at all about migrating to 3.0. It's very 
reasonable to not even start thinking about Python 3 before 3.2 is
released, which may happen in 2010.

Regards,
Martin


From p.f.moore at gmail.com  Tue Mar 18 15:12:18 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 18 Mar 2008 14:12:18 +0000
Subject: [Python-3000] A question about Py3K migration
In-Reply-To: <47DFC8E2.2080009@v.loewis.de>
References: <79990c6b0803180314j655affaauc158e0aa142ccbab@mail.gmail.com>
	<47DFC8E2.2080009@v.loewis.de>
Message-ID: <79990c6b0803180712j1b8a750alfb15627a08bb6ef9@mail.gmail.com>

On 18/03/2008, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > This is something that I've been pondering over for a while now, but I
> > haven't been able to come to any strong conclusions. I'd appreciate
> > some comment, and possibly a bit of clarification in the documentation
> > for migrating to 3.0.
>
> As Nick says: Don't worry at all about migrating to 3.0. It's very
> reasonable to not even start thinking about Python 3 before 3.2 is
> released, which may happen in 2010.

OK, that's a fair comment. It might be worth stating this
recommendation somewhere. There's a risk of discouraging people from
moving past 2.6 by doing this, but on the other hand it stops people
leaping in too soon and finding that "it's broken". (It's not, of
course, but that's how it may get publicised).

Paul

From barry at python.org  Tue Mar 18 15:47:51 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 18 Mar 2008 09:47:51 -0500
Subject: [Python-3000] PEP 361: Python 2.6/3.0 release schedule
In-Reply-To: <47DF6989.1010808@ieee.org>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
	<47DF6989.1010808@ieee.org>
Message-ID: <5F2A88CA-5C89-49C6-9226-B989C46D9D04@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>
> Hey Barry,
>
> Thanks for putting this PEP together.  This is really helpful.

Hi Travis... thanks!

> I didn't see discussion of PEP 3118 and it's features back-ported to
> Python 2.6.  I've already back-ported the new buffer API as an  
> addition
> to the old buffer protocol.
>
> In addition, I've planned to back-port the improvements to the struct
> module and the addition of the memoryview object (both in PEP 3118).
>
> If you have questions, we can talk tomorrow.

Let's do that.  Neal has put together a list of things that he thinks  
needs to be backported.  We should formalize that list (as best we can  
given we're still in alpha), and add it to the PEP.  I think we should  
also make sure we have open issues in the tracker for each backporting  
task.

Neal and I talked about this yesterday too and came up with some  
general guidelines. The view we have is that through conservative use  
of future imports and backports, we want to start closing the gap  
between 2.6 and 3.0.  It'll still be fairly wide though, so we'll use  
2.7/3.1 to close it even further by doing things like backporting more  
stuff, de-futurizing features in 2.6, etc.  It may be that we should  
take a very conservative approach to new features in the next few  
major release (in both families), concentrating instead on stabilizing  
what we've got and helping make the transition less and less painful.   
So you could imagine that 2.8/3.2 would close the gap far enough that  
it wouldn't be much more work to move from 2.8 to 3.2 than it would be  
to move from 2.5 to 2.6.

Some other thoughts: we might want to shorten our post 2.6/3.0 release  
cycles, say to 1 year or less so that we can help speed this  
transition.  If we try hard to keep new features to a minimum, this  
might be possible, but we also have to avoid churn.  Quite a few  
people expressed to me that it might be 5 years before they switch  
fully to 3.0.  That seems fine to me, given that some big Python shops  
are still on 2.2 or <gasp> 1.5 and 1.6.  So 3 years from 2.6/3.0 to  
2.8/3.2 doesn't seem to wildly outrageous to me.

Given this longer view of the transition, we can be more conservative  
about what we backport to 2.6.  A general principle would be anything  
that is brand new syntax in 3.0 can be backported, because there won't  
be any existing code in 2.6 that could break.  Anything that can be  
enabled through a future-import might be a candidate, but you have to  
be careful about tricky semantic differences.  For example, changing  
the meaning of dict.keys() via a future-import is not a good idea.

One thing I would like to see is "from __future__ import  
unicode_strings" or some such.  The only thing this would do is allow  
you to write unicode string literals in Python 2.6 without the u''  
prefix.  That's a fairly localized change (affecting just the file the  
literals appear in), but it would go a long way toward closing that gap.

One question that came up was whether we have enough bitfields to  
handle all the future statements we might have, and whether you even  
want to see Python 2.6 code sprinkled with lots of future statements.   
Does it make sense to have a "from __future__ import python3"  
umbrella?  Will we really have that many future statements?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR9/WGHEjvBPtnXfVAQLP1AP+OpSuXHDgE1uxifKA6FEKxS1Zms1Pe0ww
OimG2kw3afzL5+o1mdrRBUDy/rETpNhlxBTgx+fgI7VJc+Vs+uBi0sQwemCqOZ1I
9qlBFCo8YrmXlCZTdL9E0nEpiBSuanLKJcdNP8VU3QjbOX0EKqNTfK1asSckxvgT
H1o5wGqnX5M=
=wiJQ
-----END PGP SIGNATURE-----

From steven.bethard at gmail.com  Tue Mar 18 16:21:22 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 18 Mar 2008 09:21:22 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <1205843968.23745.9.camel@qrnik>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
Message-ID: <d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>

On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>
>  > I've replaced __del__ API (which resurrected objects) with a
>  > __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>  > in __finalizeattrs__ are proxied into a core object, a finalizer
>  > thread is given a reference to the core, and when the main object is
>  > deleted the GC asynchronously notifies the finalizer thread so that it
>  > can call core.__finalize__().  The net result is an API very similar
>  > to __del__ (you need to list attributes it might use), but it's now
>  > impossible for the GC to run arbitrary code (I even enforce this).
>
>  Ah! Irrespective of other issues, I like this very much. This design
>  agrees with my understanding of how finalization should behave, except
>  that I haven't had details in mind which would fit Python. My abstract
>  design needs the finalization function to somehow access parts of the
>  dying object, but not the object itself, and this design shows how to
>  actually do it in a convenient way.

Note that you can use something very much like this right now::

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From martin at v.loewis.de  Tue Mar 18 16:23:41 2008
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 18 Mar 2008 10:23:41 -0500
Subject: [Python-3000] from .foo import *
Message-ID: <47DFDE7D.407@v.loewis.de>

When I do a relative star import, I current get

SyntaxError: 'import *' not allowed with 'from .'

What's the reason for this restriction?

Is it ok to remove it?

I encountered the issue while porting Django. In
django/newforms/__init__.py, they do

from widgets import *
from fields import *
from forms import *
from models import *

In 3k, that needs to change to

from .widgets import *
from .fields import *
from .forms import *
from .models import *

but that still won't work because of the syntax
error. One solution would be to make the import
explicit, but that is tedious and unmaintainable.
E.g. for the widgets line, it would be

from .widgets import (Widget, TextInput, PasswordInput,
     HiddenInput, MultipleHiddenInput,
     FileInput, DateTimeInput, Textarea, CheckboxInput,
     Select, NullBooleanSelect, SelectMultiple, RadioSelect,
     CheckboxSelectMultiple, MultiWidget, SplitDateTimeWidget)

Regards,
Martin

From guido at python.org  Tue Mar 18 16:32:33 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 18 Mar 2008 10:32:33 -0500
Subject: [Python-3000] from .foo import *
In-Reply-To: <47DFDE7D.407@v.loewis.de>
References: <47DFDE7D.407@v.loewis.de>
Message-ID: <ca471dc20803180832g76e0830fo31562897d16206f6@mail.gmail.com>

I don't recall the reason; it may simply be due to the complexity, or
possibly it would have made the _import__ API even uglier.

I'm fine with removing the restriction; your use case is compelling.

On Tue, Mar 18, 2008 at 10:23 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> When I do a relative star import, I current get
>
>  SyntaxError: 'import *' not allowed with 'from .'
>
>  What's the reason for this restriction?
>
>  Is it ok to remove it?
>
>  I encountered the issue while porting Django. In
>  django/newforms/__init__.py, they do
>
>  from widgets import *
>  from fields import *
>  from forms import *
>  from models import *
>
>  In 3k, that needs to change to
>
>  from .widgets import *
>  from .fields import *
>  from .forms import *
>  from .models import *
>
>  but that still won't work because of the syntax
>  error. One solution would be to make the import
>  explicit, but that is tedious and unmaintainable.
>  E.g. for the widgets line, it would be
>
>  from .widgets import (Widget, TextInput, PasswordInput,
>      HiddenInput, MultipleHiddenInput,
>      FileInput, DateTimeInput, Textarea, CheckboxInput,
>      Select, NullBooleanSelect, SelectMultiple, RadioSelect,
>      CheckboxSelectMultiple, MultiWidget, SplitDateTimeWidget)
>
>  Regards,
>  Martin
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From thomas at python.org  Tue Mar 18 16:38:08 2008
From: thomas at python.org (Thomas Wouters)
Date: Tue, 18 Mar 2008 08:38:08 -0700
Subject: [Python-3000] from .foo import *
In-Reply-To: <ca471dc20803180832g76e0830fo31562897d16206f6@mail.gmail.com>
References: <47DFDE7D.407@v.loewis.de>
	<ca471dc20803180832g76e0830fo31562897d16206f6@mail.gmail.com>
Message-ID: <9e804ac0803180838q4f7040d9x8f6c33b7a11f7f1d@mail.gmail.com>

On Tue, Mar 18, 2008 at 8:32 AM, Guido van Rossum <guido at python.org> wrote:

> I don't recall the reason; it may simply be due to the complexity, or
> possibly it would have made the _import__ API even uglier.
>

I don't recall any such issues, and I can't imagine them now. The '.' is
resolved before the fromlist is even considered, and is just a way to find
the right package to import from. Importing '*' instead of a set of names
should not be a problem.


>
> I'm fine with removing the restriction; your use case is compelling.
>
> On Tue, Mar 18, 2008 at 10:23 AM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> > When I do a relative star import, I current get
> >
> >  SyntaxError: 'import *' not allowed with 'from .'
> >
> >  What's the reason for this restriction?
> >
> >  Is it ok to remove it?
> >
> >  I encountered the issue while porting Django. In
> >  django/newforms/__init__.py, they do
> >
> >  from widgets import *
> >  from fields import *
> >  from forms import *
> >  from models import *
> >
> >  In 3k, that needs to change to
> >
> >  from .widgets import *
> >  from .fields import *
> >  from .forms import *
> >  from .models import *
> >
> >  but that still won't work because of the syntax
> >  error. One solution would be to make the import
> >  explicit, but that is tedious and unmaintainable.
> >  E.g. for the widgets line, it would be
> >
> >  from .widgets import (Widget, TextInput, PasswordInput,
> >      HiddenInput, MultipleHiddenInput,
> >      FileInput, DateTimeInput, Textarea, CheckboxInput,
> >      Select, NullBooleanSelect, SelectMultiple, RadioSelect,
> >      CheckboxSelectMultiple, MultiWidget, SplitDateTimeWidget)
> >
> >  Regards,
> >  Martin
> >  _______________________________________________
> >  Python-3000 mailing list
> >  Python-3000 at python.org
> >  http://mail.python.org/mailman/listinfo/python-3000
> >  Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/thomas%40python.org
>



-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080318/ecd16f8d/attachment-0001.htm 

From aahz at pythoncraft.com  Tue Mar 18 16:49:45 2008
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 18 Mar 2008 08:49:45 -0700
Subject: [Python-3000] from .foo import *
In-Reply-To: <47DFDE7D.407@v.loewis.de>
References: <47DFDE7D.407@v.loewis.de>
Message-ID: <20080318154945.GA9803@panix.com>

On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
>
> When I do a relative star import, I current get
> 
> SyntaxError: 'import *' not allowed with 'from .'
> 
> What's the reason for this restriction?

It was the first step in removing the ability to use "from *" at all.  I
don't have time right now to find the discussion, but I can do that later
if you want.

> Is it ok to remove it?

As always, that's up to Guido.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

From rhamph at gmail.com  Tue Mar 18 16:55:16 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 09:55:16 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
Message-ID: <aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>

On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>  <qrczak at knm.org.pl> wrote:
>  > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>  >
>  >  > I've replaced __del__ API (which resurrected objects) with a
>  >  > __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>  >  > in __finalizeattrs__ are proxied into a core object, a finalizer
>  >  > thread is given a reference to the core, and when the main object is
>  >  > deleted the GC asynchronously notifies the finalizer thread so that it
>  >  > can call core.__finalize__().  The net result is an API very similar
>  >  > to __del__ (you need to list attributes it might use), but it's now
>  >  > impossible for the GC to run arbitrary code (I even enforce this).
>  >
>  >  Ah! Irrespective of other issues, I like this very much. This design
>  >  agrees with my understanding of how finalization should behave, except
>  >  that I haven't had details in mind which would fit Python. My abstract
>  >  design needs the finalization function to somehow access parts of the
>  >  dying object, but not the object itself, and this design shows how to
>  >  actually do it in a convenient way.
>
>  Note that you can use something very much like this right now::
>
>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635

Yeah.  That's missing the finalizer thread, but that could be add.

Note, you need to use a finalizer thread in order to use locks to
protect your datastructures.  Without it, if you simply preempt the
current thread like is done today, you can only do operations the
memory model provides as atomic.

-- 
Adam Olsen, aka Rhamphoryncus

From theller at ctypes.org  Tue Mar 18 17:15:03 2008
From: theller at ctypes.org (Thomas Heller)
Date: Tue, 18 Mar 2008 17:15:03 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>	<1205843968.23745.9.camel@qrnik>	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
Message-ID: <fropq7$h45$1@ger.gmane.org>

Adam Olsen schrieb:
> On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>>  <qrczak at knm.org.pl> wrote:
>>  > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>>  >
>>  >  > I've replaced __del__ API (which resurrected objects) with a
>>  >  > __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>>  >  > in __finalizeattrs__ are proxied into a core object, a finalizer
>>  >  > thread is given a reference to the core, and when the main object is
>>  >  > deleted the GC asynchronously notifies the finalizer thread so that it
>>  >  > can call core.__finalize__().  The net result is an API very similar
>>  >  > to __del__ (you need to list attributes it might use), but it's now
>>  >  > impossible for the GC to run arbitrary code (I even enforce this).
>>  >
>>  >  Ah! Irrespective of other issues, I like this very much. This design
>>  >  agrees with my understanding of how finalization should behave, except
>>  >  that I haven't had details in mind which would fit Python. My abstract
>>  >  design needs the finalization function to somehow access parts of the
>>  >  dying object, but not the object itself, and this design shows how to
>>  >  actually do it in a convenient way.
>>
>>  Note that you can use something very much like this right now::
>>
>>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635
> 
> Yeah.  That's missing the finalizer thread, but that could be add.
> 
> Note, you need to use a finalizer thread in order to use locks to
> protect your datastructures.  Without it, if you simply preempt the
> current thread like is done today, you can only do operations the
> memory model provides as atomic.
> 

Hm, I could imagine objects that need to be finalized in the thread that created them.
How could that be handled?

Thomas


From theller at ctypes.org  Tue Mar 18 17:17:54 2008
From: theller at ctypes.org (Thomas Heller)
Date: Tue, 18 Mar 2008 17:17:54 +0100
Subject: [Python-3000] PEP 361: Python 2.6/3.0 release   schedule
In-Reply-To: <5F2A88CA-5C89-49C6-9226-B989C46D9D04@python.org>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>	<47DF6989.1010808@ieee.org>
	<5F2A88CA-5C89-49C6-9226-B989C46D9D04@python.org>
Message-ID: <fropvi$h45$2@ger.gmane.org>

Barry Warsaw schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>>
>> Hey Barry,
>>
>> Thanks for putting this PEP together.  This is really helpful.
> 
> Hi Travis... thanks!
> 
>> I didn't see discussion of PEP 3118 and it's features back-ported to
>> Python 2.6.  I've already back-ported the new buffer API as an  
>> addition
>> to the old buffer protocol.
>>
>> In addition, I've planned to back-port the improvements to the struct
>> module and the addition of the memoryview object (both in PEP 3118).
>>
>> If you have questions, we can talk tomorrow.
> 
> Let's do that.  Neal has put together a list of things that he thinks  
> needs to be backported.  We should formalize that list (as best we can  
> given we're still in alpha), and add it to the PEP.  I think we should  
> also make sure we have open issues in the tracker for each backporting  
> task.
> 

I think that
  [issue1971] ctypes exposing the pep 3118 buffer interface
should / could also be backported to 2.6 (once it is merged into py3k).

Thomas


From douglas at openplans.org  Tue Mar 18 17:35:36 2008
From: douglas at openplans.org (Douglas Mayle)
Date: Tue, 18 Mar 2008 12:35:36 -0400
Subject: [Python-3000] [Python-Dev] PEP 361: Python 2.6/3.0 release
	schedule
In-Reply-To: <3283f7fe0803180917o459f52d5x32691b1d6d87a8ef@mail.gmail.com>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
	<3283f7fe0803180917o459f52d5x32691b1d6d87a8ef@mail.gmail.com>
Message-ID: <F921B572-750C-4C94-88E9-5C78552545E0@openplans.org>

I keep forgetting to reply to the list:

This is great news.  I was getting ready to submit a patch to fix the  
Unicode handling in simplejson (which I will probably do anyway), but  
I'm interested in making sure whichever lib will hit the standard  
library has a correct implementation.

Doug

On Mar 18, 2008, at 12:17 PM, John Millikin wrote:

>> Possible features for 2.6
>>    New modules in the standard library:
>>        - JSON implementation
>>
> Have there been any plans made for which one? All of the
> implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
> python-json) have serious issues that in my opinion should be fixed
> before inclusion in the standard library[1]. I am the author of
> jsonlib, and am willing to write patches for whichever implementation
> becomes the standard, but it would be very nice to know what to focus
> on.
>
> Apologies if this has been discussed already, but there was no link to
> a PEP in 361 and a search of python-dev and c.l.p returned no relevant
> results.
>
>
> [1]
> * cjson and python-json have almost complete absense of Unicode  
> support.
> * simplejson is slow and writes incorrect unicode escapes.
> * demjson is far too forgiving when parsing and accepts all sorts of
> invalid input.
> * jsonlib is not PEP 8-compliant and has terrible error handling.
> * python-json is abandoned, slow, and lacks Unicode support.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/douglas%40openplans.org
>
> !DSPAM:4037,47dfeb7b286095409313003!
>


From nnorwitz at gmail.com  Tue Mar 18 17:43:25 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 18 Mar 2008 11:43:25 -0500
Subject: [Python-3000] adding json to stdlib (was: Re: [Python-Dev] PEP 361:
	Python 2.6/3.0 release schedule)
Message-ID: <ee2a432c0803180943t7e1589b6ye87d5523f51dcd27@mail.gmail.com>

On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <jmillikin at gmail.com> wrote:
> > Possible features for 2.6
>  >     New modules in the standard library:
>  >         - JSON implementation
>  >
>  Have there been any plans made for which one? All of the

No.  This was something I added as a nice to have for 2.6.

>  implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
>  python-json) have serious issues that in my opinion should be fixed
>  before inclusion in the standard library[1]. I am the author of
>  jsonlib, and am willing to write patches for whichever implementation
>  becomes the standard, but it would be very nice to know what to focus
>  on.

I'm not familiar enough with any of the libraries to comment.  If it's
premature to add a particular implementation, that's fine, we can
wait.

>  Apologies if this has been discussed already, but there was no link to
>  a PEP in 361 and a search of python-dev and c.l.p returned no relevant
>  results.

I don't believe it has been discussed before.  I've changed the
subject and would like to discuss this now.

It would be great if you could pull together and get the community
behind a single solution that is robust enough to include in the
stdlib.  If that an be finished for 2.6, great.  If it waits for 2.7,
that would still be fine.

n

>
>  [1]
>  * cjson and python-json have almost complete absense of Unicode support.
>  * simplejson is slow and writes incorrect unicode escapes.
>  * demjson is far too forgiving when parsing and accepts all sorts of
>  invalid input.
>  * jsonlib is not PEP 8-compliant and has terrible error handling.
>  * python-json is abandoned, slow, and lacks Unicode support.
>
>
> _______________________________________________
>  Python-Dev mailing list
>  Python-Dev at python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>

From martin at v.loewis.de  Tue Mar 18 17:55:46 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 18 Mar 2008 11:55:46 -0500
Subject: [Python-3000] from .foo import *
In-Reply-To: <20080318154945.GA9803@panix.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
Message-ID: <47DFF412.4030607@v.loewis.de>

> It was the first step in removing the ability to use "from *" at all.  I
> don't have time right now to find the discussion, but I can do that later
> if you want.

Thanks - that's what I expected; no need to dig out further details.

Regards,
Martin

From musiccomposition at gmail.com  Tue Mar 18 17:59:54 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 18 Mar 2008 11:59:54 -0500
Subject: [Python-3000] from .foo import *
In-Reply-To: <20080318154945.GA9803@panix.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
Message-ID: <1afaf6160803180959h35e186bdr327acb48ee8bb714@mail.gmail.com>

On Tue, Mar 18, 2008 at 10:49 AM, Aahz <aahz at pythoncraft.com> wrote:

> On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
> >
> > When I do a relative star import, I current get
> >
> > SyntaxError: 'import *' not allowed with 'from .'
> >
> > What's the reason for this restriction?
>
> It was the first step in removing the ability to use "from *" at all.  I
> don't have time right now to find the discussion, but I can do that later
> if you want.

I suppose issue 2400 should be closed, then.

>
>
> > Is it ok to remove it?
>
> As always, that's up to Guido.
> --
> Aahz (aahz at pythoncraft.com)           <*>
> http://www.pythoncraft.com/
>
> "It is easier to optimize correct code than to correct optimized code."
> --Bill Harlan
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080318/34a96e38/attachment.htm 

From nnorwitz at gmail.com  Tue Mar 18 18:21:54 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 18 Mar 2008 12:21:54 -0500
Subject: [Python-3000] from .foo import *
In-Reply-To: <1afaf6160803180959h35e186bdr327acb48ee8bb714@mail.gmail.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
	<1afaf6160803180959h35e186bdr327acb48ee8bb714@mail.gmail.com>
Message-ID: <ee2a432c0803181021g1deb970bs2e5ed460c809bda0@mail.gmail.com>

On Tue, Mar 18, 2008 at 11:59 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
>
>
>
> On Tue, Mar 18, 2008 at 10:49 AM, Aahz <aahz at pythoncraft.com> wrote:
> >
> > On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
> > >
> > > When I do a relative star import, I current get
> > >
> > > SyntaxError: 'import *' not allowed with 'from .'
> > >
> > > What's the reason for this restriction?
> >
> > It was the first step in removing the ability to use "from *" at all.  I
> > don't have time right now to find the discussion, but I can do that later
> > if you want.
> I suppose issue 2400 should be closed, then.

The reason that 2400 was opened was to remove the restriction. :-)  If
I worded it wrong, feel free to add a comment to it.  The point of
adding the issue was that the SyntaxError should not be generated and
the import should do the right thing.

n

n

From rhamph at gmail.com  Tue Mar 18 18:24:21 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 11:24:21 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <fropq7$h45$1@ger.gmane.org>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
Message-ID: <aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>

On Tue, Mar 18, 2008 at 10:15 AM, Thomas Heller <theller at ctypes.org> wrote:
> Adam Olsen schrieb:
>
>
> > On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
>  > <steven.bethard at gmail.com> wrote:
>  >> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>  >>  <qrczak at knm.org.pl> wrote:
>  >>  > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>  >>  >
>  >>  >  > I've replaced __del__ API (which resurrected objects) with a
>  >>  >  > __finalize__/__finalizeattrs__ API (which doesn't).  Attributes listed
>  >>  >  > in __finalizeattrs__ are proxied into a core object, a finalizer
>  >>  >  > thread is given a reference to the core, and when the main object is
>  >>  >  > deleted the GC asynchronously notifies the finalizer thread so that it
>  >>  >  > can call core.__finalize__().  The net result is an API very similar
>  >>  >  > to __del__ (you need to list attributes it might use), but it's now
>  >>  >  > impossible for the GC to run arbitrary code (I even enforce this).
>  >>  >
>  >>  >  Ah! Irrespective of other issues, I like this very much. This design
>  >>  >  agrees with my understanding of how finalization should behave, except
>  >>  >  that I haven't had details in mind which would fit Python. My abstract
>  >>  >  design needs the finalization function to somehow access parts of the
>  >>  >  dying object, but not the object itself, and this design shows how to
>  >>  >  actually do it in a convenient way.
>  >>
>  >>  Note that you can use something very much like this right now::
>  >>
>  >>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635
>  >
>  > Yeah.  That's missing the finalizer thread, but that could be add.
>  >
>  > Note, you need to use a finalizer thread in order to use locks to
>  > protect your datastructures.  Without it, if you simply preempt the
>  > current thread like is done today, you can only do operations the
>  > memory model provides as atomic.
>  >
>
>  Hm, I could imagine objects that need to be finalized in the thread that created them.
>  How could that be handled?

If they need access to containing objects the only option is to use
the underlying tool, deathqueues.  WeakKeyDictionary and friends do
this.  This gives you notification that an object was deleted, but
without the core/__finalize__ machinery.

This can be wrapped up to give you back the core/__finalize__
machinery, but with you explicitly checking the deathqueue so you can
call __finalize__.

-- 
Adam Olsen, aka Rhamphoryncus

From musiccomposition at gmail.com  Tue Mar 18 18:47:47 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 18 Mar 2008 12:47:47 -0500
Subject: [Python-3000] from .foo import *
In-Reply-To: <ee2a432c0803181021g1deb970bs2e5ed460c809bda0@mail.gmail.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
	<1afaf6160803180959h35e186bdr327acb48ee8bb714@mail.gmail.com>
	<ee2a432c0803181021g1deb970bs2e5ed460c809bda0@mail.gmail.com>
Message-ID: <1afaf6160803181047o3201e1bq50f8594ab54518fc@mail.gmail.com>

On Tue, Mar 18, 2008 at 12:21 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:

> On Tue, Mar 18, 2008 at 11:59 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >
> >
> >
> > On Tue, Mar 18, 2008 at 10:49 AM, Aahz <aahz at pythoncraft.com> wrote:
> > >
> > > On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
> > > >
> > > > When I do a relative star import, I current get
> > > >
> > > > SyntaxError: 'import *' not allowed with 'from .'
> > > >
> > > > What's the reason for this restriction?
> > >
> > > It was the first step in removing the ability to use "from *" at all.
>  I
> > > don't have time right now to find the discussion, but I can do that
> later
> > > if you want.
> > I suppose issue 2400 should be closed, then.
>
> The reason that 2400 was opened was to remove the restriction. :-)  If
> I worded it wrong, feel free to add a comment to it.  The point of
> adding the issue was that the SyntaxError should not be generated and
> the import should do the right thing.

Okay. Sorry, I misread that.

>
>
> n
>
> n
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080318/4c4e015a/attachment.htm 

From qrczak at knm.org.pl  Tue Mar 18 20:13:26 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 18 Mar 2008 20:13:26 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
Message-ID: <1205867606.31138.11.camel@qrnik>

Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:

> If they need access to containing objects the only option is to use
> the underlying tool, deathqueues.

Deathqueues are a part of python-safethread, right?

Interesting, but just like the finalization design, the design with
weakrefs being added to deathqueues instead of using weakref callbacks
is exactly what I consider the right design of weakrefs (or actually
it's a superset of my design which does not include a blocking wait).

I see that you are implementing thread interrupts, which might be the
third thing that you are doing my way, and I am beginning to worry about
these coincidences. The interrupts seem to be unfinished in the patch
available to download, and the anonymous SVN is empty...

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From rhamph at gmail.com  Tue Mar 18 20:37:41 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 13:37:41 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <1205867606.31138.11.camel@qrnik>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
Message-ID: <aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>

On Tue, Mar 18, 2008 at 1:13 PM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
>
>
>  > If they need access to containing objects the only option is to use
>  > the underlying tool, deathqueues.
>
>  Deathqueues are a part of python-safethread, right?

Yup


>  Interesting, but just like the finalization design, the design with
>  weakrefs being added to deathqueues instead of using weakref callbacks
>  is exactly what I consider the right design of weakrefs (or actually
>  it's a superset of my design which does not include a blocking wait).

What sort of blocking wait do you use?  Or did you mean you don't have one?


>  I see that you are implementing thread interrupts, which might be the
>  third thing that you are doing my way, and I am beginning to worry about
>  these coincidences. The interrupts seem to be unfinished in the patch
>  available to download, and the anonymous SVN is empty...

The interrupt code is pretty rough and only implemented for a couple
cases.  If you look in test.test_sharedmodule, all the calls to
sharedmodule.readloop() use it.

All the interruption stuff will get renamed to "cancellation" at some
point, as well as getting fleshed out a little more.

-- 
Adam Olsen, aka Rhamphoryncus

From aahz at pythoncraft.com  Tue Mar 18 20:59:56 2008
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 18 Mar 2008 12:59:56 -0700
Subject: [Python-3000] from .foo import *
In-Reply-To: <1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
	<1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>
Message-ID: <20080318195956.GB11591@panix.com>

On Tue, Mar 18, 2008, Ronald Oussoren wrote:
> On 18 Mar, 2008, at 16:49, Aahz wrote:
>>On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
>>>
>>>When I do a relative star import, I current get
>>>
>>>SyntaxError: 'import *' not allowed with 'from .'
>>>
>>>What's the reason for this restriction?
>>
>>It was the first step in removing the ability to use "from *" at all.
>>I don't have time right now to find the discussion, but I can do that
>>later if you want.
>
> Do you remember approximately when and where this was discussed? I
> don't like the idea, but don't want to restart the discussion without
> reading the previous discussion.

It was part of PEP 328 (Relative Imports) [*] -- and actually, taking a
quick look at the PEP, it appears that the links within it point to some
discussion about the "import *" issue.

[*] General note to the list: see how I'm using both the PEP number and
the title.  For those of us who don't live and breath PEPs it is really
helpful to have both.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

From qrczak at knm.org.pl  Tue Mar 18 21:04:12 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 18 Mar 2008 21:04:12 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
Message-ID: <1205870652.31138.38.camel@qrnik>

Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:

> What sort of blocking wait do you use?  Or did you mean you don't have one?

I meant that I don't have one, I only have iteration over the whole
queue, which is equivalent to having trypop. Which prompts the question:
what are use cases of pop & wait, i.e. of blocking until the queue is
not empty?

I used to have weakref callbacks. They must be synchronized with the
rest of the program (unless their operations on shared data are already
atomic). Then I realized that a design with deathqueues suffices for
cases like WeakKeyDictionary, and it is not less convenient because
the queue can be checked in exactly those places where the design with
callbacks would lock the shared data.

Regarding interrupts, I have a more involved scheme with threads
blocking and unblocking interrupts, with a counter of the number of
blocks, with a special synchronous mode for being interruptible at
blocking operations only (similar to PTHREAD_CANCEL_DEFERRED, but the
default is PTHREAD_CANCEL_ASYNCHRONOUS), and with signals which don't
necessarily cause an exception but they execute a signal handler which
often throws an exception.

I've seen a simpler interrupt blocking scheme being proposed for Python,
based on the design in Haskell:
   http://www.cs.williams.edu/~freund/papers/python.pdf
but it seems to have been abandoned (the paper is from 2002 and I
haven't heard of anything newer).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From rhamph at gmail.com  Tue Mar 18 21:32:55 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 14:32:55 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <1205870652.31138.38.camel@qrnik>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
Message-ID: <aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>

On Tue, Mar 18, 2008 at 2:04 PM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
>
>
>  > What sort of blocking wait do you use?  Or did you mean you don't have one?
>
>  I meant that I don't have one, I only have iteration over the whole
>  queue, which is equivalent to having trypop. Which prompts the question:
>  what are use cases of pop & wait, i.e. of blocking until the queue is
>  not empty?

The finalizer thread blocks until something's been deleted.  I may
need a better API if I (eventually) switch to a threadpool for
finalizers though.


>  I used to have weakref callbacks. They must be synchronized with the
>  rest of the program (unless their operations on shared data are already
>  atomic). Then I realized that a design with deathqueues suffices for
>  cases like WeakKeyDictionary, and it is not less convenient because
>  the queue can be checked in exactly those places where the design with
>  callbacks would lock the shared data.
>
>  Regarding interrupts, I have a more involved scheme with threads
>  blocking and unblocking interrupts, with a counter of the number of
>  blocks, with a special synchronous mode for being interruptible at
>  blocking operations only (similar to PTHREAD_CANCEL_DEFERRED, but the
>  default is PTHREAD_CANCEL_ASYNCHRONOUS), and with signals which don't
>  necessarily cause an exception but they execute a signal handler which
>  often throws an exception.
>
>  I've seen a simpler interrupt blocking scheme being proposed for Python,
>  based on the design in Haskell:
>    http://www.cs.williams.edu/~freund/papers/python.pdf
>  but it seems to have been abandoned (the paper is from 2002 and I
>  haven't heard of anything newer).

I think deferred is a vastly better default.  To translate for
everybody else, deferred in this context means "set a flag that I/O
functions can check".  It means you'll only get a Cancelled exception
at documented points.

In contrast, asynchronous may raise an exception at totally arbitrary
points.  Maybe in the finally portion of a try/finally block, maybe
when you were about to call os.close().  It's not something you can
rely on.

Note though, my cancellation is *not* a signal handler mechanism!
There's a dedicated signal handler thread in which to process signals.
 Cancellation is only the last ditch, "abandon all hope - start
tearing down the program (or at least part of it)" option.

Incidentally, although I currently only support "deferred"
cancellation, I'd eventually like to add some sort of option for
"asynchronous" (what I tend to call "forced") cancellation.  It could
be used in what you know is a simple CPU bound math loop
(10**10**10?), or as a backup in the interactive interpreter.  The
interactive interpreter needs to be modified to use this all properly
anyway though, so I'm in no hurry.

-- 
Adam Olsen, aka Rhamphoryncus

From guido at python.org  Tue Mar 18 22:04:40 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 18 Mar 2008 16:04:40 -0500
Subject: [Python-3000] [Python-Dev] adding json to stdlib (was: Re: PEP
	361: Python 2.6/3.0 release schedule)
In-Reply-To: <ee2a432c0803180943t7e1589b6ye87d5523f51dcd27@mail.gmail.com>
References: <ee2a432c0803180943t7e1589b6ye87d5523f51dcd27@mail.gmail.com>
Message-ID: <ca471dc20803181404xb2c6549xd5df19cb26e6976c@mail.gmail.com>

On Tue, Mar 18, 2008 at 11:43 AM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <jmillikin at gmail.com> wrote:
>  > > Possible features for 2.6
>  >  >     New modules in the standard library:
>  >  >         - JSON implementation
>  >  >
>  >  Have there been any plans made for which one? All of the
>
>  No.  This was something I added as a nice to have for 2.6.

I'd like to tentatively elevate it to a must have. There has been
overwhelming support for this on web-sig.

>  >  implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
>  >  python-json) have serious issues that in my opinion should be fixed
>  >  before inclusion in the standard library[1]. I am the author of
>  >  jsonlib, and am willing to write patches for whichever implementation
>  >  becomes the standard, but it would be very nice to know what to focus
>  >  on.
>
>  I'm not familiar enough with any of the libraries to comment.  If it's
>  premature to add a particular implementation, that's fine, we can
>  wait.

On web-sig, the overwhelming majority wants simplejson, since that's
the API they already use. (All current web frameworks use it.)

>  >  Apologies if this has been discussed already, but there was no link to
>  >  a PEP in 361 and a search of python-dev and c.l.p returned no relevant
>  >  results.
>
>  I don't believe it has been discussed before.  I've changed the
>  subject and would like to discuss this now.
>
>  It would be great if you could pull together and get the community
>  behind a single solution that is robust enough to include in the
>  stdlib.  If that an be finished for 2.6, great.  If it waits for 2.7,
>  that would still be fine.

This is happening on web-sig as we speak.

--Guido

>  n
>
>  >
>  >  [1]
>  >  * cjson and python-json have almost complete absense of Unicode support.
>  >  * simplejson is slow and writes incorrect unicode escapes.
>  >  * demjson is far too forgiving when parsing and accepts all sorts of
>  >  invalid input.
>  >  * jsonlib is not PEP 8-compliant and has terrible error handling.
>  >  * python-json is abandoned, slow, and lacks Unicode support.
>  >
>  >
>  > _______________________________________________
>  >  Python-Dev mailing list
>  >  Python-Dev at python.org
>  >  http://mail.python.org/mailman/listinfo/python-dev
>  >  Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>  >
>  _______________________________________________
>  Python-Dev mailing list
>  Python-Dev at python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nnorwitz at gmail.com  Tue Mar 18 22:23:33 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 18 Mar 2008 16:23:33 -0500
Subject: [Python-3000] changing regrtest to handle import errors
Message-ID: <ee2a432c0803181423t40a44f75n969162751c99fed5@mail.gmail.com>

[changing to: and subject: ]

On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
>  <python-3000-checkins at python.org> wrote:
>  >  Get this test to pass (UserList/UserDict no longer exist and caused a skip).
>
>  I think the automatic skip on ImportError is harmful.
>
>  We should add a helper function to test_support so that you can write
>
>  foobar = test_support.import_optional('foobar')
>
>  and it will skip the test if foobar cannot be imported; all other
>  failing imports should cause the test to *fail*.
>
>  Any takers? This should be an easy two-part task.

This would be a great starter project for a new developer.
http://bugs.python.org/issue2409
Let me know if you could use some help.  Feel free to contact me on or off list.

n

From qrczak at knm.org.pl  Tue Mar 18 23:04:32 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 18 Mar 2008 23:04:32 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<1205843968.23745.9.camel@qrnik>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
Message-ID: <1205877872.10732.28.camel@qrnik>

Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:

> The finalizer thread blocks until something's been deleted.

Ok. If this is the only use case, I feel quite safe not having this,
because my finalizers are implemented independently (and a finalizer
thread is created on demand, which is cheap there).

> I think deferred is a vastly better default.  To translate for
> everybody else, deferred in this context means "set a flag that I/O
> functions can check".  It means you'll only get a Cancelled exception
> at documented points.

Well, if ^C uses the same mechanism, which is the case in my language,
then this means that ^C can only interrupt I/O, or synchronization with
other threads, or sleep, but not a long pure computation.

The choice of the default blocking state depends on the programming
style. The more shared data is mutated, the more tempting is to default
to deferred interrupts. The more functional style is, the safer are
asynchronous interrupts. Also defaulting to asynchronous interrupts
needs various language functions and constructs to block interrupts
implicitly, so code does not have to deal with interrupts all the time.
I agree that defaulting to asynchronous interrupts is risky, and might
be too demanding from library authors.

In reality whether a particular interrupt is safe to be processed
could depend on the kind of interrupt (e.g. even if a locally handled
interrupt should be blocked to avoid corrupting a data structure,
an interrupt which exits the whole program would be safe since the data
structure is dead then anyway). I have not considered such design in a
programming language. Looks too complex for its benefits.

> In contrast, asynchronous may raise an exception at totally arbitrary
> points.  Maybe in the finally portion of a try/finally block,

No, because my language blocks interrupts automatically there :-)

They are also blocked e.g. when a mutex is locked, or when a module is
being imported.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From greg at krypto.org  Tue Mar 18 23:21:49 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 18 Mar 2008 17:21:49 -0500
Subject: [Python-3000] binascii.crc32 vs zlib.crc32
Message-ID: <52dc1c820803181521s5cd7e01ia29fac02740fe739@mail.gmail.com>

Both modules have a crc32 function.  The zlib version is faster when zlib
has been compiled optimally or about the same when zlib is old or uses its C
code.

Should we ditch the binascii.crc32 version in py3k?

64bit Linux (CentOS 5.1):

$ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import binascii as mod'
'f = mod.crc32' 'for x in xrange(100000): f(foo)'
10 loops, best of 3: 108 msec per loop
$ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import zlib as mod' 'f =
mod.crc32' 'for x in xrange(100000): f(foo)'
10 loops, best of 3: 40.5 msec per loop

32bit MacOS X 10.4:

% python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import
binascii as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
10 loops, best of 3: 7.37e+04 usec per loop
% python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import
zlib as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
10 loops, best of 3: 4.62e+04 usec per loop

Removal from binascii would break things for platforms or embedded systems
wanting crc32 that don't want to include zlib.  Anyone care?

What about 2.x?  if we remove the redundancy in py3k i guess we deprecate
binascii.crc32 and remove in 2.7?

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080318/8e712cce/attachment.htm 

From rhamph at gmail.com  Tue Mar 18 23:22:36 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 16:22:36 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <1205877872.10732.28.camel@qrnik>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
Message-ID: <aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>

On Tue, Mar 18, 2008 at 4:04 PM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
>
>
>  > The finalizer thread blocks until something's been deleted.
>
>  Ok. If this is the only use case, I feel quite safe not having this,
>  because my finalizers are implemented independently (and a finalizer
>  thread is created on demand, which is cheap there).

Essentially, your "spawn a thread to handle this task" function serves
the same purpose.  As I said, I'd likely need to redesign if I had a
thread pool.  The details here aren't too important.


>  > I think deferred is a vastly better default.  To translate for
>  > everybody else, deferred in this context means "set a flag that I/O
>  > functions can check".  It means you'll only get a Cancelled exception
>  > at documented points.
>
>  Well, if ^C uses the same mechanism, which is the case in my language,
>  then this means that ^C can only interrupt I/O, or synchronization with
>  other threads, or sleep, but not a long pure computation.
>
>  The choice of the default blocking state depends on the programming
>  style. The more shared data is mutated, the more tempting is to default
>  to deferred interrupts. The more functional style is, the safer are
>  asynchronous interrupts. Also defaulting to asynchronous interrupts
>  needs various language functions and constructs to block interrupts
>  implicitly, so code does not have to deal with interrupts all the time.
>  I agree that defaulting to asynchronous interrupts is risky, and might
>  be too demanding from library authors.

I'd tend to assume only *purely* functional languages should have
asynchronous interrupts.  Any imperative language with them is
suspect.

Search for info on java's deprecated Thread.stop() if you're not
already familiar with the problems it has.


>  In reality whether a particular interrupt is safe to be processed
>  could depend on the kind of interrupt (e.g. even if a locally handled
>  interrupt should be blocked to avoid corrupting a data structure,
>  an interrupt which exits the whole program would be safe since the data
>  structure is dead then anyway). I have not considered such design in a
>  programming language. Looks too complex for its benefits.

In my case interrupt/cancellation raises an exception.  Doing so
asynchronously could have any manor of bad effects, effectively
eliminating the ability shut down gracefully.  If I wanted that I'd
just kill it from C (_exit(), abort(), SIGKILL, etc.)


>  > In contrast, asynchronous may raise an exception at totally arbitrary
>  > points.  Maybe in the finally portion of a try/finally block,
>
>  No, because my language blocks interrupts automatically there :-)
>
>  They are also blocked e.g. when a mutex is locked, or when a module is
>  being imported.

You mean the *entire* time a mutex is held?  That wouldn't work for
monitors, as they expect to hold their lock for extended periods of
time.

In fact, there's some implicit MonitorSpace's who's locks are very
likely to be held for the entire run of the program.

-- 
Adam Olsen, aka Rhamphoryncus

From qrczak at knm.org.pl  Tue Mar 18 23:52:54 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 18 Mar 2008 23:52:54 +0100
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
	<aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
Message-ID: <1205880774.10732.58.camel@qrnik>

Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:

> Search for info on java's deprecated Thread.stop() if you're not
> already familiar with the problems it has.

The problem with Java's Thread.stop() is that it is not possible to
block it in a given region, and that it is not possible to install
a different handler than throwing an exception. The first issue is
critical. If interrupts can't be blocked, it is impossible to declare
that a given operation is to be performed in whole or not at all, and
this is indeed unsafe.

If interrupts can be blocked, things are quite different, and I believe
that obtaining safe code is practical enough to make defaulting to
asynchronous interrupts a viable option.

> You mean the *entire* time a mutex is held?  That wouldn't work for
> monitors, as they expect to hold their lock for extended periods of
> time.

Aren't you including the time when a thread issues Monitor.wait()?
The mutex is unlocked there.

The coding style I am familiar with advises to not block while having
a lock. Also note that pthread_mutex_lock is not a cancellation point,
even though it can suspend the current thread.

In any case, in my language you can explicitly unblock interrupts
under a mutex, and of course waiting on a condition variable is normally
interruptible (the associated mutex is unlocked).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From rhamph at gmail.com  Wed Mar 19 00:07:34 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 17:07:34 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <1205880774.10732.58.camel@qrnik>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
	<aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
	<1205880774.10732.58.camel@qrnik>
Message-ID: <aac2c7cb0803181607n54ef9dc1tce2a45a149932868@mail.gmail.com>

On Tue, Mar 18, 2008 at 4:52 PM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
>
>
>  > Search for info on java's deprecated Thread.stop() if you're not
>  > already familiar with the problems it has.
>
>  The problem with Java's Thread.stop() is that it is not possible to
>  block it in a given region, and that it is not possible to install
>  a different handler than throwing an exception. The first issue is
>  critical. If interrupts can't be blocked, it is impossible to declare
>  that a given operation is to be performed in whole or not at all, and
>  this is indeed unsafe.
>
>  If interrupts can be blocked, things are quite different, and I believe
>  that obtaining safe code is practical enough to make defaulting to
>  asynchronous interrupts a viable option.

I disagree.  In theory you could block things extensively enough that
you'd be okay, but eventually you become equivalent to deferred - only
with a great deal more boilerplate.  The maintenance and testing
issues make it impractical.

Handlers are irrelevant.  Use those for signal handling, not thread
cancellation.


>  > You mean the *entire* time a mutex is held?  That wouldn't work for
>  > monitors, as they expect to hold their lock for extended periods of
>  > time.
>
>  Aren't you including the time when a thread issues Monitor.wait()?
>  The mutex is unlocked there.
>
>  The coding style I am familiar with advises to not block while having
>  a lock. Also note that pthread_mutex_lock is not a cancellation point,
>  even though it can suspend the current thread.

Keeping your critical sections tiny may be "good practise", but it's
not possible to do all the time.  In some cases you don't intend
another thread to modify your datastructures for a long period of
time.  In C you might skip locking altogether, but with safethread
you'll likely stick them in a monitor and never release the monitor.

Also, although conceptually related to posix cancellation points, by
aware that my implementation is totally independent.


>  In any case, in my language you can explicitly unblock interrupts
>  under a mutex, and of course waiting on a condition variable is normally
>  interruptible (the associated mutex is unlocked).


-- 
Adam Olsen, aka Rhamphoryncus

From greg.ewing at canterbury.ac.nz  Wed Mar 19 01:17:23 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 19 Mar 2008 12:17:23 +1200
Subject: [Python-3000] Auto PEP titling? (Re: from .foo import *)
In-Reply-To: <20080318195956.GB11591@panix.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
	<1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>
	<20080318195956.GB11591@panix.com>
Message-ID: <47E05B93.6050700@canterbury.ac.nz>

Aahz wrote:
> [*] General note to the list: see how I'm using both the PEP number and
> the title.

Maybe the Python-Dev list server could pass everything
through a filter that looks for "PEP xxxx" references
and inserts the PEP title after them? :-)

-- 
Greg

From greg.ewing at canterbury.ac.nz  Wed Mar 19 01:47:31 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 19 Mar 2008 12:47:31 +1200
Subject: [Python-3000] python-safethread project status
In-Reply-To: <aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<d11dcfba0803180821v5b49176bi6bb7fe23e4599e2c@mail.gmail.com>
	<aac2c7cb0803180855n2f8bf3c3wbb67b5e34769fd62@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
	<aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
Message-ID: <47E062A3.4030702@canterbury.ac.nz>

Adam Olsen wrote:
> I'd tend to assume only *purely* functional languages should have
> asynchronous interrupts.  Any imperative language with them is
> suspect.

Yet there are situations where *not* having any such thing
can be extremely inconvenient.

If I'm performing some background calculation that only
munges on its own data, and doesn't touch anything shared,
it's quite safe to kill it at any point and throw away
everything it was working on.

Being unable to do that from outside means that I have
to sprinkle explicit tests through it for an abort flag,
which is a horrible thing to have to do from a software
engineering standpoint for many reasons.

In the consenting-adults environment of Python, I don't
like having a useful facility withheld from me just
because it's possible to misuse it.

-- 
Greg

From rhamph at gmail.com  Wed Mar 19 02:41:17 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 18 Mar 2008 19:41:17 -0600
Subject: [Python-3000] python-safethread project status
In-Reply-To: <47E062A3.4030702@canterbury.ac.nz>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
	<aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
	<47E062A3.4030702@canterbury.ac.nz>
Message-ID: <aac2c7cb0803181841u37c594can7891a479d1d309c1@mail.gmail.com>

On Tue, Mar 18, 2008 at 6:47 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Adam Olsen wrote:
>  > I'd tend to assume only *purely* functional languages should have
>  > asynchronous interrupts.  Any imperative language with them is
>  > suspect.
>
>  Yet there are situations where *not* having any such thing
>  can be extremely inconvenient.
>
>  If I'm performing some background calculation that only
>  munges on its own data, and doesn't touch anything shared,
>  it's quite safe to kill it at any point and throw away
>  everything it was working on.
>
>  Being unable to do that from outside means that I have
>  to sprinkle explicit tests through it for an abort flag,
>  which is a horrible thing to have to do from a software
>  engineering standpoint for many reasons.
>
>  In the consenting-adults environment of Python, I don't
>  like having a useful facility withheld from me just
>  because it's possible to misuse it.

Sorry, I wasn't clear.  I'm only opposed to using it as the default.
There certainly are cases that demand it and I do wish to provide it
for them.

I suspect it'll be more practical to keep usage to a bare minimum
where you can't sprinkle checks for the cancellation flag, but that
doesn't matter much at this point.


-- 
Adam Olsen, aka Rhamphoryncus

From skip at pobox.com  Wed Mar 19 04:32:55 2008
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 18 Mar 2008 22:32:55 -0500
Subject: [Python-3000] JSON nit
Message-ID: <18400.35175.953074.951901@montanaro-dyndns-org.local>

Regarding putting some JSON implementation in the standard library...

I suppose anyone who uses JSON is aware of its limitations, but this was a
bit disconcerting:

    >>> simplejson.loads(simplejson.dumps({1: 2}))
    {u'1': 2}

Silent type conversion is a Perl thing.  I would prefer it if it raised a
TypeError if I tried to encode something other than a string as a dictionary
key.

Skip



From bob at redivi.com  Wed Mar 19 08:42:39 2008
From: bob at redivi.com (Bob Ippolito)
Date: Wed, 19 Mar 2008 00:42:39 -0700
Subject: [Python-3000] JSON nit
In-Reply-To: <18400.35175.953074.951901@montanaro-dyndns-org.local>
References: <18400.35175.953074.951901@montanaro-dyndns-org.local>
Message-ID: <6a36e7290803190042u13d973fan272eea9a7049aa7b@mail.gmail.com>

On Tue, Mar 18, 2008 at 8:32 PM,  <skip at pobox.com> wrote:
> Regarding putting some JSON implementation in the standard library...
>
>  I suppose anyone who uses JSON is aware of its limitations, but this was a
>  bit disconcerting:
>
>     >>> simplejson.loads(simplejson.dumps({1: 2}))
>     {u'1': 2}
>
>  Silent type conversion is a Perl thing.  I would prefer it if it raised a
>  TypeError if I tried to encode something other than a string as a dictionary
>  key.

It's also a JavaScript thing, which is why that behavior was chosen.
Yes it's silly, but no it has never caused anyone any (reported)
problems in practice.

-bob

From jyasskin at gmail.com  Wed Mar 19 09:06:55 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Wed, 19 Mar 2008 03:06:55 -0500
Subject: [Python-3000] python-safethread project status
In-Reply-To: <47E062A3.4030702@canterbury.ac.nz>
References: <aac2c7cb0803171056l7db4eb5at19d2bcbd8ccd77b9@mail.gmail.com>
	<fropq7$h45$1@ger.gmane.org>
	<aac2c7cb0803181024kb4cc139k7ba12061390de82b@mail.gmail.com>
	<1205867606.31138.11.camel@qrnik>
	<aac2c7cb0803181237w7bfb0829re376f67c11a5585e@mail.gmail.com>
	<1205870652.31138.38.camel@qrnik>
	<aac2c7cb0803181332q2b935b45j5cd59b8487c79139@mail.gmail.com>
	<1205877872.10732.28.camel@qrnik>
	<aac2c7cb0803181522h107493b7i3747959c01dc2ce8@mail.gmail.com>
	<47E062A3.4030702@canterbury.ac.nz>
Message-ID: <5d44f72f0803190106m1df58730vc6793c7dc7b6dcf7@mail.gmail.com>

FWIW, I think thread interruption/cancellation deserves a PEP. There
are a bunch of subtle issues like this, several other languages that
we can imitate, and a lot of places in the implementation that will
need to change to support it. I was planning to write the PEP a month
or two from now, but if someone else gets there first, I'll be happy
to help.

On Tue, Mar 18, 2008 at 7:47 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Adam Olsen wrote:
>  > I'd tend to assume only *purely* functional languages should have
>  > asynchronous interrupts.  Any imperative language with them is
>  > suspect.
>
>  Yet there are situations where *not* having any such thing
>  can be extremely inconvenient.
>
>  If I'm performing some background calculation that only
>  munges on its own data, and doesn't touch anything shared,
>  it's quite safe to kill it at any point and throw away
>  everything it was working on.
>
>  Being unable to do that from outside means that I have
>  to sprinkle explicit tests through it for an abort flag,
>  which is a horrible thing to have to do from a software
>  engineering standpoint for many reasons.
>
>  In the consenting-adults environment of Python, I don't
>  like having a useful facility withheld from me just
>  because it's possible to misuse it.
>
>  --
>  Greg
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/jyasskin%40gmail.com
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From ncoghlan at gmail.com  Wed Mar 19 10:57:28 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 19 Mar 2008 19:57:28 +1000
Subject: [Python-3000] from .foo import *
In-Reply-To: <20080318195956.GB11591@panix.com>
References: <47DFDE7D.407@v.loewis.de>
	<20080318154945.GA9803@panix.com>	<1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>
	<20080318195956.GB11591@panix.com>
Message-ID: <47E0E388.50707@gmail.com>

Aahz wrote:
> 
> It was part of PEP 328 (Relative Imports) [*] -- and actually, taking a
> quick look at the PEP, it appears that the links within it point to some
> discussion about the "import *" issue.

I found a question from Jack Jansen about it in one of the threads, but 
no real answer that I saw.

However, PEP 3100 (the general Py3k TO-DO list) includes a line item to 
get rid of "from ... import *" at function level because of the merry 
hell it plays with the local variable optimisations. It's possible the 
module level version also got clobbered when this was implemented.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From skip at pobox.com  Wed Mar 19 12:29:55 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Mar 2008 06:29:55 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
Message-ID: <18400.63795.52233.902170@montanaro-dyndns-org.local>


After the next SpamBayes release I plan to branch the code and work on
porting it to Python 3.0, mostly as an experiment in porting code from
Python 2.x to 3.x whose results I can feed back to the larger Python
community.  I'm curious about how best to approach the problem.  My first
thought is to run as many SpamBayes apps and tests as I can with the -3 flag
and resolve as many problems as it finds.  How soon before the set of
warnings it emits stabilizes?  Next would be to run 2to3 to do as much other
automatic conversion as possible.  Now run it under Python 3.x and resolve
any other issues.  Should I feed the problems I discover here back to the
community in hopes either -3 or 2to3 can be enhanced?

Then what?

Skip


From martin at v.loewis.de  Wed Mar 19 14:45:24 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 19 Mar 2008 08:45:24 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <18400.63795.52233.902170@montanaro-dyndns-org.local>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
Message-ID: <47E118F4.6000608@v.loewis.de>

> After the next SpamBayes release I plan to branch the code and work on
> porting it to Python 3.0, mostly as an experiment in porting code from
> Python 2.x to 3.x whose results I can feed back to the larger Python
> community.  I'm curious about how best to approach the problem.  My first
> thought is to run as many SpamBayes apps and tests as I can with the -3 flag
> and resolve as many problems as it finds.  How soon before the set of
> warnings it emits stabilizes?

Define "stabilize". In the sense that existing warnings will not be 
revoked anymore? That should be now already.

In the sense that no significant number of warnings will be added 
anymore? Not this year, I suppose. I would expect that 2.7 still adds
new -3 warnings, to cover cases where people report porting problems
that could have been warned about.

This is particularly the case when users won't start using -3 until
it stabilizes.

> Next would be to run 2to3 to do as much other
> automatic conversion as possible.  Now run it under Python 3.x and resolve
> any other issues.  Should I feed the problems I discover here back to the
> community in hopes either -3 or 2to3 can be enhanced?

Most definitely.

> Then what?

Hard to tell at the moment. Assuming you want to continue to support 2.x
and 3.x concurrently, you should come up with some strategy on how to do
that.

One option that I envision is that you might keep all sources as 2.x,
and only convert to 3.x at installation time, or perhaps at packaging
time. I don't know whether that would work for you, or would be
attractive. If not, you either need to come up with a different
strategy, or just continue to support only 2.x, and defer switching to
3.x to the future (say, 2010).

Regards,
Martin

From skip at pobox.com  Wed Mar 19 14:59:11 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Mar 2008 08:59:11 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <47E118F4.6000608@v.loewis.de>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<47E118F4.6000608@v.loewis.de>
Message-ID: <18401.7215.718758.363559@montanaro-dyndns-org.local>


    >> How soon before the set of warnings it emits stabilizes?

    Martin> Define "stabilize". In the sense that existing warnings will not
    Martin> be revoked anymore? That should be now already.

Maybe I should have written "stops growing significantly" or "plateaus"
instead of "stabilizes".  It seems to me that if people will be adding many
more -3 warnings in the next couple months I should wait until most/all
those warnings are added to the code.  I guess I was really asking if we've
passed the "knee" in the growth of the number of warnings -3 will emit.

    >> Then what?

    Martin> Hard to tell at the moment. Assuming you want to continue to
    Martin> support 2.x and 3.x concurrently, you should come up with some
    Martin> strategy on how to do that.

That's not a big problem.  I don't mind creating source distributions for
both for awhile (a couple years anyway).  

    Martin> One option that I envision is that you might keep all sources as
    Martin> 2.x, and only convert to 3.x at installation time, 

How can this ever work?  Aren't there always going to be some
incompatibilities which aren't covered by -3 or 2to3?  Those will require
manual code changes which aren't 2.x compatible.

I view this mostly as an exercise to provide feedback to the greater Python
community, not necessarily a straight-line path to 3.x support in
SpamBayes.

Skip

From eric+python-dev at trueblade.com  Wed Mar 19 15:25:50 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 19 Mar 2008 10:25:50 -0400
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <18401.7215.718758.363559@montanaro-dyndns-org.local>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>	<47E118F4.6000608@v.loewis.de>
	<18401.7215.718758.363559@montanaro-dyndns-org.local>
Message-ID: <47E1226E.6070005@trueblade.com>

skip at pobox.com wrote:
>     Martin> One option that I envision is that you might keep all sources as
>     Martin> 2.x, and only convert to 3.x at installation time, 
> 
> How can this ever work?  Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3?  Those will require
> manual code changes which aren't 2.x compatible.

I've always thought that yes, there will some things that 2to3 doesn't 
(or can't) fix, but it should be possible to modify your 2.x code so 
that you don't trigger these issues.  Then you'll end up with code that 
can in fact fun in 2.x and in 3.x by way of 2to3.

For example, say that 2to3 changes all instances of has_key to an "in" 
expression (I'm not saying it does this or not, I really don't know). 
If you have a Locksmith class that has a has_key method unrelated to 
dicts, then 2to3 would break it.  But it's certainly possible that you 
could change the method name in your 2.6 code and avoid the problem. 
You'd have 2.6 code that could automatically run in 3.0.

This won't work with public API's that can't be changed, but I think 
it's a valid strategy for most code.

The proposed 3to2 also might be a way out.

Eric.

From asmodai at in-nomine.org  Tue Mar 18 09:16:57 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 18 Mar 2008 09:16:57 +0100
Subject: [Python-3000] [Python-Dev] PEP 361: Python 2.6/3.0 release
	schedule
In-Reply-To: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
Message-ID: <20080318081657.GQ60713@nexus.in-nomine.org>

-On [20080318 01:52], Barry Warsaw (barry at python.org) wrote:
>This schedule gives everybody plenty of advanced notice, so you should be 
>able to get your code in on time.

In particular the memory related fixes over the last weeks, please. :)

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
To love someone deeply gives you strength. Being loved by someone deeply
gives you courage...

From jmillikin at gmail.com  Tue Mar 18 17:17:32 2008
From: jmillikin at gmail.com (John Millikin)
Date: Tue, 18 Mar 2008 11:17:32 -0500
Subject: [Python-3000] [Python-Dev] PEP 361: Python 2.6/3.0 release
	schedule
In-Reply-To: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
References: <AA3F9CF8-0245-43CA-8FD9-02A1291EB661@python.org>
Message-ID: <3283f7fe0803180917o459f52d5x32691b1d6d87a8ef@mail.gmail.com>

> Possible features for 2.6
>     New modules in the standard library:
>         - JSON implementation
>
Have there been any plans made for which one? All of the
implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
python-json) have serious issues that in my opinion should be fixed
before inclusion in the standard library[1]. I am the author of
jsonlib, and am willing to write patches for whichever implementation
becomes the standard, but it would be very nice to know what to focus
on.

Apologies if this has been discussed already, but there was no link to
a PEP in 361 and a search of python-dev and c.l.p returned no relevant
results.


[1]
* cjson and python-json have almost complete absense of Unicode support.
* simplejson is slow and writes incorrect unicode escapes.
* demjson is far too forgiving when parsing and accepts all sorts of
invalid input.
* jsonlib is not PEP 8-compliant and has terrible error handling.
* python-json is abandoned, slow, and lacks Unicode support.

From skip at pobox.com  Wed Mar 19 16:31:03 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Mar 2008 10:31:03 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <47E1226E.6070005@trueblade.com>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<47E118F4.6000608@v.loewis.de>
	<18401.7215.718758.363559@montanaro-dyndns-org.local>
	<47E1226E.6070005@trueblade.com>
Message-ID: <18401.12727.276330.892436@montanaro-dyndns-org.local>


    Eric> The proposed 3to2 also might be a way out.

Will be interesting to see how the round-trip code compares to the original.

Skip


From skip at pobox.com  Wed Mar 19 16:44:05 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Mar 2008 10:44:05 -0500
Subject: [Python-3000] csv.Sniffer - delete in Python 3.0?
Message-ID: <18401.13509.344107.988906@montanaro-dyndns-org.local>


The csv module contains a Sniffer class which is supposed to deduce the
delimiter and quote character as well as the presence or absence of a header
in a sample taken from the start of a purported CSV file.  I no longer
remember who wrote it, and I've never been a big fan of it.  It determines
the delimiter based almost solely on character frequencies.  It doesn't
consider what the actual structure of a CSV file is or that delimiters and
quote characters are almost always taken from the set of punctuation or
whitespace characters.  Consequently, it can cause some occasional
head-scratching:

    >>> sample = """\
    ... abc8def
    ... def8ghi
    ... ghi8jkl
    ... """
    >>> import csv
    >>> d = csv.Sniffer().sniff(sample)
    >>> d.delimiter
    '8'
    >>> sample = """\
    ... a8bcdef
    ... ab8cdef
    ... abc8def
    ... abcd8ef
    ... """
    >>> d = csv.Sniffer().sniff(sample)
    >>> d.delimiter
    'f'

It's not clear to me that people use letters or digits very often as
delimiters.  Both samples above probably represent data from single-column
files, not double-column files with '8' or 'f' as the delimiter.

I would be happy to get rid of it in 3.0, but I'm also aware that some
people use it.  I'd like feedback from the Python community about this.  If
I removed it is there someone out there who wants it badly enough to
maintain it in PyPI?

Thanks,

-- 
Skip Montanaro - skip at pobox.com - http://www.webfast.com/~skip/

From robin at reportlab.com  Wed Mar 19 17:24:46 2008
From: robin at reportlab.com (Robin Becker)
Date: Wed, 19 Mar 2008 16:24:46 +0000
Subject: [Python-3000] csv.Sniffer - delete in Python 3.0?
In-Reply-To: <18401.13509.344107.988906@montanaro-dyndns-org.local>
References: <18401.13509.344107.988906@montanaro-dyndns-org.local>
Message-ID: <47E13E4E.5030306@chamonix.reportlab.co.uk>

skip at pobox.com wrote:
........
> 
> I would be happy to get rid of it in 3.0, but I'm also aware that some
> people use it.  I'd like feedback from the Python community about this.  If
> I removed it is there someone out there who wants it badly enough to
> maintain it in PyPI?
......
sounds like we really need

import ai

info = ai.guess_what_this_is('crummy.csv')

but I suspect that won't arrive before py5000

I use csv, but almost always with tab or comma separation and \r\n line terminators.
-- 
Robin Becker


From guido at python.org  Wed Mar 19 20:08:06 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 19 Mar 2008 12:08:06 -0700
Subject: [Python-3000] from .foo import *
In-Reply-To: <47E0E388.50707@gmail.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>
	<1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>
	<20080318195956.GB11591@panix.com> <47E0E388.50707@gmail.com>
Message-ID: <ca471dc20803191208s1e45de0l861d24d8b790f8ee@mail.gmail.com>

On Wed, Mar 19, 2008 at 2:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>  However, PEP 3100 (the general Py3k TO-DO list) includes a line item to
>  get rid of "from ... import *" at function level because of the merry
>  hell it plays with the local variable optimisations. It's possible the
>  module level version also got clobbered when this was implemented.

That sounds like completely separate from relative import though, and
unrelated. I think outside functions "from .foo import *" should be
allowed.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Wed Mar 19 22:54:48 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 19 Mar 2008 22:54:48 +0100
Subject: [Python-3000] zlib.crc32 - signed or unsigned?
Message-ID: <47E18BA8.6050602@cheimes.de>

In Python 3.0 the unit test for zlib is broken because in 3.0 
zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed int.

How should the issue be solved? I think the unsigned long is wrong.

Christian

From lists at cheimes.de  Wed Mar 19 22:59:08 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 19 Mar 2008 22:59:08 +0100
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <47E1226E.6070005@trueblade.com>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>	<47E118F4.6000608@v.loewis.de>	<18401.7215.718758.363559@montanaro-dyndns-org.local>
	<47E1226E.6070005@trueblade.com>
Message-ID: <frs219$24l$1@ger.gmane.org>

Eric Smith schrieb:
> For example, say that 2to3 changes all instances of has_key to an "in" 
> expression (I'm not saying it does this or not, I really don't know). 
> If you have a Locksmith class that has a has_key method unrelated to 
> dicts, then 2to3 would break it.  But it's certainly possible that you 
> could change the method name in your 2.6 code and avoid the problem. 
> You'd have 2.6 code that could automatically run in 3.0.

IIRC Collin is working on a system to skip those with a comment like

  #2to3: skip fixer_haskey
  if egg.has_key(spam):

Christian



From charles.merriam at gmail.com  Wed Mar 19 23:31:37 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Wed, 19 Mar 2008 15:31:37 -0700
Subject: [Python-3000] Using *a for packing in lists and other places
In-Reply-To: <frmrqf$9bl$1@ger.gmane.org>
References: <ca471dc20803150915l27750346g8655f596f5035c69@mail.gmail.com>
	<frhgpf$k84$1@ger.gmane.org>
	<9e804ac0803151513j495be5d8h22bba219148cf491@mail.gmail.com>
	<frk6g8$dpt$1@ger.gmane.org> <1205751413.13377.11.camel@qrnik>
	<frmrqf$9bl$1@ger.gmane.org>
Message-ID: <b8c6f6c40803191531i132664edk711a053dbe112f11@mail.gmail.com>

On Mon, Mar 17, 2008 at 3:37 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>  ...
>  Can you give another rule that you prefer and that I can comprehend and
>  that I can explain to Python newcomers?  The OP only gave a few examples of
>  * usage and (initially) no rule that I saw.

Really, it is as clear as is the summer sun.   Maybe we should add it
to the tutorial to be clear:

'*':  Python expansion operator expands things to bigger things.  For
example, "3*5" expands 3 by multiplying by five while "3**5" expands
it twice resulting in exponentiation.  In exactly the same vein
'import * from mod" expands the implicit namespace by the symboles in
mod, unless mod has __all__ in which case by not all the symbols.  *a
expands a into a tuple, or into a the current tuple if inside a
function parameter list, so **a expands it twice, except at the end
where **a means it is a dictionary of names not used yet.  Which fits
well with the use of expanding in general expressions where *a,b,c =
expr expands a into a tuple to be big enough to hold the expression.
Be careful not to use **a,b,c = expr as this causes a to expand to far
and blow up the compiler.   Similarly the the * can be used on the
left hand side to expand things there.  * can't be used by itself as
you can't blow up nothing, and should be avoided on Sparc machines
because blowing up the sun is a nonrecoverable boo-boo.  See also
"diving where the is tuple while avoiding a really bad tan."  Some
code might make this clear.

import * from animals;
rabbits = rabbits * rabbits ** rabbits  # they breed fast and will
double expand before the single expand.
mice = *mouse.blind()*3 # poor mice in a tuple
*cat = *mice  # blind mice which is three mouses get eaten by a cat,
of which there is only one.
dog1, *dog2 = cat, *cat, *mice  # which is a concise way of saying if
two dogs eat the cat and the cat has mice, then
# the second dog eats not only the cat and the mice but any other
blind mice around.
count(first_dog=dog1, *dog2)
# how many mice are in the second dog is left as an exercise in philosophy.
# unfortunately, this really isn't very Pythonic because dogs are not
snakes, as everyone knows.


Seriously, this proposed syntax is about as clear as silly proposals
for "def foo(self, a,b,lamda c:self.d())"
creating an array of code to magically execute in a created context.
It's a useful special case, just not special enough.

Have a fun day!

From martin at v.loewis.de  Thu Mar 20 01:45:06 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 19 Mar 2008 19:45:06 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <18401.7215.718758.363559@montanaro-dyndns-org.local>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<47E118F4.6000608@v.loewis.de>
	<18401.7215.718758.363559@montanaro-dyndns-org.local>
Message-ID: <47E1B392.7080809@v.loewis.de>

>     Martin> One option that I envision is that you might keep all sources as
>     Martin> 2.x, and only convert to 3.x at installation time, 
> 
> How can this ever work?  Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3?  Those will require
> manual code changes which aren't 2.x compatible.

Like which incompatibilities specifically? I'm not aware of any.

There are certainly incompatibilities, but I am not aware of a case
where you can't write the code so that it works correctly in 2.x, and
then works also correctly after 2to3 has done its thing. Most likely,
this wouldn't work for SpamBayes as-is, but I can't see why it couldn't
work for SpamBayes when-changed.

> I view this mostly as an exercise to provide feedback to the greater Python
> community, not necessarily a straight-line path to 3.x support in
> SpamBayes.

Sure. As an exercise, I think it would be most useful if you actually
tried to implement some strategy for SpamBayes that you think other
projects could realistically also follow, and the report if and how
this strategy falls short.

Regards,
Martin



From martin at v.loewis.de  Thu Mar 20 02:30:25 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 19 Mar 2008 20:30:25 -0500
Subject: [Python-3000] zlib.crc32 - signed or unsigned?
In-Reply-To: <47E18BA8.6050602@cheimes.de>
References: <47E18BA8.6050602@cheimes.de>
Message-ID: <47E1BE31.70602@v.loewis.de>

Christian Heimes schrieb:
> In Python 3.0 the unit test for zlib is broken because in 3.0 
> zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed int.
> 
> How should the issue be solved? I think the unsigned long is wrong.

Here at the sprint people agreed that crc32 *obviously* gives
an unsigned number.

It's unfortunate that Python 2.6 can't really implement that
very well, hence we have to keep the 2.x behavior in 2.6.
In 3k, it should change.

Regards,
Martin

From skip at pobox.com  Thu Mar 20 03:00:38 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Mar 2008 21:00:38 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <47E1B392.7080809@v.loewis.de>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<47E118F4.6000608@v.loewis.de>
	<18401.7215.718758.363559@montanaro-dyndns-org.local>
	<47E1B392.7080809@v.loewis.de>
Message-ID: <18401.50502.497181.169511@montanaro-dyndns-org.local>


    >> How can this ever work?  Aren't there always going to be some
    >> incompatibilities which aren't covered by -3 or 2to3?  Those will
    >> require manual code changes which aren't 2.x compatible.

    Martin> Like which incompatibilities specifically? I'm not aware of any.

Nothing specifically.  I was simply under the impression that the conversion
couldn't be 100% from my reading, perhaps incorrectly, of the mailing list.

Skip

From martin at v.loewis.de  Thu Mar 20 04:11:32 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 19 Mar 2008 22:11:32 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <18401.50502.497181.169511@montanaro-dyndns-org.local>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<47E118F4.6000608@v.loewis.de>
	<18401.7215.718758.363559@montanaro-dyndns-org.local>
	<47E1B392.7080809@v.loewis.de>
	<18401.50502.497181.169511@montanaro-dyndns-org.local>
Message-ID: <47E1D5E4.9050306@v.loewis.de>

>     >> How can this ever work?  Aren't there always going to be some
>     >> incompatibilities which aren't covered by -3 or 2to3?  Those will
>     >> require manual code changes which aren't 2.x compatible.
> 
>     Martin> Like which incompatibilities specifically? I'm not aware of any.
> 
> Nothing specifically.  I was simply under the impression that the conversion
> couldn't be 100% from my reading, perhaps incorrectly, of the mailing list.

Depends on what you mean by "100%". The conversion is *always* 100% in
the sense that it converts the complete program to a complete (perhaps
inoperable) program. It will never ever drop pieces of source code, or
refuse to convert them. (David just found a case where it did refuse
processing, but these are bugs that can be fixed).

So it converts *all* source code. It some times does that correctly,
and sometimes incorrectly. It's difficult to talk about ratios here,
I rather see "correct conversion" as a binary property: it's either
correct, or it isn't.

Talking in fractions of all Python programs in existence, along
with all possible Python programs, conversion is certainly not correct
for 100% of all programs.

However, conversion is also not 0%, i.e, there are *some* programs
for which conversion is correct. A modified SpamBayes might be one of
them.

Regards,
Martin

P.S. In case you are interested in a formal definition of "correct
conversion", here is mine:
Given a specification of a program, and a Python 2.x application
conforming to that specification, the conversion is "correct" iff
the resulting 3.x application still conforms to the specification.

From greg at krypto.org  Thu Mar 20 07:26:47 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 20 Mar 2008 01:26:47 -0500
Subject: [Python-3000] zlib.crc32 - signed or unsigned?
In-Reply-To: <47E1BE31.70602@v.loewis.de>
References: <47E18BA8.6050602@cheimes.de> <47E1BE31.70602@v.loewis.de>
Message-ID: <52dc1c820803192326n2c6e167drb548055979888d92@mail.gmail.com>

On 3/19/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Christian Heimes schrieb:
>
> > In Python 3.0 the unit test for zlib is broken because in 3.0
> > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed
> int.
> >
> > How should the issue be solved? I think the unsigned long is wrong.
>
>
> Here at the sprint people agreed that crc32 *obviously* gives
> an unsigned number.
>
> It's unfortunate that Python 2.6 can't really implement that
> very well, hence we have to keep the 2.x behavior in 2.6.
> In 3k, it should change.
>
> Regards,
>
> Martin


yes crcs should be unsigned; they're fixed size bit fields.  it could even
make sense to return them as a 4 byte bytes/str object but that'd be an API
change.  a sign requires you to assume you know the length of the underlying
integer holding it.  python ints and longs don't have a fixed size so that
is troublesome and leads to lots of zlib.crc32(foo) & 0xffffffff and
binascii.crc32(foo) & 0xffffffff or other ugly tricks to un-sign the value.

I could make 2.6 return unsigned but it would mean that it returns a long
half of the time rather than an int.  The informal consensus in the room
earlier this week was to leave 2.x returning a signed value for
compatibility (I made it consistent so that it -always- returns a signed
regardless of sizeof(long)).  i'd be happy either way.

My recent checkin should have fixed the py3k tests and got them returning
unsigned again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/4bc66f4d/attachment.htm 

From guido at python.org  Thu Mar 20 07:39:45 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 19 Mar 2008 23:39:45 -0700
Subject: [Python-3000] zlib.crc32 - signed or unsigned?
In-Reply-To: <52dc1c820803192326n2c6e167drb548055979888d92@mail.gmail.com>
References: <47E18BA8.6050602@cheimes.de> <47E1BE31.70602@v.loewis.de>
	<52dc1c820803192326n2c6e167drb548055979888d92@mail.gmail.com>
Message-ID: <ca471dc20803192339n178e3598t8a7ca0ecea7ee35a@mail.gmail.com>

I say stick to what we have now: 2.6 signed, 3.0 unsigned. The 2.6
behavior is 100% compatible with 2.5 on 32bit boxes. It is 50%
incompatible with 2.5 on 64bit boxes, but it adds 100% compatibility
in 2.6 between 32bit and 64bit boxes (and also in 3.0 of course).

On Wed, Mar 19, 2008 at 11:26 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
>
> On 3/19/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Christian Heimes schrieb:
> >
> > > In Python 3.0 the unit test for zlib is broken because in 3.0
> > > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed
> int.
> > >
> > > How should the issue be solved? I think the unsigned long is wrong.
> >
> >
> > Here at the sprint people agreed that crc32 *obviously* gives
> > an unsigned number.
> >
> > It's unfortunate that Python 2.6 can't really implement that
> > very well, hence we have to keep the 2.x behavior in 2.6.
> > In 3k, it should change.
> >
> > Regards,
> >
> > Martin
>
> yes crcs should be unsigned; they're fixed size bit fields.  it could even
> make sense to return them as a 4 byte bytes/str object but that'd be an API
> change.  a sign requires you to assume you know the length of the underlying
> integer holding it.  python ints and longs don't have a fixed size so that
> is troublesome and leads to lots of zlib.crc32(foo) & 0xffffffff and
> binascii.crc32(foo) & 0xffffffff or other ugly tricks to un-sign the value.
>
> I could make 2.6 return unsigned but it would mean that it returns a long
> half of the time rather than an int.  The informal consensus in the room
> earlier this week was to leave 2.x returning a signed value for
> compatibility (I made it consistent so that it -always- returns a signed
> regardless of sizeof(long)).  i'd be happy either way.
>
> My recent checkin should have fixed the py3k tests and got them returning
> unsigned again.
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Thu Mar 20 08:02:32 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 20 Mar 2008 00:02:32 -0700
Subject: [Python-3000] binascii.crc32 vs zlib.crc32
In-Reply-To: <52dc1c820803181521s5cd7e01ia29fac02740fe739@mail.gmail.com>
References: <52dc1c820803181521s5cd7e01ia29fac02740fe739@mail.gmail.com>
Message-ID: <ca471dc20803200002y840c081if3191f50f280ba1e@mail.gmail.com>

Hm.  zlib is an odd place to find this API (unless you know way more
about gzip than healthy :-).  Though binascii isn't much better.  I'd
rather expect this in the vicinity of md5 and sha... Is it possible to
tweak that C code to use the zlib version if present and the old C
code otherwise?

On Tue, Mar 18, 2008 at 3:21 PM, Gregory P. Smith <greg at krypto.org> wrote:
> Both modules have a crc32 function.  The zlib version is faster when zlib
> has been compiled optimally or about the same when zlib is old or uses its C
> code.
>
> Should we ditch the binascii.crc32 version in py3k?
>
>  64bit Linux (CentOS 5.1):
>
> $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import binascii as mod'
> 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
>  10 loops, best of 3: 108 msec per loop
> $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import zlib as mod' 'f =
> mod.crc32' 'for x in xrange(100000): f(foo)'
>  10 loops, best of 3: 40.5 msec per loop
>
> 32bit MacOS X 10.4:
>
> % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import
> binascii as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
>  10 loops, best of 3: 7.37e+04 usec per loop
> % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import
> zlib as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
>  10 loops, best of 3: 4.62e+04 usec per loop
>
> Removal from binascii would break things for platforms or embedded systems
> wanting crc32 that don't want to include zlib.  Anyone care?
>
> What about 2.x?  if we remove the redundancy in py3k i guess we deprecate
> binascii.crc32 and remove in 2.7?
>
> -gps
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tnelson at onresolve.com  Thu Mar 20 08:13:00 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Thu, 20 Mar 2008 00:13:00 -0700
Subject: [Python-3000] PyLong_Check() behaviour clarification (test_getargs2
 failing on Windows x64)
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEE32@EXMBX04.exchhosting.com>

test_getargs2 is failing on Windows x64:
test test_getargs2 failed -- Traceback (most recent call last):
  File "S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py", line 190, in test_n
    self.failUnlessEqual(99, getargs_n(Long()))
TypeError: 'Long' object cannot be interpreted as an integer

Drilling down into the source, this code arrives at Python/getargs.c:convertsimple().  On Windows x64, SIZEOF_SIZE_T != SIZEOF_LONG, so there's a case 'n' statement that is defined that does the following:

    iobj = PyNumber_Index(arg);

I'm a little confused.  At this point, arg is a PyObject *, and arg->obj_type->tp_as_number->nb_int has a non-zero value.  However, PyNumber_Index(arg) performs two checks, and this object fails both, which results in the TypeError being raised.

The first check is PyLong_Check(arg), which is handled via PyType_FastSubclass, which ends up doing the following:

    ((arg->obj_type->tp_flags & Py_TPFLAGS_LONG_SUBCLASS) != 0)

tp_flags is 284160 at this point.  Py_TPFLAGS_LONG_SUBCLASS is 16777216 and Py_TPFLAGS_INT_SUBCLASS is 8388608, so this check fails.  Why doesn't tp_flags have either one of these values here?  obj_type->nb_int has a value, so shouldn't flags reflect the type?

I've just checked a 32-bit build and PyNumber_Index for a PyObject * representing a literal 99 also exhibits the same behaviour as above.

Also, if we're a 32-bit build, the 'n' code path visits PyLong_AsLong(), which calls PyLong_AsLongAndOverflow() -- the test cases calling getargs_n() test for the overflow being raised correctly.  Notionally, on x64 Windows where ((size_t == long long) > long), shouldn't we have a PyLong_AsLongLongAndOverflow() method?

    Trent.

From regebro at gmail.com  Thu Mar 20 08:48:11 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 08:48:11 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
Message-ID: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>

Hiya all, I've googled for this issue but I couldn't find it so I hope
this hasn't been beaten to death already.

I've been doing some compatibility tests with 3.0a3, 2.6a1 and 2.5, to
see exactly what breaks and how and if you can get around it,
basically to see if it is possible to write code that runs under both
2.6 and 3.0 without too much pain. It's looking rather encouraging,
most differences have easy workarounds. Some of them need try/except
clauses which could be collected in a small compatibility module
installable as an egg for those who want it.

There is one big problem though, and it's unicode. I'm happy to see
that 2.6 has the b'data' syntax as an alias for 'data', to make it
easier to port code from 2.6 to 3.0. But 3.0 doesn't support the
u''syntax, and that means that it gets very hard to use unicode in an
application and run it under 2.6 and 3.0. You can get around it with
this workaround:

    try:
        u = unicode
    except NameError:
        u = str
    text = u("This is unicode")

But this is still not perfect, as this means you only can have
ascii-texts in the unicode strings. That's OK for people like me that
use Zope, because we'll use i18n tools to localize texts anyway, but I
suspect it's not going to be OK for others. Also, it's ugly. :-)


I would really like to see u'text' support in Python 3.0, as an alias
for 'text'. If we can have that, it means that 90% of all code I have
written will just straight of in Python 3.0 (yeah, really), and most
of the remaining code can be fixed with conditional imports of the
renamed standard modules.

Admittedly, this is because I rarely use xrange or iterkeys. Also, I
rarely print, I use the logging module, and so on. But I don't think
that is so unusual, is it?


So, please allow u'' in Python 3.0! With that change, my
porting/compatibility worried would be gone, and  you would be able to
choose between the three porting strategies dependningon how your code
base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
Supporting both 2.6 and 3.0.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From abpillai at gmail.com  Thu Mar 20 10:26:12 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Thu, 20 Mar 2008 14:56:12 +0530
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <ca471dc20803170638v4704ab63g2539d9c1f0d9d6fe@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
	<8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>
	<ca471dc20803170638v4704ab63g2539d9c1f0d9d6fe@mail.gmail.com>
Message-ID: <8548c5f30803200226w1c41ce3btb6ef7d21ac7fe7cb@mail.gmail.com>

Hi,

  Sorry for the late reply. Looked into the bug list, the following bugs
looked interesting.

http://bugs.python.org/issue2122
http://bugs.python.org/issue2188
http://bugs.python.org/issue2320
http://bugs.python.org/issue2325
http://bugs.python.org/issue2355
http://bugs.python.org/issue2389

There are also many bugs filed for Py3k which are patterned
like "deprecated feature <oldfeature> should raise a warning in py3k".
Are they in any priority ?

I would like looking into any or some of the above bugs or perhaps
the warning bugs. How do I go about doing it ?

Thanks

--Anand

On Mon, Mar 17, 2008 at 7:08 PM, Guido van Rossum <guido at python.org> wrote:
> Glad you want to help!
>
>  You can find plenty of things to do in the bug tracker at
>  bugs.python.org. Note that 2.6 needs as much (or more!) love as 3.0 at
>  this point. (2.6 is being developed in the svn trunk.) Feel free to
>  tentatively pick a project and send mail here asking if that's
>  something we'd like to have fixed.
>
>  Again, thanks!
>
>  --Guido
>
>
>
>  On Mon, Mar 17, 2008 at 2:48 AM, Anand Balachandran Pillai
>  <abpillai at gmail.com> wrote:
>  > Hi py3k,
>  >
>  >      First of all, excuse me for taking your time. I am new to the list
>  >  so, not familiar with the processes specific to the list, if any.
>  >
>  >      I am new to the list (joined a week back) but not new to Python having
>  >  coded in it for a fair bit of time and contributed open source code in Python,
>  >  but not yet to the Python project.
>  >
>  >     I have been reading the py3k archives and some recent mails. I
>  >  would like to help out in some way. I am familiar with the Python
>  >  development process and has read most of the PEPs related to
>  >  Py3k. Perhaps there are some bugs to fix, some documentation to
>  >  be done, testing ... ?
>  >
>  >     Excuse me if I sound naive, but I am not sure where to start.
>  >  I checked out py3k branch, built it and have it running on my Fedora box.
>  >  Is there a URL showing a list of tasks to start with so I can start on
>  >  something ?
>  >
>  >  Did not want to start a new thread for my post, so replying to a thread
>  >  which seemed relevant.
>  >
>  >  Thanks a lot for your patience.
>  >
>  >  Best Regards
>  >
>  >  --Anand
>  >
>  >  http://harvestmanontheweb.com
>  >
>  >
>  >
>  >
>  >  On Mon, Mar 17, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>  >  > -----BEGIN PGP SIGNED MESSAGE-----
>  >  >  Hash: SHA1
>  >  >
>  >  >
>  >  > On Mar 16, 2008, at 5:02 PM, Martin v. L?wis wrote:
>  >  >
>  >  >  >> How about using the "critical" Severity for show stoppers?
>  >  >  >
>  >  >  > Alternatively, Priority "immediate" could be used.
>  >  >  >
>  >  >  > The intended use of Severity is that it is assigned by the
>  >  >  > submitter, whereas Priority is assigned by triage/developers.
>  >  >  >
>  >  >  > We should really decide whether we want to use it that way.
>  >  >
>  >  >  That would certainly work for me.  Could we add some description of
>  >  >  this separation to the Roundup pages?  And/or is there a way that only
>  >  >  developers or the triage specialists are allowed to change the priority?
>  >  >
>  >  >
>  >  >  - -Barry
>  >  >
>  >  >  -----BEGIN PGP SIGNATURE-----
>  >  >  Version: GnuPG v1.4.8 (Darwin)
>  >  >
>  >  >  iQCVAwUBR92x4HEjvBPtnXfVAQLAAAP9FIS+Z3OI4CK+KVSrqkuZkwTl2cs0Rk3Q
>  >  >  6RQNNuReyLIGPXqvXoFcOO2zZcZdWVcSwkw7DJhzV1yPI9z2/KY5ve298Mg75afG
>  >  >  eFJO+TVH24LsWyOqXe9Aodoaf+OUpJcAhRy6q1YVtTlxoY/VuiOUtNjhNsJ7DKWP
>  >  >  WwlDBlduW0g=
>  >  >  =/42B
>  >  >  -----END PGP SIGNATURE-----
>  >  >
>  >  >
>  >
>  > > _______________________________________________
>  >  >  Python-3000 mailing list
>  >  >  Python-3000 at python.org
>  >  >  http://mail.python.org/mailman/listinfo/python-3000
>  >  >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>  >  >
>  >
>  >
>  >
>  >  --
>  >  -Anand
>  >
>  >
>  > _______________________________________________
>  >  Python-3000 mailing list
>  >  Python-3000 at python.org
>  >  http://mail.python.org/mailman/listinfo/python-3000
>  >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>
> >
>
>
>
>  --
>  --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
-Anand

From ncoghlan at gmail.com  Thu Mar 20 11:23:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 20 Mar 2008 20:23:21 +1000
Subject: [Python-3000] from .foo import *
In-Reply-To: <ca471dc20803191208s1e45de0l861d24d8b790f8ee@mail.gmail.com>
References: <47DFDE7D.407@v.loewis.de> <20080318154945.GA9803@panix.com>	
	<1B65D90C-6043-42F3-925E-6B03BFAD9C3E@mac.com>	
	<20080318195956.GB11591@panix.com> <47E0E388.50707@gmail.com>
	<ca471dc20803191208s1e45de0l861d24d8b790f8ee@mail.gmail.com>
Message-ID: <47E23B19.5000004@gmail.com>

Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 2:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>  However, PEP 3100 (the general Py3k TO-DO list) includes a line item to
>>  get rid of "from ... import *" at function level because of the merry
>>  hell it plays with the local variable optimisations. It's possible the
>>  module level version also got clobbered when this was implemented.
> 
> That sounds like completely separate from relative import though, and
> unrelated. I think outside functions "from .foo import *" should be
> allowed.
> 

Oh, I agree (it's an invaluable trick for things like "from 
._hidden_module import *"). I was just speculating on how the module 
level variant may have come to be broken in the first place, not 
suggesting that the breakage was intentional or a good idea. My 
curiousity isn't strong enough to get me to trawl through the svn 
history to find out the actual cause though ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Thu Mar 20 11:28:48 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 20 Mar 2008 20:28:48 +1000
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
Message-ID: <47E23C60.6030306@gmail.com>

Lennart Regebro wrote:
> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and  you would be able to
> choose between the three porting strategies dependningon how your code
> base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
> Supporting both 2.6 and 3.0.

3 is not an option, and isn't going to be an option. The intended 
approach for string compatibility is to use u'' and b'' in 2.6, and let 
2to3 take care of converting the u'' to '' in the 3.0 version.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From regebro at gmail.com  Thu Mar 20 11:45:41 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 11:45:41 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E23C60.6030306@gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
Message-ID: <319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>

On Thu, Mar 20, 2008 at 11:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>  3 is not an option, and isn't going to be an option.

I know the Python 3000 project started with the attitude of not having
any backwards compatibility to be able to start at a blank slate. But
since then the compatibility set has increased so far that 3 now could
be an option with very little effort.

3 *should* be an option, as well. Loads of software, in particular the
whole Plone community, which is a significant part of the Python user
base, will struggle very hard if 3 is not an option. But this
discussion *has* been beaten to death. 3 should be an option, and it
is an option, if u'' gets supported.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Thu Mar 20 13:00:15 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 07:00:15 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
Message-ID: <47E251CF.2050104@v.loewis.de>

> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and  you would be able to
> choose between the three porting strategies dependningon how your code
> base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
> Supporting both 2.6 and 3.0.

It's as Nick says. Run 2to3. Can you please explain why that doesn't
sound acceptable to you? By running 2to3, you *get* option 3; you
support 2.6 and 3.0 from a single code base.

Regards,
Martin


From schmir at gmail.com  Thu Mar 20 13:07:37 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 20 Mar 2008 13:07:37 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E251CF.2050104@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
Message-ID: <932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>

On Thu, Mar 20, 2008 at 1:00 PM, "Martin v. L?wis" <martin at v.loewis.de>
wrote:

> > So, please allow u'' in Python 3.0! With that change, my
> > porting/compatibility worried would be gone, and  you would be able to
> > choose between the three porting strategies dependningon how your code
> > base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
> > Supporting both 2.6 and 3.0.
>
> It's as Nick says. Run 2to3. Can you please explain why that doesn't
> sound acceptable to you? By running 2to3, you *get* option 3; you
> support 2.6 and 3.0 from a single code base.
>

Well, he is basically required to compile his source code before he can run
it.
This is quite uncommon for python code...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/b1067877/attachment.htm 

From martin at v.loewis.de  Thu Mar 20 13:16:56 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 07:16:56 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
Message-ID: <47E255B8.9080007@v.loewis.de>


> Well, he is basically required to compile his source code before he can 
> run it.
> This is quite uncommon for python code...

However, it *is* common to install Python code before running it.

I propose a scheme (which is almost implemented) where you run
2to3 as part of the distutils build step. So the converted sources
land in the build directory, if setup.py runs under 3.0 (and you
explicitly asked distutils to perform the conversion).

Then, you can either install to the target directory, or run
from the build directory. distutils does time-stamp based dependency
tracking, so it only recompiles things when you change the original
source.

So yes, you get a compilation step, but not one unheard of (distutils
isn't new), and with the usual standard of comfort for compile steps.

Lennart, can you please comment whether this (need for compilation)
was also your concern, or just Ralf's?

Regards,
Martin


From regebro at gmail.com  Thu Mar 20 13:30:19 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 13:30:19 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E255B8.9080007@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
Message-ID: <319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>

On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  However, it *is* common to install Python code before running it.

Not every time you make a change in the code.

>  Lennart, can you please comment whether this (need for compilation)
>  was also your concern, or just Ralf's?

That is a part of it yes.

I have to say I thought this discussion was over with, and that the
argument against this was that it would be too difficult to support a
large enough common codebase between 2.6 and 3.0 for it to be useable.
Of course, it was impossible to say if this was the case before the
2.6a1 was out. Now it is out, and I have started testing.

And as far as I can see, this not the case. The overlap is very big,
very much thanks to 2.6 supporting many of the new syntax of 3.0. The
unicode u'' seems to be the only major stumbling block. Hence, a
common codeset *is* a practical possibility.

Now, it is quite possible to say that this isn't desirable, and that
2.6 and 3.0 should not be able to run the same code at all, even if
that was possible, but I haven't heard that opinion, and hope it isn't
common.

If we need to have this discussion again, I will prepare a longer
answer to why the 2to3 conversion should be supplemented with a
possible gradual code path. I started to write an answer already, but
it's going to take me a while, and I'd rather not. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From schmir at gmail.com  Thu Mar 20 13:38:35 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 20 Mar 2008 13:38:35 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
Message-ID: <932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>

On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> >  However, it *is* common to install Python code before running it.
>
> Not every time you make a change in the code.
>

I also happen to have test code that will not be installed with python
setup.py install, so I would have to manually convert that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/fed4d6ae/attachment.htm 

From amauryfa at gmail.com  Thu Mar 20 14:28:31 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 20 Mar 2008 14:28:31 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>
Message-ID: <e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>

Ralf Schmitt wrote:
>
> On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro <regebro at gmail.com> wrote:
> >
> > On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> > >  However, it *is* common to install Python code before running it.
> >
> > Not every time you make a change in the code.
> >
>
> I also happen to have test code that will not be installed with python
> setup.py install, so I would have to manually convert that.

What about using sys.path_hooks to run 2to3 on the fly at import time?
It would cache its results, of course.

-- 
Amaury Forgeot d'Arc

From martin at v.loewis.de  Thu Mar 20 15:01:36 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 09:01:36 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E251CF.2050104@v.loewis.de>	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	<47E255B8.9080007@v.loewis.de>	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	<932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>
	<e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
Message-ID: <47E26E40.9020909@v.loewis.de>

> What about using sys.path_hooks to run 2to3 on the fly at import time?
> It would cache its results, of course.

It would have to do so selectively, and it would be fairly slow (atleast
with the current implementation), but yes, that could also work.

The question then is: what __file__ do you put into the code? The
original one, or the cached one? I'd vote for the cached copy, so
that you get sensible output in tracebacks. It probably should
also mark the cached copy read-only on disk, so that people won't
attempt to edit it. If off-by-one errors are acceptable, it could
also try to put a first-line comment "GENERATED" into it.

Regards,
Martin


From martin at v.loewis.de  Thu Mar 20 15:09:18 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 09:09:18 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E251CF.2050104@v.loewis.de>	
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
Message-ID: <47E2700E.3050700@v.loewis.de>

> Now, it is quite possible to say that this isn't desirable, and that
> 2.6 and 3.0 should not be able to run the same code at all, even if
> that was possible, but I haven't heard that opinion, and hope it isn't
> common.
> 
> If we need to have this discussion again, I will prepare a longer
> answer to why the 2to3 conversion should be supplemented with a
> possible gradual code path. I started to write an answer already, but
> it's going to take me a while, and I'd rather not. :)

That would be wasteful, indeed.

Few people think that 3k should actively, aggressively, deliberately
break 2.x code.

However, it is decided and has been carved into stone that 3k must
not include any transitional features that serve no other purpose
but to allow running 2.x code. Therefore, you won't get u'text' as
an alternative for 'text', and you won't get a 'unicode' builtin.
All the transitional mechanisms either get into 2.x, or 2to3, or not
implemented at all.

Regards,
Martin

From schmir at gmail.com  Thu Mar 20 15:20:29 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 20 Mar 2008 15:20:29 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2700E.3050700@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<47E2700E.3050700@v.loewis.de>
Message-ID: <932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>

On Thu, Mar 20, 2008 at 3:09 PM, "Martin v. L?wis" <martin at v.loewis.de>
wrote:

> > Now, it is quite possible to say that this isn't desirable, and that
> > 2.6 and 3.0 should not be able to run the same code at all, even if
> > that was possible, but I haven't heard that opinion, and hope it isn't
> > common.
> >
> > If we need to have this discussion again, I will prepare a longer
> > answer to why the 2to3 conversion should be supplemented with a
> > possible gradual code path. I started to write an answer already, but
> > it's going to take me a while, and I'd rather not. :)
>
> That would be wasteful, indeed.
>
> Few people think that 3k should actively, aggressively, deliberately
> break 2.x code.
>
> However, it is decided and has been carved into stone that 3k must
> not include any transitional features that serve no other purpose
> but to allow running 2.x code. Therefore, you won't get u'text' as
> an alternative for 'text', and you won't get a 'unicode' builtin.
> All the transitional mechanisms either get into 2.x, or 2to3, or not
> implemented at all.
>

Will python 2.6 have something like "from future import
unicode_string_literals" ?
This should also solve lennart's problem. (But then py3k would need to
support that future import, which
is forbidden).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/9b99d85c/attachment-0001.htm 

From jimjjewett at gmail.com  Thu Mar 20 15:55:03 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 20 Mar 2008 10:55:03 -0400
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <8548c5f30803200226w1c41ce3btb6ef7d21ac7fe7cb@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
	<8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>
	<ca471dc20803170638v4704ab63g2539d9c1f0d9d6fe@mail.gmail.com>
	<8548c5f30803200226w1c41ce3btb6ef7d21ac7fe7cb@mail.gmail.com>
Message-ID: <fb6fbf560803200755m15a024a6s28dbf635cd362316@mail.gmail.com>

On 3/20/08, Anand Balachandran Pillai <abpillai at gmail.com> wrote:

>  There are also many bugs filed for Py3k which are patterned
>  like "deprecated feature <oldfeature> should raise a warning in py3k".
>  Are they in any priority ?

Do you really mean warn in 3.0?  Or do you mean that they're gone (or
should be, or might be) in 3.x, and should raise a warning in 2.6,
given the -3 flag?

If something is removed in 3.0, would a failure to warn in 2.x under
-3 mode be considered a bug that could get fixed in 2.6.1, or would
the warning have to wait for 2.7?

-jJ

From jimjjewett at gmail.com  Thu Mar 20 16:02:23 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 20 Mar 2008 11:02:23 -0400
Subject: [Python-3000] from .foo import *
In-Reply-To: <47DFDE7D.407@v.loewis.de>
References: <47DFDE7D.407@v.loewis.de>
Message-ID: <fb6fbf560803200802h69bc8f4exc58861d35b557e3e@mail.gmail.com>

I *think* you already fixed this; if not, I agree it should be fixed.
While import * is not great, I think the alternative is worse.

As you point out, an explicit listing is unmaintainable, and the
alternative is a funky dance to first import that module's __all__,
then import based on that -- which still has all the disadvantanges of
import *.

-jJ

On 3/18/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:

>  but that still won't work because of the syntax
>  error. One solution would be to make the import
>  explicit, but that is tedious and unmaintainable.
>  E.g. for the widgets line, it would be
>
>  from .widgets import (Widget, TextInput, PasswordInput,
>      HiddenInput, MultipleHiddenInput,
>      FileInput, DateTimeInput, Textarea, CheckboxInput,
>      Select, NullBooleanSelect, SelectMultiple, RadioSelect,
>      CheckboxSelectMultiple, MultiWidget, SplitDateTimeWidget)

From jimjjewett at gmail.com  Thu Mar 20 16:15:16 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 20 Mar 2008 11:15:16 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>
	<e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
Message-ID: <fb6fbf560803200815y79d498ffqb72555e013d51062@mail.gmail.com>

Lennart Regebro
Ralf Schmitt


On 3/20/08, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:

> What about using sys.path_hooks to run 2to3 on the fly at import time?
>  It would cache its results, of course.

I think even that might be overkill; Lennart (and others) are talking
about trying to use the same code in both cases, and finding that the
only difference is u"..." vs "...".

That sounds simple enough that I think it could be done as part of a codec.
Instead of of "coding: utf-8", he could use "coding: py2-utf-8", which
would delegate to utf-8, and then make this one fairly quick
substution.

-jJ

From charles.merriam at gmail.com  Thu Mar 20 16:40:57 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Thu, 20 Mar 2008 08:40:57 -0700
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
Message-ID: <b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>

Hello Lennart,

As you can see by the growing conversation, the matter is a bit old
and, with age, smells
bad.  I'd like to convince you that it is a bad idea anyway.

The problem is not the gratuitous removal of the leading 'u', but the
subtle problems when
the code looks nearly identical.  The most likely one to cause
problems is the new semantics
of the keys operations.   While I haven't read the 3.0 code, this is
what was stated at Guido's
last talk.

On Thu, Mar 20, 2008 at 3:45 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Thu, Mar 20, 2008 at 11:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>  >  3 is not an option, and isn't going to be an option.
>
>  I know the Python 3000 project started with the attitude of not having
>  any backwards compatibility to be able to start at a blank slate. But
>  since then the compatibility set has increased so far that 3 now could
>  be an option with very little effort.
>
>  3 *should* be an option, as well. Loads of software, in particular the
>  whole Plone community, which is a significant part of the Python user
>  base, will struggle very hard if 3 is not an option. But this
>  discussion *has* been beaten to death. 3 should be an option, and it
>  is an option, if u'' gets supported.
>
>
>  --
>  Lennart Regebro: Zope and Plone consulting.
>  http://www.colliberty.com/
>  +33 661 58 14 64
>  _______________________________________________
>
>
> Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>

From charles.merriam at gmail.com  Thu Mar 20 16:50:54 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Thu, 20 Mar 2008 08:50:54 -0700
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
Message-ID: <b8c6f6c40803200850s2fc796d8tb8142154bf9ad32f@mail.gmail.com>

@#$ send in the middle of the email.    Sorry.

Short version:  Python 3000 breaks other code as well, some subtly.
This could be bad.    One long debugging
session over a missing character on a report due to the change in
representation of a Long could make all
the work of trying for an easy "3to2" conversion tool moot.

I don't know if the list has considered proposals to generalize the
underlying string prefix operator, such that
a user could somehow write a function t"Hello" to be equivalent to
gettext.gettext("Hello").  Has it been
brought up before?

On Thu, Mar 20, 2008 at 8:40 AM, Charles Merriam
<charles.merriam at gmail.com> wrote:
> Hello Lennart,
>
>  As you can see by the growing conversation, the matter is a bit old
>  and, with age, smells
>  bad.  I'd like to convince you that it is a bad idea anyway.
>
>  The problem is not the gratuitous removal of the leading 'u', but the
>  subtle problems when
>  the code looks nearly identical.  The most likely one to cause
>  problems is the new semantics
>  of the keys operations.   While I haven't read the 3.0 code, this is
>  what was stated at Guido's
>  last talk.
>
>
>
>  On Thu, Mar 20, 2008 at 3:45 AM, Lennart Regebro <regebro at gmail.com> wrote:
>  > On Thu, Mar 20, 2008 at 11:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>  >  >  3 is not an option, and isn't going to be an option.
>  >
>  >  I know the Python 3000 project started with the attitude of not having
>  >  any backwards compatibility to be able to start at a blank slate. But
>  >  since then the compatibility set has increased so far that 3 now could
>  >  be an option with very little effort.
>  >
>  >  3 *should* be an option, as well. Loads of software, in particular the
>  >  whole Plone community, which is a significant part of the Python user
>  >  base, will struggle very hard if 3 is not an option. But this
>  >  discussion *has* been beaten to death. 3 should be an option, and it
>  >  is an option, if u'' gets supported.
>  >
>  >
>  >  --
>  >  Lennart Regebro: Zope and Plone consulting.
>  >  http://www.colliberty.com/
>  >  +33 661 58 14 64
>  >  _______________________________________________
>  >
>  >
>  > Python-3000 mailing list
>  >  Python-3000 at python.org
>  >  http://mail.python.org/mailman/listinfo/python-3000
>  >  Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>  >
>

From regebro at gmail.com  Thu Mar 20 16:57:05 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 16:57:05 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<47E2700E.3050700@v.loewis.de>
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
Message-ID: <319e029f0803200857wff6ab7dp5e064456712dacbc@mail.gmail.com>

On Thu, Mar 20, 2008 at 3:20 PM, Ralf Schmitt <schmir at gmail.com> wrote:
> Will python 2.6 have something like "from future import
> unicode_string_literals" ?
> This should also solve lennart's problem. (But then py3k would need to
> support that future import, which
>  is forbidden).

A try/except around that future import solves that, so that isn't any
problem. Indeed, this would solve the problem without changing 3.0, it
would instead be a change in 2.6. Sounds good to me.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Thu Mar 20 17:27:25 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 11:27:25 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E251CF.2050104@v.loewis.de>	
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	
	<47E255B8.9080007@v.loewis.de>	
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	
	<47E2700E.3050700@v.loewis.de>
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
Message-ID: <47E2906D.3090201@v.loewis.de>

> Will python 2.6 have something like "from future import 
> unicode_string_literals" ?

It was proposed before, I don't know whether any implementation
on that has started.

> This should also solve lennart's problem. (But then py3k would need to 
> support that future import, which
> is forbidden).

Right. Of course, just removing a __future__ import is simpler than
editing all the string literals.

Regards,
Martin

From regebro at gmail.com  Thu Mar 20 17:28:28 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 17:28:28 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
Message-ID: <319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>

On Thu, Mar 20, 2008 at 4:40 PM, Charles Merriam
<charles.merriam at gmail.com> wrote:
>  The problem is not the gratuitous removal of the leading 'u', but the
>  subtle problems when
>  the code looks nearly identical.  The most likely one to cause
>  problems is the new semantics
>  of the keys operations.   While I haven't read the 3.0 code, this is
>  what was stated at Guido's
>  last talk.

No, the problem is the lack of u'' support. I've tried. :)

The new semantics of the keys operation means that keys() will work
like iterkeys() works now. This is not a problem unless you try to use
the result of keys() as a list, which isn't commonly done. Those types
of problems is however completely unavoidable in any case, 2to3 won't
solve them either, as I understand it.

I like your t"Hello" literal, it's prettier than the standard
_("Hello") binding, and this is a parallell case to the u("Hello")
binding I mentioned before as a partial workaround for the unicode
problem. Perhaps something to think about for 3.1?

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From regebro at gmail.com  Thu Mar 20 17:31:16 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 17:31:16 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2906D.3090201@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<47E2700E.3050700@v.loewis.de>
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
	<47E2906D.3090201@v.loewis.de>
Message-ID: <319e029f0803200931x11982acer647faf3eac55f374@mail.gmail.com>

On Thu, Mar 20, 2008 at 5:27 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Will python 2.6 have something like "from future import
>  > unicode_string_literals" ?
>
>  It was proposed before, I don't know whether any implementation
>  on that has started.
>
>
>  > This should also solve lennart's problem. (But then py3k would need to
>  > support that future import, which
>  > is forbidden).
>
>  Right. Of course, just removing a __future__ import is simpler than
>  editing all the string literals.

Also, if it doesn't come into 2.6, it can always appear in a 2.7.
While u'' support rather is something you'd want to *remove* from a
3.1, not add. Yes, this is a better solution. I'm now lobbying for
"from __future__ import unicode_string_literals" instead. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From thomas at python.org  Thu Mar 20 17:50:26 2008
From: thomas at python.org (Thomas Wouters)
Date: Thu, 20 Mar 2008 09:50:26 -0700
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
Message-ID: <9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>

On Thu, Mar 20, 2008 at 9:28 AM, Lennart Regebro <regebro at gmail.com> wrote:

> On Thu, Mar 20, 2008 at 4:40 PM, Charles Merriam
> <charles.merriam at gmail.com> wrote:
> >  The problem is not the gratuitous removal of the leading 'u', but the
> >  subtle problems when
> >  the code looks nearly identical.  The most likely one to cause
> >  problems is the new semantics
> >  of the keys operations.   While I haven't read the 3.0 code, this is
> >  what was stated at Guido's
> >  last talk.
>
> No, the problem is the lack of u'' support. I've tried. :)
>

That may be the case now, and with that particular code. It's still very
fragile to *count* on this being true. Python 3.0 should not and must not
have backward compatibility cruft. It defeats the whole point of 3.0 and
devalues it to the point of uselessness. It's just plain silly to discuss
it.

What can be done is adding a future statement to 2.6 to make '' be identical
to u'': 'from __future__ import unicode_strings' or such, but it doesn't
remove the need to use 2to3. Really, use 2to3.


> The new semantics of the keys operation means that keys() will work
> like iterkeys() works now. This is not a problem unless you try to use
> the result of keys() as a list, which isn't commonly done. Those types
> of problems is however completely unavoidable in any case, 2to3 won't
> solve them either, as I understand it.
>

It'll do a much better job than try-and-pray. It may not matter in any of
your code, but I really suggest not relying on it. Use 2to3.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/deb8ef43/attachment-0001.htm 

From regebro at gmail.com  Thu Mar 20 17:55:59 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 17:55:59 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
Message-ID: <319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>

On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <thomas at python.org> wrote:
> It'll do a much better job than try-and-pray. It may not matter in any of
> your code, but I really suggest not relying on it. Use 2to3.

This is not a case of try and pray, and 2to3 is not a realistic option.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Thu Mar 20 19:02:03 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 13:02:03 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E23C60.6030306@gmail.com>	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
Message-ID: <47E2A69B.9080509@v.loewis.de>

Lennart Regebro schrieb:
> On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <thomas at python.org> wrote:
>> It'll do a much better job than try-and-pray. It may not matter in any of
>> your code, but I really suggest not relying on it. Use 2to3.
> 
> This is not a case of try and pray, and 2to3 is not a realistic option.

Can you please try to explain with more words why it is not a
"realistic option"? I still don't get it.

Regards,
Martin

From eric+python-dev at trueblade.com  Thu Mar 20 19:11:13 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 20 Mar 2008 14:11:13 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2906D.3090201@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>		<47E251CF.2050104@v.loewis.de>		<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>		<47E255B8.9080007@v.loewis.de>		<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>		<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
	<47E2906D.3090201@v.loewis.de>
Message-ID: <47E2A8C1.9060906@trueblade.com>

Martin v. L?wis wrote:
>> Will python 2.6 have something like "from future import 
>> unicode_string_literals" ?
> 
> It was proposed before, I don't know whether any implementation
> on that has started.

I don't see anything in the bug tracker.  I'd be willing to look at it, 
if this is what we want to do.

>> This should also solve lennart's problem. (But then py3k would need to 
>> support that future import, which
>> is forbidden).
> 
> Right. Of course, just removing a __future__ import is simpler than
> editing all the string literals.

py3k supports future imports.  For example, "from __future__ import 
with_statement" works, and I presume it's a no-op.  I did not forward 
port print_function, but maybe I should?

Eric.


From lists at cheimes.de  Thu Mar 20 20:10:41 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 20:10:41 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2A8C1.9060906@trueblade.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>		<47E251CF.2050104@v.loewis.de>		<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>		<47E255B8.9080007@v.loewis.de>		<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>		<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	<47E2906D.3090201@v.loewis.de>
	<47E2A8C1.9060906@trueblade.com>
Message-ID: <47E2B6B1.1010208@cheimes.de>

Eric Smith schrieb:
> py3k supports future imports.  For example, "from __future__ import 
> with_statement" works, and I presume it's a no-op.  I did not forward 
> port print_function, but maybe I should?

Python 3.0 must accept all future imports that are available in the 2.x 
series although they are no-ops. from __future__ import feature has to 
work even if the feature is already available by default.

Christian

From thomas at python.org  Thu Mar 20 20:09:32 2008
From: thomas at python.org (Thomas Wouters)
Date: Thu, 20 Mar 2008 12:09:32 -0700
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2B6B1.1010208@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<47E2700E.3050700@v.loewis.de>
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
	<47E2906D.3090201@v.loewis.de> <47E2A8C1.9060906@trueblade.com>
	<47E2B6B1.1010208@cheimes.de>
Message-ID: <9e804ac0803201209y6d284555y85769d7f2a6faee8@mail.gmail.com>

On Thu, Mar 20, 2008 at 12:10 PM, Christian Heimes <lists at cheimes.de> wrote:

> Eric Smith schrieb:
> > py3k supports future imports.  For example, "from __future__ import
> > with_statement" works, and I presume it's a no-op.  I did not forward
> > port print_function, but maybe I should?
>
> Python 3.0 must accept all future imports that are available in the 2.x
> series although they are no-ops. from __future__ import feature has to
> work even if the feature is already available by default.


This surprises me greatly. The reason this is true in 2.x is for the obvious
backward compatibility. 3.0 is about not worrying about backward
compatibility. Why do we need to keep the future imports?

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/0b39c0fa/attachment.htm 

From lists at cheimes.de  Thu Mar 20 20:21:37 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 20:21:37 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <9e804ac0803201209y6d284555y85769d7f2a6faee8@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E251CF.2050104@v.loewis.de>	
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	
	<47E255B8.9080007@v.loewis.de>	
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	
	<47E2700E.3050700@v.loewis.de>	
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	
	<47E2906D.3090201@v.loewis.de>
	<47E2A8C1.9060906@trueblade.com>	 <47E2B6B1.1010208@cheimes.de>
	<9e804ac0803201209y6d284555y85769d7f2a6faee8@mail.gmail.com>
Message-ID: <47E2B941.4080700@cheimes.de>

Thomas Wouters schrieb:
  > This surprises me greatly. The reason this is true in 2.x is for the 
obvious
> backward compatibility. 3.0 is about not worrying about backward
> compatibility. Why do we need to keep the future imports?
> 

The __future__ docs say "No feature description will ever be deleted 
from __future__."

ever is a very strong word and I expect Python 3.x to follow the rule.

Christian

From eric+python-dev at trueblade.com  Thu Mar 20 20:19:10 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 20 Mar 2008 15:19:10 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2B941.4080700@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E251CF.2050104@v.loewis.de>	
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	
	<47E255B8.9080007@v.loewis.de>	
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	
	<47E2700E.3050700@v.loewis.de>	
	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	
	<47E2906D.3090201@v.loewis.de>
	<47E2A8C1.9060906@trueblade.com>	 <47E2B6B1.1010208@cheimes.de>
	<9e804ac0803201209y6d284555y85769d7f2a6faee8@mail.gmail.com>
	<47E2B941.4080700@cheimes.de>
Message-ID: <47E2B8AE.9080407@trueblade.com>

Christian Heimes wrote:
> Thomas Wouters schrieb:
>  > This surprises me greatly. The reason this is true in 2.x is for the 
> obvious
>> backward compatibility. 3.0 is about not worrying about backward
>> compatibility. Why do we need to keep the future imports?
>>
> 
> The __future__ docs say "No feature description will ever be deleted 
> from __future__."
> 
> ever is a very strong word and I expect Python 3.x to follow the rule.
> 
> Christian
> 

Okay.  I'll add it to py3k.


From barry at python.org  Thu Mar 20 20:42:22 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 20 Mar 2008 14:42:22 -0500
Subject: [Python-3000] Python source code on Bazaar vcs
Message-ID: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm happy to announce that we now have available for public  
consumption, the Python source code for 2.5, 2.6 and 3.0 available  
under the Bazaar distributed version control system.

The current Subversion repository is still the master copy of the  
source code.  We have not made a decision to move to Bazaar  
officially, nor have we made a decision to even move off of  
Subversion.  We're making these branches available exactly so that  
you, the Python developer community, can kick the tires and see if it  
makes sense to move to a different vcs.  Nothing will happen until  
after the Python 2.6/3.0 releases anyway.

All the gory details are documented here:

     http://www.python.org/dev/bazaar

These branches are available both for core Python developers with  
commit privileges, and the wider world of developers without commit  
privileges.  It's this latter group that I think will find the most  
compelling immediate benefit from using Bazaar, because they will no  
longer need to maintain their own changes using a mass of patch files.

For more information on Bazaar in general, see:

     http://bazaar-vcs.org

You will probably be most interested in the Bazaar mirrors of the  
Subversion master repository.  We have a cron job that updates Bazaar  
from Subversion every 15 minutes.  It is also possible to push changes  
made in your Bazaar branches into the Subversion master, so you can  
keep reasonably up-to-date and interact with the Python source code  
solely via Bazaar.

Please let me know if you have any questions or anything in the docs  
referenced above aren't clear.  I know I need to document the Bazaar- 
 >Subversion workflow in more detail.

Huge thanks go out especially to Thomas Wouters who sprinted with me  
yesterday on getting the whole infrastructure up and running.  Thanks  
also to Martin v. Loewis, Sean Reifschneider, and the folks here at  
Pycon from the Bazaar project, Ian, Andrew, John, and Edwin.

Enjoy,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+K+H3EjvBPtnXfVAQL6bwP/d0XKx0mRPgzdOD6zCPwwRl8y2kxWV9Vl
zVwN07cK8IlwMa9M470MsERuXuD8hmeXnPgnrUcrX9HciwldmY8C33t0f8GaOk1J
iD4Od1midlIaJJiMd+JcFk9NbX3Rwc4HMj3s8jKjjdlGrFe77ei9DCZ/HMl/iG5K
fyyjXo4HLEE=
=Gcjq
-----END PGP SIGNATURE-----

From regebro at gmail.com  Thu Mar 20 20:51:04 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 20:51:04 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2A69B.9080509@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
Message-ID: <319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>

On Thu, Mar 20, 2008 at 7:02 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Lennart Regebro schrieb:
>
> > On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <thomas at python.org> wrote:
>  >> It'll do a much better job than try-and-pray. It may not matter in any of
>  >> your code, but I really suggest not relying on it. Use 2to3.
>  >
>  > This is not a case of try and pray, and 2to3 is not a realistic option.
>
>  Can you please try to explain with more words why it is not a
>  "realistic option"? I still don't get it.

OK, I'll try:

The recommended path for porting Python code to Python 3.0 is to use a
tool called 2to3 to convert the code from Python 2.x code to 3.x code.
If you need to support both 2.x and 3.0, you should maintain the code
as 2.x code, and convert it to 3.x code and test it before you make a
new release, and then make two separate releases, one for 2.x and one
for 3.0.

That use case works for when you have code that is maintained by a
small set of maintainers and regularly released to a large set of
users who do not have access to the code repository. That is an ideal
situation that isn't always fulfilled, and is a strategy well
optimized for those who develop library type modules, but not for
others.

In many other cases, this is not how code is developed. Both within
larger organisations and within large communities like Zope and Plone
(and I suspect the same is true for communities such as Turbogears and
Django), many people are instead working on the same code base at the
same time.

So, there are many people working on the same large set of modules.
All are using direct svn checkouts, because during development of
their product/site they need a module and they discover bugs or add
features to this module. They also have wildly varying experience
levels and python knowledge.

Either all of these people and modules need to switch to 3.0 at the
same time, which is unrealistic, or some will run 2.6 and some will
run 3.0, and that means that the modules need to support both 2.6 and
3.0. The 2to3 strategy in that case means that everybody that wants to
go over to 3.0 needs to have two complete development environments for
every instance of the software that they need. Basically, for every
website they develop, they would need one instance that runs under 2.6
and one under 3.0. This even though most of the code developed only
would run under 3.0 or 2.6, as it's custom for that particular
website. The developer would then have to check out the 2.6 code in
the 2.6 site, change it there, and test the change, and then run 2to3
copying over the code to the 3.0 instance, and test it there.
Basically, any sort of code change, no matter how minor, requires a
"change -> test -> copy -> 2to3 -> test" dance, instead of the normal
"change -> test". This doubles the effort of making any change. And
since testing on the web often means testing with some sort of browser
(zope.testbrowser or Selenium or the like) this means restarting a
webserver before running the tests. Running tests this was often takes
a significant time.

The end result of this is that people will not move to Python 3 as
long as they need any sort of third-party product from the Plone
collective or similar set of modules, because it is going to be too
much work. So everybody will stay on 2.x. Which means there is no
incentive to port the third-party products to 3.0. It becomes a
chicken and egg, or a catch 22 problem.

In the best case this means that Python 3 dies and nobody uses it.
Yes, that is the best case. It's a horrible case, I agree. But the
worst case is that the community splits in two, and that will be
dangerous for Python as a whole. Python may survive being split into
two communities, but it would be negative for the community as a
whole. Zope had this problem with Zope 2 and Zope 3.

So therefore, having so much forwards compatibility in Python 2.6 that
we can run a reasonable set of Python code in both 2.6 and 3.0 would
be a Very Good Thing. Because that enables us to either make a clean
break by running 2to3 once, and dropping 2,x support, or supporting
both by writing compatible code (which is a bit of extra effort and
will not perhaps not always work) and supporting both by writing 2.6
code and using 2to3 to support 3.0, which is a lot of extra effort,
but will work in almost all cases.

Now, before we all get into doomsday mode, there is good news. First
of all, 2.6a1 already contains a lot of forwards compatibility. And
with the "from __future__ import print_function", which adds more such
compatibility. The horrible complete compatibility break that we were
so worried about might never happen. All that is needed is pretty much
a from __future__ import unicode_string_literals, and  far as I'm
concerned we are all set.

And, if we are not, then there is no reason why even more forwards
compatibility couldn't be added to a 2.7, if it turns out to be
needed. If however people do move over to 3.0 quickly, or to a 2.6/3.0
compatible hybrid, then no more 2.7 additions will be needed.

I hope this clarifies things.
-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From lists at cheimes.de  Thu Mar 20 21:15:38 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 21:15:38 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E23C60.6030306@gmail.com>	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
Message-ID: <47E2C5EA.7090905@cheimes.de>

Lennart Regebro schrieb:
> Now, before we all get into doomsday mode, there is good news. First
> of all, 2.6a1 already contains a lot of forwards compatibility. And
> with the "from __future__ import print_function", which adds more such
> compatibility. The horrible complete compatibility break that we were
> so worried about might never happen. All that is needed is pretty much
> a from __future__ import unicode_string_literals, and  far as I'm
> concerned we are all set.


How about "from __future__ import py3k_literals" for Python 2.6? The 
future statement turns several literals into Python 3.0 mode:

* '' creates an unicode object instead of a str object
* b'' creates a str object (aka bytes in Python 3.0)
* 1 creates a long instead of an int
* 1L and u'' are invalid

Christian

From martin at v.loewis.de  Thu Mar 20 21:18:35 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 15:18:35 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2A8C1.9060906@trueblade.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>		<47E251CF.2050104@v.loewis.de>		<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>		<47E255B8.9080007@v.loewis.de>		<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>		<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>
	<47E2906D.3090201@v.loewis.de> <47E2A8C1.9060906@trueblade.com>
Message-ID: <47E2C69B.2080200@v.loewis.de>

>> It was proposed before, I don't know whether any implementation
>> on that has started.
> 
> I don't see anything in the bug tracker.  I'd be willing to look at it, 
> if this is what we want to do.

Neither could I. I vaguely remember having people mention it, but
could not find anything, either. Perhaps you need to get
approval/agreement first in a separate thread.

>> Right. Of course, just removing a __future__ import is simpler than
>> editing all the string literals.
> 
> py3k supports future imports.  

Yes, but it won't/shouldn't support the unicode_literals __future__
import (atleast not without BDFL pronouncement).

Regards,
Martin

From regebro at gmail.com  Thu Mar 20 21:22:40 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 21:22:40 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2C5EA.7090905@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<47E2C5EA.7090905@cheimes.de>
Message-ID: <319e029f0803201322j77bb38d0va57afe86a851db78@mail.gmail.com>

On Thu, Mar 20, 2008 at 9:15 PM, Christian Heimes <lists at cheimes.de> wrote:
>  How about "from __future__ import py3k_literals" for Python 2.6? The
>  future statement turns several literals into Python 3.0 mode:
>
>  * '' creates an unicode object instead of a str object

That would be fantastic indeed.

>  * b'' creates a str object (aka bytes in Python 3.0)

It already does that, as b'' doesn't clash with any python 2 literal,
so that's already fixed.

>  * 1 creates a long instead of an int

I haven't come up with any case where you need to know if it is a int
or a long, except if you are stripping out the L from a repr. So I
don't think it's necessary. But maybe it could be helpful?

>  * 1L and u'' are invalid

That could be good, but deprecation warnings in -3 mode is enough, IMO.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Thu Mar 20 21:29:24 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 15:29:24 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E23C60.6030306@gmail.com>	
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
Message-ID: <47E2C924.5080103@v.loewis.de>

> The recommended path for porting Python code to Python 3.0 is to use a
> tool called 2to3 to convert the code from Python 2.x code to 3.x code.

Correct.

> If you need to support both 2.x and 3.0, you should maintain the code
> as 2.x code, and convert it to 3.x code and test it before you make a
> new release, and then make two separate releases, one for 2.x and one
> for 3.0.

You don't necessarily need two separate releases. You could make asingle 
source release, and have 2to3 run on the user's machines at installation
time.

> So, there are many people working on the same large set of modules.
> All are using direct svn checkouts, because during development of
> their product/site they need a module and they discover bugs or add
> features to this module. They also have wildly varying experience
> levels and python knowledge.

In such an environment, you could run 2to3 even at import time,
as somebody proposed.

> Basically, any sort of code change, no matter how minor, requires a
> "change -> test -> copy -> 2to3 -> test" dance, instead of the normal
> "change -> test".

For the development cycle, it could remain change-test, if the test
runner would do the 2to3 conversion first.

> The end result of this is that people will not move to Python 3 as
> long as they need any sort of third-party product from the Plone
> collective or similar set of modules, because it is going to be too
> much work. So everybody will stay on 2.x. Which means there is no
> incentive to port the third-party products to 3.0. It becomes a
> chicken and egg, or a catch 22 problem.

I think this problem is highly theoretical. Even if no end-user
application is ported to 3.0 within the first year, still: by
the time 3.2 is released, all major library packages will be
available.

> In the best case this means that Python 3 dies and nobody uses it.
> Yes, that is the best case. It's a horrible case, I agree. But the
> worst case is that the community splits in two, and that will be
> dangerous for Python as a whole. Python may survive being split into
> two communities, but it would be negative for the community as a
> whole. Zope had this problem with Zope 2 and Zope 3.

Again, I think these are unfounded fears.

> I hope this clarifies things.

It does, thanks. I still think you can use 2to3 in all the cases
you've described.

Regards,
Martin

From lists at cheimes.de  Thu Mar 20 21:35:54 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 21:35:54 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201322j77bb38d0va57afe86a851db78@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E23C60.6030306@gmail.com>	
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	
	<47E2A69B.9080509@v.loewis.de>	
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	
	<47E2C5EA.7090905@cheimes.de>
	<319e029f0803201322j77bb38d0va57afe86a851db78@mail.gmail.com>
Message-ID: <47E2CAAA.9070501@cheimes.de>

Lennart Regebro schrieb:
>>  * b'' creates a str object (aka bytes in Python 3.0)
> 
> It already does that, as b'' doesn't clash with any python 2 literal,
> so that's already fixed.

I know, I've implemented the feature myself about two months ago. I 
wanted to emphasis on the fact that b'' creates a str object in 2.6 and 
a bytes object in 3.0.

>>  * 1 creates a long instead of an int
> 
> I haven't come up with any case where you need to know if it is a int
> or a long, except if you are stripping out the L from a repr. So I
> don't think it's necessary. But maybe it could be helpful?

I think it's an reasonable approach to change *all* literals to be 100% 
Python 3.0 compatible. In this particular case I'm for the everything or 
nothing approach.

>>  * 1L and u'' are invalid
> 
> That could be good, but deprecation warnings in -3 mode is enough, IMO.

When the user specifies the py3k_literal mode than 1L and u'' should 
raise a SyntaxError. I'm -0 for no error and -1 for a deprecation 
warning with -3. It'd clutter the parser and tokenizer code even more. 
The warning isn't required, too.

Christian

From regebro at gmail.com  Thu Mar 20 21:40:15 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 21:40:15 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2C924.5080103@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<47E2C924.5080103@v.loewis.de>
Message-ID: <319e029f0803201340w3b0aac65lf6de67db4f7a247f@mail.gmail.com>

On Thu, Mar 20, 2008 at 9:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  In such an environment, you could run 2to3 even at import time,
>  as somebody proposed.

That is even less realistic, to be honest. And many of these modules
are not installed, so there there is no install time. That might
change, the community is moving towards eggs, but we are not there
yet.

>  For the development cycle, it could remain change-test, if the test
>  runner would do the 2to3 conversion first.

Why/how would it? How would it know what to run 2to3 on?

>  I think this problem is highly theoretical.

No, this is a highly practical problem. The practicality of running
2to3 on various magical ways is highly theoretical. I described how
the world looks, now. That is not theory.

> Even if no end-user
>  application is ported to 3.0 within the first year, still: by
>  the time 3.2 is released, all major library packages will be
>  available.

Library packages is, as mentioned, not the problem here.

>  It does, thanks. I still think you can use 2to3 in all the cases
>  you've described.

Then I didn't make myself clear.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From regebro at gmail.com  Thu Mar 20 21:42:47 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 21:42:47 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2CAAA.9070501@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<47E2C5EA.7090905@cheimes.de>
	<319e029f0803201322j77bb38d0va57afe86a851db78@mail.gmail.com>
	<47E2CAAA.9070501@cheimes.de>
Message-ID: <319e029f0803201342h74bd5fcemba1404ba8229cab@mail.gmail.com>

On Thu, Mar 20, 2008 at 9:35 PM, Christian Heimes <lists at cheimes.de> wrote:
>  I think it's an reasonable approach to change *all* literals to be 100%
>  Python 3.0 compatible.

Well, I'm sure not going to complain if that is the case. :)

>  When the user specifies the py3k_literal mode than 1L and u'' should
>  raise a SyntaxError. I'm -0 for no error and -1 for a deprecation
>  warning with -3. It'd clutter the parser and tokenizer code even more.
>  The warning isn't required, too.

OK, if the warning is more complicated than the SyntaxError, then
evidently the SyntaxError is better.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From lists at cheimes.de  Thu Mar 20 21:58:33 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 21:58:33 +0100
Subject: [Python-3000] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <47E2CFF9.6010400@cheimes.de>

Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public  
> consumption, the Python source code for 2.5, 2.6 and 3.0 available  
> under the Bazaar distributed version control system.

Thank you very much to Barry and the rest of team! Great work!

Ubuntu users have to install a newer version of bzr before they can 
check out the sources:

sudo vi /etc/apt/sources.list.d/bzr.list
--- add ---
deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
--- eof ---

sudo apt-get update

#  --force-yes because the packages aren't signed yet
sudo apt-get --force-yes -y install bzr bzr-gtk bzrtools


Also read https://launchpad.net/~bzr/+archive and 
http://bazaar-vcs.org/DistroDownloads

Christian

From barry at python.org  Thu Mar 20 21:59:40 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 20 Mar 2008 15:59:40 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
Message-ID: <A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 20, 2008, at 2:48 AM, Lennart Regebro wrote:

> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and  you would be able to
> choose between the three porting strategies dependningon how your code
> base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
> Supporting both 2.6 and 3.0.

I proposed what I think is a better solution.  Add

from __future__ import unicode_strings

to Py2.6.  That would let you write Py3k compatible strings (and of  
course byte literals) in 2.6.  It would essential treat 'foo' as  
u'foo' in the file with the future import.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+LQPXEjvBPtnXfVAQL1igP+LFAJyXhSs9qbW8dcOvRhvlAeSNGKdQ8h
pMP3QWXY1TlVNs+3UQF93neL+TSSc1AN1iOIg42VRQefBZPaOTnnbtYSWwyYXW4o
ITYpaXS8h5wwpvqXRawGGaIaeS/t1/xMEqfIHbhHeFyrbRbfk1JEn5aDSz3A7gIW
kwbYdNAaqGo=
=X4nr
-----END PGP SIGNATURE-----

From lists at cheimes.de  Thu Mar 20 22:18:33 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 22:18:33 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
Message-ID: <47E2D4A9.6050204@cheimes.de>

Barry Warsaw schrieb:
> I proposed what I think is a better solution.  Add
> 
> from __future__ import unicode_strings
> 
> to Py2.6.  That would let you write Py3k compatible strings (and of  
> course byte literals) in 2.6.  It would essential treat 'foo' as  
> u'foo' in the file with the future import.

I proposed a similar solution an hour ago: from __future__ import 
py3k_literals

It's in my answer to Lennarts' posting written at 21:15 local time.

Christian

From lists at cheimes.de  Thu Mar 20 22:19:55 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 22:19:55 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201342h74bd5fcemba1404ba8229cab@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	<47E2A69B.9080509@v.loewis.de>	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	<47E2C5EA.7090905@cheimes.de>	<319e029f0803201322j77bb38d0va57afe86a851db78@mail.gmail.com>	<47E2CAAA.9070501@cheimes.de>
	<319e029f0803201342h74bd5fcemba1404ba8229cab@mail.gmail.com>
Message-ID: <47E2D4FB.7030401@cheimes.de>

Lennart Regebro schrieb:
> On Thu, Mar 20, 2008 at 9:35 PM, Christian Heimes <lists at cheimes.de> wrote:
>>  I think it's an reasonable approach to change *all* literals to be 100%
>>  Python 3.0 compatible.
> 
> Well, I'm sure not going to complain if that is the case. :)

It's just a proposal. We've to wait and see how Guido likes it.

Christian

From barry at python.org  Thu Mar 20 22:15:03 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 20 Mar 2008 16:15:03 -0500
Subject: [Python-3000] Python source code on Bazaar vcs
In-Reply-To: <47E2CFF9.6010400@cheimes.de>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<47E2CFF9.6010400@cheimes.de>
Message-ID: <A74E086A-0E9A-435F-AF55-0162F5CB2020@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 20, 2008, at 3:58 PM, Christian Heimes wrote:

> Barry Warsaw schrieb:
>> I'm happy to announce that we now have available for public   
>> consumption, the Python source code for 2.5, 2.6 and 3.0 available   
>> under the Bazaar distributed version control system.
>
> Thank you very much to Barry and the rest of team! Great work!
>
> Ubuntu users have to install a newer version of bzr before they can  
> check out the sources:
>
> sudo vi /etc/apt/sources.list.d/bzr.list
> --- add ---
> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
> --- eof ---
>
> sudo apt-get update
>
> #  --force-yes because the packages aren't signed yet
> sudo apt-get --force-yes -y install bzr bzr-gtk bzrtools
>
>
> Also read https://launchpad.net/~bzr/+archive and http://bazaar-vcs.org/DistroDownloads

Thanks Christian, I'll add this to the page.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+LT2nEjvBPtnXfVAQJ+aAP+JNqjnGdgfqszSGDn8dtBppaxf4d486DD
5GLdPUn696nHw0Q2+OzqFbTk8s/qNDyNmVoLuG80TsyrhqMJTidIwyupjxFXvdfI
gk/7Ghl1/ky5QEBXfmE0xrql+uoEmoVD+OVxlrzYy8Z9rm22y0EAUN2BOyM9oLYq
TsSj2XJSdVM=
=XJlg
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Thu Mar 20 22:25:21 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 Mar 2008 16:25:21 -0500
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201340w3b0aac65lf6de67db4f7a247f@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<47E23C60.6030306@gmail.com>	
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	
	<47E2A69B.9080509@v.loewis.de>	
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	
	<47E2C924.5080103@v.loewis.de>
	<319e029f0803201340w3b0aac65lf6de67db4f7a247f@mail.gmail.com>
Message-ID: <47E2D641.7020103@v.loewis.de>

>>  For the development cycle, it could remain change-test, if the test
>>  runner would do the 2to3 conversion first.
> 
> Why/how would it? How would it know what to run 2to3 on?

There could be a 3k copy created by the test suite, which it
updates based on the time stamps of the 2.x sources.

>>  I think this problem is highly theoretical.
> 
> No, this is a highly practical problem. The practicality of running
> 2to3 on various magical ways is highly theoretical. I described how
> the world looks, now. That is not theory.

You have been describing a chicken-and-egg problem that might
occur *after* 3.0 is released. This is not what the world looks
today: today's world does not have 3.0.

Speculating that users will reject 3.0 if they have to run 2to3
is, well, speculation (and so is that they will adopt 3.0 despite
having nothing but 2to3).

Regards,
Martin

From schmir at gmail.com  Thu Mar 20 22:26:22 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 20 Mar 2008 22:26:22 +0100
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <932f8baf0803201426ua0ae2edu3f7b62eaf22ef787@mail.gmail.com>

On Thu, Mar 20, 2008 at 8:42 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
>

I have also setup a mirror using mercurial: http://hgpy.de/py/
It contains the 2.4, 2.5, trunk and py3k branches (in case anyone wants to
compare this to bzr).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/b1a383a9/attachment.htm 

From lists at cheimes.de  Thu Mar 20 22:49:35 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 22:49:35 +0100
Subject: [Python-3000] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <47E2DBEF.8010809@cheimes.de>

Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.

Somebody has to fix the subversion related code in Python/sysmodule.c:

heimes at hamiller:~/dev/python/bzr/trunk$ ./python
Fatal Python error: subversion keywords missing
Aborted (core dumped)

Christian

From walter at livinglogic.de  Thu Mar 20 23:20:20 2008
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 20 Mar 2008 23:20:20 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2D4A9.6050204@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
	<47E2D4A9.6050204@cheimes.de>
Message-ID: <47E2E324.5000208@livinglogic.de>

Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I proposed what I think is a better solution.  Add
>>
>> from __future__ import unicode_strings
>>
>> to Py2.6.  That would let you write Py3k compatible strings (and of  
>> course byte literals) in 2.6.  It would essential treat 'foo' as  
>> u'foo' in the file with the future import.
> 
> I proposed a similar solution an hour ago: from __future__ import 
> py3k_literals
> 
> It's in my answer to Lennarts' posting written at 21:15 local time.

Isn't the super secret -U option most of what we need?

./python.exe -U
Python 2.6a1+ (trunk:61276M, Mar  6 2008, 12:06:38)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> type('foo')
<type 'unicode'>
 >>>


A future import would only affect one module though, -U is global.

Servus,
    Walter

From lists at cheimes.de  Thu Mar 20 23:49:42 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 20 Mar 2008 23:49:42 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2E324.5000208@livinglogic.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
	<47E2D4A9.6050204@cheimes.de> <47E2E324.5000208@livinglogic.de>
Message-ID: <47E2EA06.1070007@cheimes.de>

Walter D?rwald schrieb:
> Isn't the super secret -U option most of what we need?

Yeah, it's really super secret. Neither me nor python --help knows about
it. :)

Christian

From regebro at gmail.com  Thu Mar 20 23:45:41 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 20 Mar 2008 23:45:41 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2E324.5000208@livinglogic.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
	<47E2D4A9.6050204@cheimes.de> <47E2E324.5000208@livinglogic.de>
Message-ID: <319e029f0803201545y7031b952j2e1f6c6fbc649a07@mail.gmail.com>

On Thu, Mar 20, 2008 at 11:20 PM, Walter D?rwald <walter at livinglogic.de> wrote:
>  A future import would only affect one module though, -U is global.

Yeah, I don't think -U would work because of that. That would again
mean you need to switch all code at the same time.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From phd at phd.pp.ru  Thu Mar 20 23:48:25 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Fri, 21 Mar 2008 01:48:25 +0300
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2EA06.1070007@cheimes.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<A058B71A-0C56-488F-9788-69C9733C4EA7@python.org>
	<47E2D4A9.6050204@cheimes.de> <47E2E324.5000208@livinglogic.de>
	<47E2EA06.1070007@cheimes.de>
Message-ID: <20080320224825.GA23955@phd.pp.ru>

On Thu, Mar 20, 2008 at 11:49:42PM +0100, Christian Heimes wrote:
> Walter D?rwald schrieb:
> > Isn't the super secret -U option most of what we need?
> 
> Yeah, it's really super secret. Neither me nor python --help knows about
> it. :)

   Neither "man python". I knew the option, but forgot about it.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From greg.ewing at canterbury.ac.nz  Thu Mar 20 23:51:02 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 21 Mar 2008 10:51:02 +1200
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2700E.3050700@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E251CF.2050104@v.loewis.de>
	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>
	<47E255B8.9080007@v.loewis.de>
	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>
	<47E2700E.3050700@v.loewis.de>
Message-ID: <47E2EA56.2030406@canterbury.ac.nz>

Would it help if 2.6 had a __future__ import to treat
all unadorned string literals as unicode?

-- 
Greg

From eric+python-dev at trueblade.com  Fri Mar 21 01:55:17 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 20 Mar 2008 20:55:17 -0400
Subject: [Python-3000] [Python-3000-checkins] r61682 - in
 python/branches/py3k:	Include/code.h Include/compile.h
 Lib/__future__.py	Lib/test/test_print.py Python/future.c
In-Reply-To: <ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>
References: <20080320230233.A46231E4018@bag.python.org>
	<ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>
Message-ID: <47E30775.9030407@trueblade.com>

Guido van Rossum wrote:
> Really? I though 2to3 was supposed to remove all __future__ imports?

I was convinced when Christian pointed out the statement in 
http://docs.python.org/lib/module-future.html:
"No feature description will ever be deleted from __future__."

Admittedly, I implemented more than the minimum required for that, but 
since the other future statements (absolute_import, with_statement, 
etc.) were in py3k, I figured it would make sense to have print_function 
behave the same way.  Then, if we want to remove all __future__ imports 
from py3k, it's more obvious (to me, anyway) how to extract them all.

> 
> On Thu, Mar 20, 2008 at 4:02 PM, eric.smith
> <python-3000-checkins at python.org> wrote:
>> Author: eric.smith
>>  Date: Fri Mar 21 00:02:08 2008
>>  New Revision: 61682
>>
>>  Modified:
>>    python/branches/py3k/Include/code.h
>>    python/branches/py3k/Include/compile.h
>>    python/branches/py3k/Lib/__future__.py
>>    python/branches/py3k/Lib/test/test_print.py
>>    python/branches/py3k/Python/future.c
>>  Log:
>>  Add __future__ import for print_function.  It's a no-op in 3.0, but it needs to not be a syntax error.
>>  Closes issue 2436.
>>
>>  Modified: python/branches/py3k/Include/code.h
>>  ==============================================================================
>>  --- python/branches/py3k/Include/code.h (original)
>>  +++ python/branches/py3k/Include/code.h Fri Mar 21 00:02:08 2008
>>  @@ -48,6 +48,7 @@
>>   #define CO_FUTURE_DIVISION     0x2000
>>   #define CO_FUTURE_ABSOLUTE_IMPORT 0x4000 /* do absolute imports by default */
>>   #define CO_FUTURE_WITH_STATEMENT  0x8000
>>  +#define CO_FUTURE_PRINT_FUNCTION  0x10000
>>   #endif
>>
>>   /* This should be defined if a future statement modifies the syntax.
>>
>>  Modified: python/branches/py3k/Include/compile.h
>>  ==============================================================================
>>  --- python/branches/py3k/Include/compile.h      (original)
>>  +++ python/branches/py3k/Include/compile.h      Fri Mar 21 00:02:08 2008
>>  @@ -24,6 +24,7 @@
>>   #define FUTURE_DIVISION "division"
>>   #define FUTURE_ABSOLUTE_IMPORT "absolute_import"
>>   #define FUTURE_WITH_STATEMENT "with_statement"
>>  +#define FUTURE_PRINT_FUNCTION "print_function"
>>
>>   struct _mod; /* Declare the existence of this type */
>>   PyAPI_FUNC(PyCodeObject *) PyAST_Compile(struct _mod *, const char *,
>>
>>  Modified: python/branches/py3k/Lib/__future__.py
>>  ==============================================================================
>>  --- python/branches/py3k/Lib/__future__.py      (original)
>>  +++ python/branches/py3k/Lib/__future__.py      Fri Mar 21 00:02:08 2008
>>  @@ -53,6 +53,7 @@
>>      "division",
>>      "absolute_import",
>>      "with_statement",
>>  +    "print_function",
>>   ]
>>
>>   __all__ = ["all_feature_names"] + all_feature_names
>>  @@ -66,6 +67,7 @@
>>   CO_FUTURE_DIVISION   = 0x2000   # division
>>   CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default
>>   CO_FUTURE_WITH_STATEMENT  = 0x8000   # with statement
>>  +CO_FUTURE_PRINT_FUNCTION  = 0x10000   # print function
>>
>>   class _Feature:
>>      def __init__(self, optionalRelease, mandatoryRelease, compiler_flag):
>>  @@ -114,3 +116,7 @@
>>   with_statement = _Feature((2, 5, 0, "alpha", 1),
>>                            (2, 6, 0, "alpha", 0),
>>                            CO_FUTURE_WITH_STATEMENT)
>>  +
>>  +print_function = _Feature((2, 6, 0, "alpha", 2),
>>  +                          (3, 0, 0, "alpha", 0),
>>  +                          CO_FUTURE_PRINT_FUNCTION)
>>
>>  Modified: python/branches/py3k/Lib/test/test_print.py
>>  ==============================================================================
>>  --- python/branches/py3k/Lib/test/test_print.py (original)
>>  +++ python/branches/py3k/Lib/test/test_print.py Fri Mar 21 00:02:08 2008
>>  @@ -1,6 +1,8 @@
>>   """Test correct operation of the print function.
>>   """
>>
>>  +from __future__ import print_function
>>  +
>>   import unittest
>>   from test import test_support
>>
>>  @@ -98,6 +100,11 @@
>>          x('*\n', (ClassWith__str__('*'),))
>>          x('abc 1\n', (ClassWith__str__('abc'), 1))
>>
>>  +#        # 2.x unicode tests
>>  +#        x(u'1 2\n', ('1', u'2'))
>>  +#        x(u'u\1234\n', (u'u\1234',))
>>  +#        x(u'  abc 1\n', (' ', ClassWith__str__(u'abc'), 1))
>>  +
>>          # errors
>>          self.assertRaises(TypeError, print, '', sep=3)
>>          self.assertRaises(TypeError, print, '', end=3)
>>
>>  Modified: python/branches/py3k/Python/future.c
>>  ==============================================================================
>>  --- python/branches/py3k/Python/future.c        (original)
>>  +++ python/branches/py3k/Python/future.c        Fri Mar 21 00:02:08 2008
>>  @@ -33,6 +33,8 @@
>>                         continue;
>>                 } else if (strcmp(feature, FUTURE_WITH_STATEMENT) == 0) {
>>                         continue;
>>  +               } else if (strcmp(feature, FUTURE_PRINT_FUNCTION) == 0) {
>>  +                       continue;
>>                 } else if (strcmp(feature, "braces") == 0) {
>>                         PyErr_SetString(PyExc_SyntaxError,
>>                                         "not a chance");
>>  _______________________________________________
>>  Python-3000-checkins mailing list
>>  Python-3000-checkins at python.org
>>  http://mail.python.org/mailman/listinfo/python-3000-checkins
>>
> 
> 
> 


From guido at python.org  Fri Mar 21 02:29:41 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 20 Mar 2008 18:29:41 -0700
Subject: [Python-3000] [Python-3000-checkins] r61682 - in
	python/branches/py3k: Include/code.h Include/compile.h
	Lib/__future__.py Lib/test/test_print.py Python/future.c
In-Reply-To: <47E30775.9030407@trueblade.com>
References: <20080320230233.A46231E4018@bag.python.org>
	<ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>
	<47E30775.9030407@trueblade.com>
Message-ID: <ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>

Cool, I can live with that. Are all current __future__ statements
still valid in 3.0?

On Thu, Mar 20, 2008 at 5:55 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
>  > Really? I though 2to3 was supposed to remove all __future__ imports?
>
>  I was convinced when Christian pointed out the statement in
>  http://docs.python.org/lib/module-future.html:
>  "No feature description will ever be deleted from __future__."
>
>  Admittedly, I implemented more than the minimum required for that, but
>  since the other future statements (absolute_import, with_statement,
>  etc.) were in py3k, I figured it would make sense to have print_function
>  behave the same way.  Then, if we want to remove all __future__ imports
>  from py3k, it's more obvious (to me, anyway) how to extract them all.
>
>
>
>  >
>  > On Thu, Mar 20, 2008 at 4:02 PM, eric.smith
>  > <python-3000-checkins at python.org> wrote:
>  >> Author: eric.smith
>  >>  Date: Fri Mar 21 00:02:08 2008
>  >>  New Revision: 61682
>  >>
>  >>  Modified:
>  >>    python/branches/py3k/Include/code.h
>  >>    python/branches/py3k/Include/compile.h
>  >>    python/branches/py3k/Lib/__future__.py
>  >>    python/branches/py3k/Lib/test/test_print.py
>  >>    python/branches/py3k/Python/future.c
>  >>  Log:
>  >>  Add __future__ import for print_function.  It's a no-op in 3.0, but it needs to not be a syntax error.
>  >>  Closes issue 2436.
>  >>
>  >>  Modified: python/branches/py3k/Include/code.h
>  >>  ==============================================================================
>  >>  --- python/branches/py3k/Include/code.h (original)
>  >>  +++ python/branches/py3k/Include/code.h Fri Mar 21 00:02:08 2008
>  >>  @@ -48,6 +48,7 @@
>  >>   #define CO_FUTURE_DIVISION     0x2000
>  >>   #define CO_FUTURE_ABSOLUTE_IMPORT 0x4000 /* do absolute imports by default */
>  >>   #define CO_FUTURE_WITH_STATEMENT  0x8000
>  >>  +#define CO_FUTURE_PRINT_FUNCTION  0x10000
>  >>   #endif
>  >>
>  >>   /* This should be defined if a future statement modifies the syntax.
>  >>
>  >>  Modified: python/branches/py3k/Include/compile.h
>  >>  ==============================================================================
>  >>  --- python/branches/py3k/Include/compile.h      (original)
>  >>  +++ python/branches/py3k/Include/compile.h      Fri Mar 21 00:02:08 2008
>  >>  @@ -24,6 +24,7 @@
>  >>   #define FUTURE_DIVISION "division"
>  >>   #define FUTURE_ABSOLUTE_IMPORT "absolute_import"
>  >>   #define FUTURE_WITH_STATEMENT "with_statement"
>  >>  +#define FUTURE_PRINT_FUNCTION "print_function"
>  >>
>  >>   struct _mod; /* Declare the existence of this type */
>  >>   PyAPI_FUNC(PyCodeObject *) PyAST_Compile(struct _mod *, const char *,
>  >>
>  >>  Modified: python/branches/py3k/Lib/__future__.py
>  >>  ==============================================================================
>  >>  --- python/branches/py3k/Lib/__future__.py      (original)
>  >>  +++ python/branches/py3k/Lib/__future__.py      Fri Mar 21 00:02:08 2008
>  >>  @@ -53,6 +53,7 @@
>  >>      "division",
>  >>      "absolute_import",
>  >>      "with_statement",
>  >>  +    "print_function",
>  >>   ]
>  >>
>  >>   __all__ = ["all_feature_names"] + all_feature_names
>  >>  @@ -66,6 +67,7 @@
>  >>   CO_FUTURE_DIVISION   = 0x2000   # division
>  >>   CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default
>  >>   CO_FUTURE_WITH_STATEMENT  = 0x8000   # with statement
>  >>  +CO_FUTURE_PRINT_FUNCTION  = 0x10000   # print function
>  >>
>  >>   class _Feature:
>  >>      def __init__(self, optionalRelease, mandatoryRelease, compiler_flag):
>  >>  @@ -114,3 +116,7 @@
>  >>   with_statement = _Feature((2, 5, 0, "alpha", 1),
>  >>                            (2, 6, 0, "alpha", 0),
>  >>                            CO_FUTURE_WITH_STATEMENT)
>  >>  +
>  >>  +print_function = _Feature((2, 6, 0, "alpha", 2),
>  >>  +                          (3, 0, 0, "alpha", 0),
>  >>  +                          CO_FUTURE_PRINT_FUNCTION)
>  >>
>  >>  Modified: python/branches/py3k/Lib/test/test_print.py
>  >>  ==============================================================================
>  >>  --- python/branches/py3k/Lib/test/test_print.py (original)
>  >>  +++ python/branches/py3k/Lib/test/test_print.py Fri Mar 21 00:02:08 2008
>  >>  @@ -1,6 +1,8 @@
>  >>   """Test correct operation of the print function.
>  >>   """
>  >>
>  >>  +from __future__ import print_function
>  >>  +
>  >>   import unittest
>  >>   from test import test_support
>  >>
>  >>  @@ -98,6 +100,11 @@
>  >>          x('*\n', (ClassWith__str__('*'),))
>  >>          x('abc 1\n', (ClassWith__str__('abc'), 1))
>  >>
>  >>  +#        # 2.x unicode tests
>  >>  +#        x(u'1 2\n', ('1', u'2'))
>  >>  +#        x(u'u\1234\n', (u'u\1234',))
>  >>  +#        x(u'  abc 1\n', (' ', ClassWith__str__(u'abc'), 1))
>  >>  +
>  >>          # errors
>  >>          self.assertRaises(TypeError, print, '', sep=3)
>  >>          self.assertRaises(TypeError, print, '', end=3)
>  >>
>  >>  Modified: python/branches/py3k/Python/future.c
>  >>  ==============================================================================
>  >>  --- python/branches/py3k/Python/future.c        (original)
>  >>  +++ python/branches/py3k/Python/future.c        Fri Mar 21 00:02:08 2008
>  >>  @@ -33,6 +33,8 @@
>  >>                         continue;
>  >>                 } else if (strcmp(feature, FUTURE_WITH_STATEMENT) == 0) {
>  >>                         continue;
>  >>  +               } else if (strcmp(feature, FUTURE_PRINT_FUNCTION) == 0) {
>  >>  +                       continue;
>  >>                 } else if (strcmp(feature, "braces") == 0) {
>  >>                         PyErr_SetString(PyExc_SyntaxError,
>  >>                                         "not a chance");
>  >>  _______________________________________________
>  >>  Python-3000-checkins mailing list
>  >>  Python-3000-checkins at python.org
>  >>  http://mail.python.org/mailman/listinfo/python-3000-checkins
>  >>
>  >
>  >
>  >
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Fri Mar 21 02:41:09 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 20 Mar 2008 21:41:09 -0400
Subject: [Python-3000] [Python-3000-checkins] r61682 - in
 python/branches/py3k: Include/code.h Include/compile.h Lib/__future__.py
 Lib/test/test_print.py Python/future.c
In-Reply-To: <ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>
References: <20080320230233.A46231E4018@bag.python.org>	
	<ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>	
	<47E30775.9030407@trueblade.com>
	<ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>
Message-ID: <47E31235.80206@trueblade.com>

Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?

I believe so, yes.  But I'll double check.

> 
> On Thu, Mar 20, 2008 at 5:55 PM, Eric Smith
> <eric+python-dev at trueblade.com> wrote:
>> Guido van Rossum wrote:
>>  > Really? I though 2to3 was supposed to remove all __future__ imports?
>>
>>  I was convinced when Christian pointed out the statement in
>>  http://docs.python.org/lib/module-future.html:
>>  "No feature description will ever be deleted from __future__."
>>
>>  Admittedly, I implemented more than the minimum required for that, but
>>  since the other future statements (absolute_import, with_statement,
>>  etc.) were in py3k, I figured it would make sense to have print_function
>>  behave the same way.  Then, if we want to remove all __future__ imports
>>  from py3k, it's more obvious (to me, anyway) how to extract them all.
>>
>>
>>
>>  >
>>  > On Thu, Mar 20, 2008 at 4:02 PM, eric.smith
>>  > <python-3000-checkins at python.org> wrote:
>>  >> Author: eric.smith
>>  >>  Date: Fri Mar 21 00:02:08 2008
>>  >>  New Revision: 61682
>>  >>
>>  >>  Modified:
>>  >>    python/branches/py3k/Include/code.h
>>  >>    python/branches/py3k/Include/compile.h
>>  >>    python/branches/py3k/Lib/__future__.py
>>  >>    python/branches/py3k/Lib/test/test_print.py
>>  >>    python/branches/py3k/Python/future.c
>>  >>  Log:
>>  >>  Add __future__ import for print_function.  It's a no-op in 3.0, but it needs to not be a syntax error.
>>  >>  Closes issue 2436.
>>  >>
>>  >>  Modified: python/branches/py3k/Include/code.h
>>  >>  ==============================================================================
>>  >>  --- python/branches/py3k/Include/code.h (original)
>>  >>  +++ python/branches/py3k/Include/code.h Fri Mar 21 00:02:08 2008
>>  >>  @@ -48,6 +48,7 @@
>>  >>   #define CO_FUTURE_DIVISION     0x2000
>>  >>   #define CO_FUTURE_ABSOLUTE_IMPORT 0x4000 /* do absolute imports by default */
>>  >>   #define CO_FUTURE_WITH_STATEMENT  0x8000
>>  >>  +#define CO_FUTURE_PRINT_FUNCTION  0x10000
>>  >>   #endif
>>  >>
>>  >>   /* This should be defined if a future statement modifies the syntax.
>>  >>
>>  >>  Modified: python/branches/py3k/Include/compile.h
>>  >>  ==============================================================================
>>  >>  --- python/branches/py3k/Include/compile.h      (original)
>>  >>  +++ python/branches/py3k/Include/compile.h      Fri Mar 21 00:02:08 2008
>>  >>  @@ -24,6 +24,7 @@
>>  >>   #define FUTURE_DIVISION "division"
>>  >>   #define FUTURE_ABSOLUTE_IMPORT "absolute_import"
>>  >>   #define FUTURE_WITH_STATEMENT "with_statement"
>>  >>  +#define FUTURE_PRINT_FUNCTION "print_function"
>>  >>
>>  >>   struct _mod; /* Declare the existence of this type */
>>  >>   PyAPI_FUNC(PyCodeObject *) PyAST_Compile(struct _mod *, const char *,
>>  >>
>>  >>  Modified: python/branches/py3k/Lib/__future__.py
>>  >>  ==============================================================================
>>  >>  --- python/branches/py3k/Lib/__future__.py      (original)
>>  >>  +++ python/branches/py3k/Lib/__future__.py      Fri Mar 21 00:02:08 2008
>>  >>  @@ -53,6 +53,7 @@
>>  >>      "division",
>>  >>      "absolute_import",
>>  >>      "with_statement",
>>  >>  +    "print_function",
>>  >>   ]
>>  >>
>>  >>   __all__ = ["all_feature_names"] + all_feature_names
>>  >>  @@ -66,6 +67,7 @@
>>  >>   CO_FUTURE_DIVISION   = 0x2000   # division
>>  >>   CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default
>>  >>   CO_FUTURE_WITH_STATEMENT  = 0x8000   # with statement
>>  >>  +CO_FUTURE_PRINT_FUNCTION  = 0x10000   # print function
>>  >>
>>  >>   class _Feature:
>>  >>      def __init__(self, optionalRelease, mandatoryRelease, compiler_flag):
>>  >>  @@ -114,3 +116,7 @@
>>  >>   with_statement = _Feature((2, 5, 0, "alpha", 1),
>>  >>                            (2, 6, 0, "alpha", 0),
>>  >>                            CO_FUTURE_WITH_STATEMENT)
>>  >>  +
>>  >>  +print_function = _Feature((2, 6, 0, "alpha", 2),
>>  >>  +                          (3, 0, 0, "alpha", 0),
>>  >>  +                          CO_FUTURE_PRINT_FUNCTION)
>>  >>
>>  >>  Modified: python/branches/py3k/Lib/test/test_print.py
>>  >>  ==============================================================================
>>  >>  --- python/branches/py3k/Lib/test/test_print.py (original)
>>  >>  +++ python/branches/py3k/Lib/test/test_print.py Fri Mar 21 00:02:08 2008
>>  >>  @@ -1,6 +1,8 @@
>>  >>   """Test correct operation of the print function.
>>  >>   """
>>  >>
>>  >>  +from __future__ import print_function
>>  >>  +
>>  >>   import unittest
>>  >>   from test import test_support
>>  >>
>>  >>  @@ -98,6 +100,11 @@
>>  >>          x('*\n', (ClassWith__str__('*'),))
>>  >>          x('abc 1\n', (ClassWith__str__('abc'), 1))
>>  >>
>>  >>  +#        # 2.x unicode tests
>>  >>  +#        x(u'1 2\n', ('1', u'2'))
>>  >>  +#        x(u'u\1234\n', (u'u\1234',))
>>  >>  +#        x(u'  abc 1\n', (' ', ClassWith__str__(u'abc'), 1))
>>  >>  +
>>  >>          # errors
>>  >>          self.assertRaises(TypeError, print, '', sep=3)
>>  >>          self.assertRaises(TypeError, print, '', end=3)
>>  >>
>>  >>  Modified: python/branches/py3k/Python/future.c
>>  >>  ==============================================================================
>>  >>  --- python/branches/py3k/Python/future.c        (original)
>>  >>  +++ python/branches/py3k/Python/future.c        Fri Mar 21 00:02:08 2008
>>  >>  @@ -33,6 +33,8 @@
>>  >>                         continue;
>>  >>                 } else if (strcmp(feature, FUTURE_WITH_STATEMENT) == 0) {
>>  >>                         continue;
>>  >>  +               } else if (strcmp(feature, FUTURE_PRINT_FUNCTION) == 0) {
>>  >>  +                       continue;
>>  >>                 } else if (strcmp(feature, "braces") == 0) {
>>  >>                         PyErr_SetString(PyExc_SyntaxError,
>>  >>                                         "not a chance");
>>  >>  _______________________________________________
>>  >>  Python-3000-checkins mailing list
>>  >>  Python-3000-checkins at python.org
>>  >>  http://mail.python.org/mailman/listinfo/python-3000-checkins
>>  >>
>>  >
>>  >
>>  >
>>
>>
> 
> 
> 


From eric+python-dev at trueblade.com  Fri Mar 21 04:07:08 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 20 Mar 2008 23:07:08 -0400
Subject: [Python-3000] keeping __future__ imports [was: Re:
 [Python-3000-checkins] r61682 - in python/branches/py3k: Include/code.h
 Include/compile.h Lib/__future__.py Lib/test/test_print.py Python/future.c]
In-Reply-To: <ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>
References: <20080320230233.A46231E4018@bag.python.org>	
	<ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>	
	<47E30775.9030407@trueblade.com>
	<ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>
Message-ID: <47E3265C.3060503@trueblade.com>

Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?

Yes, all of them are in __future__.py.  But most references to 2 of them 
(nested scopes and generators) have been deleted from the C code, in 
both 2.6 and 3.0.

I think it is useful to have a few in the C code, so that there are 
examples of how to implement them.  But maybe just having them in svn is 
good enough, and we should delete the remnants out of the active C 
source.  Or maybe delete all but one, and leave it #ifdef'd out, which 
looks to be the case in 3.0, at least.

I think the only important part is that all of the __future__ imports 
work (and do nothing) in 3.0.

From guido at python.org  Fri Mar 21 04:24:17 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 20 Mar 2008 20:24:17 -0700
Subject: [Python-3000] keeping __future__ imports [was: Re:
	[Python-3000-checkins] r61682 - in python/branches/py3k:
	Include/code.h Include/compile.h Lib/__future__.py
	Lib/test/test_print.py Python/future.c]
In-Reply-To: <47E3265C.3060503@trueblade.com>
References: <20080320230233.A46231E4018@bag.python.org>
	<ca471dc20803201635k75ed98ccv7d53640779e5300a@mail.gmail.com>
	<47E30775.9030407@trueblade.com>
	<ca471dc20803201829t3f1a7be4le67e9268eb65c87d@mail.gmail.com>
	<47E3265C.3060503@trueblade.com>
Message-ID: <ca471dc20803202024k29743a32k8abe5aa795556a62@mail.gmail.com>

You're right, having at least one example in svn helps tremendously.
This is super deep code written by Tim Peters, and getting all the
details right is tricky...

On Thu, Mar 20, 2008 at 8:07 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
>  > Cool, I can live with that. Are all current __future__ statements
>  > still valid in 3.0?
>
>  Yes, all of them are in __future__.py.  But most references to 2 of them
>  (nested scopes and generators) have been deleted from the C code, in
>  both 2.6 and 3.0.
>
>  I think it is useful to have a few in the C code, so that there are
>  examples of how to implement them.  But maybe just having them in svn is
>  good enough, and we should delete the remnants out of the active C
>  source.  Or maybe delete all but one, and leave it #ifdef'd out, which
>  looks to be the case in 3.0, at least.
>
>  I think the only important part is that all of the __future__ imports
>  work (and do nothing) in 3.0.
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Fri Mar 21 04:47:36 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 20 Mar 2008 23:47:36 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E251CF.2050104@v.loewis.de>	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	<47E255B8.9080007@v.loewis.de>	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	<47E2906D.3090201@v.loewis.de><47E2A8C1.9060906@trueblade.com>	
	<47E2B6B1.1010208@cheimes.de><9e804ac0803201209y6d284555y85769d7f2a6faee8@mail.gmail.com>
	<47E2B941.4080700@cheimes.de>
Message-ID: <frvb4l$cpg$1@ger.gmane.org>


"Christian Heimes" <lists at cheimes.de> wrote in message 
news:47E2B941.4080700 at cheimes.de...
| Thomas Wouters schrieb:
| The __future__ docs say "No feature description will ever be deleted
| from __future__."
|
| ever is a very strong word and I expect Python 3.x to follow the rule.

I was tempted to suggest that 'ever' could be interpred as 'ever in 2.x' 
but then I remembered the purpose of the rule, which is to allow a 
forward-looking individual to write modules that will operate in both a 
current version and an anticipated future version *without having to touch 
the code* -- until they choose to for purposes other than deleting future 
statements.  So each version should have a dict of retired futures that are 
accepted and then ignored.

In the case of 2.6 and 3.0, the future version will already be present, so 
it will be easier to develop a nearly complete set of future statements. 
If people who are skittish about autoconversion, especially by someone 
else's code, choose and succeed in writing code in a Python subset that 
works in both 3.0 and futurized 2.6, more power to them.  I do not think 
that they should be impeded by having to delete future statements, now more 
than at any other time.

tjr




From nnorwitz at gmail.com  Fri Mar 21 05:51:06 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 20 Mar 2008 23:51:06 -0500
Subject: [Python-3000] PyLong_Check() behaviour clarification
	(test_getargs2 failing on Windows x64)
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEE32@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEE32@EXMBX04.exchhosting.com>
Message-ID: <ee2a432c0803202151n1660b3afne387d67bb4fdc41d@mail.gmail.com>

On Thu, Mar 20, 2008 at 2:13 AM, Trent Nelson <tnelson at onresolve.com> wrote:
> test_getargs2 is failing on Windows x64:
>  test test_getargs2 failed -- Traceback (most recent call last):
>   File "S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py", line 190, in test_n
>     self.failUnlessEqual(99, getargs_n(Long()))
>  TypeError: 'Long' object cannot be interpreted as an integer
>
>  Drilling down into the source, this code arrives at Python/getargs.c:convertsimple().  On Windows x64, SIZEOF_SIZE_T != SIZEOF_LONG, so there's a case 'n' statement that is defined that does the following:
>
>     iobj = PyNumber_Index(arg);
>
>  I'm a little confused.  At this point, arg is a PyObject *, and arg->obj_type->tp_as_number->nb_int has a non-zero value.  However, PyNumber_Index(arg) performs two checks, and this object fails both, which results in the TypeError being raised.

PyNumber_Index() works on an object that is an int or long or has an
__index__ method.  The "Long" class has only an __int__ method.  It is
otherwise a regular user-defined class that has no super class.

>  The first check is PyLong_Check(arg), which is handled via PyType_FastSubclass, which ends up doing the following:
>
>     ((arg->obj_type->tp_flags & Py_TPFLAGS_LONG_SUBCLASS) != 0)
>
>  tp_flags is 284160 at this point.  Py_TPFLAGS_LONG_SUBCLASS is 16777216 and Py_TPFLAGS_INT_SUBCLASS is 8388608, so this check fails.  Why doesn't tp_flags have either one of these values here?  obj_type->nb_int has a value, so shouldn't flags reflect the type?

Despite the class name of "Long", the object doesn't subclass int or
long.  That's why the tp_flags checks are failing.

nb_int has a value because of the __int__ method defined on Long.

>  I've just checked a 32-bit build and PyNumber_Index for a PyObject * representing a literal 99 also exhibits the same behaviour as above.
>
>  Also, if we're a 32-bit build, the 'n' code path visits PyLong_AsLong(), which calls PyLong_AsLongAndOverflow() -- the test cases calling getargs_n() test for the overflow being raised correctly.  Notionally, on x64 Windows where ((size_t == long long) > long), shouldn't we have a PyLong_AsLongLongAndOverflow() method?

The APIs seem very confused.  I'm not sure that is the best way to go
either.  Conceptually from what the test is trying to do, we need to
convert from a user-defined type (Long) to an PyObject (Python long or
PyLongObject) and then convert that to a Py_ssize_t.  I'm not sure the
test makes the most sense though.  There should be a test added that
uses a value between 2**32 and 2**64 to ensure we cover the win64
case.

I think the best thing to do for now (we need to clean up all the APIs
and have them make sense) is change the code that handles 'n' as
follows:

        {
                PyObject *iobj;
                Py_ssize_t *p = va_arg(*p_va, Py_ssize_t *);
                Py_ssize_t ival = -1;
                if (float_argument_error(arg))
                        return converterr("integer<n>", arg, msgbuf, bufsize);
                iobj = PyNumber_Index(arg);
                /* Code added here to handle __int__ methods on
classes which don't subclass int. */
                if (iobj == NULL) {
                        PyErr_Clear();
                        /* Using PyNumber_Long() here is probably too
permissive.  It converts strings and objects with __trunc__. Probably
we should just check the nb_int (or is it nb_long in 3k?) slot
specifically and call that? */
                        iobj = PyNumber_Long(arg);
                }
                if (iobj != NULL)
                        ival = PyLong_AsSsize_t(arg);
                if (ival == -1 && PyErr_Occurred())
                        return converterr("integer<n>", arg, msgbuf, bufsize);
                *p = ival;
                break;
        }

I'm not sure if we are abusing the 'n' format here or not.  The doc
(Doc/c-api/arg.rst) just says it turns the arg into a Py_ssize_t.  I
don't know if __index__ should really be (ab)used or not.  PEP 357
added __index__.

n

From martin at v.loewis.de  Mon Mar 17 05:27:04 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 23:27:04 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
Message-ID: <47DDF318.4080303@v.loewis.de>

> 'critical' is fine (or 'immediate').  My problem before was that I  
> couldn't do one query that gave me all the critical issues for both  
> 2.6 and 3.0.  That certainly could have been pebkac though.  Neal  
> mentioned that that kind of query should be possible, if it's not  
> already there.

I just created a "Showstoppers" public query (go to Your Queries/*edit*,
and set it to "leave in").

This *just* searches for critical open issues, all versions. Given
that there are currently really no critical issues, that semantically
is the same as further restricting it to 2.6 and 3.0.

Creating a query that searches for multiple versions is possible
through URL editing, but not the form (currently). I'm not sure
whether that would search for issues which are marked both 2.6
and 3.0, or for issues that are either marked 2.6 *or* 3.0.

Regards,
Martin


From martin at v.loewis.de  Mon Mar 17 05:29:41 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Mar 2008 23:29:41 -0500
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
Message-ID: <47DDF3B5.5010604@v.loewis.de>

> That would certainly work for me.  Could we add some description of this 
> separation to the Roundup pages?  And/or is there a way that only 
> developers or the triage specialists are allowed to change the priority?

I dropped the severity. Changing the priority was already restricted to
people with the Developer role.

Regards,
Martin


From abpillai at gmail.com  Fri Mar 21 07:26:18 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 21 Mar 2008 11:56:18 +0530
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <fb6fbf560803200755m15a024a6s28dbf635cd362316@mail.gmail.com>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<47DD98FE.2040705@v.loewis.de>
	<4A9CB229-815A-4C81-A469-BC391CEAB66F@python.org>
	<8548c5f30803170048j57afd880o65525c802414b74@mail.gmail.com>
	<ca471dc20803170638v4704ab63g2539d9c1f0d9d6fe@mail.gmail.com>
	<8548c5f30803200226w1c41ce3btb6ef7d21ac7fe7cb@mail.gmail.com>
	<fb6fbf560803200755m15a024a6s28dbf635cd362316@mail.gmail.com>
Message-ID: <8548c5f30803202326j1947b0edh6e2f52c4e8d431e1@mail.gmail.com>

On Thu, Mar 20, 2008 at 8:25 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 3/20/08, Anand Balachandran Pillai <abpillai at gmail.com> wrote:
>
>  >  There are also many bugs filed for Py3k which are patterned
>  >  like "deprecated feature <oldfeature> should raise a warning in py3k".
>  >  Are they in any priority ?
>
>  Do you really mean warn in 3.0?  Or do you mean that they're gone (or
>  should be, or might be) in 3.x, and should raise a warning in 2.6,
>  given the -3 flag?

I meant "deprecated feature in py3k should raise a warning in py2.6".
Not warn in 3.0. Confusion in the wording was mine - sorry for that!

>
>  If something is removed in 3.0, would a failure to warn in 2.x under
>  -3 mode be considered a bug that could get fixed in 2.6.1, or would
>  the warning have to wait for 2.7?
>
>  -jJ
>


Thanks

-- 
-Anand

From g.brandl at gmx.net  Fri Mar 21 10:05:12 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 21 Mar 2008 10:05:12 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E251CF.2050104@v.loewis.de>	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	<47E255B8.9080007@v.loewis.de>	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	<932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>
	<e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
Message-ID: <frvtob$k9a$1@ger.gmane.org>

Amaury Forgeot d'Arc schrieb:
> Ralf Schmitt wrote:
>>
>> On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro <regebro at gmail.com> wrote:
>> >
>> > On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. L?wis" <martin at v.loewis.de>
>> wrote:
>> > >  However, it *is* common to install Python code before running it.
>> >
>> > Not every time you make a change in the code.
>> >
>>
>> I also happen to have test code that will not be installed with python
>> setup.py install, so I would have to manually convert that.
> 
> What about using sys.path_hooks to run 2to3 on the fly at import time?
> It would cache its results, of course.
> 

See http://dev.pocoo.org/hg/sandbox/file/tip/auto2to3.py  - it's awfully
slow.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Fri Mar 21 10:09:23 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 21 Mar 2008 10:09:23 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E2C69B.2080200@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>		<47E251CF.2050104@v.loewis.de>		<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>		<47E255B8.9080007@v.loewis.de>		<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>		<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	<47E2906D.3090201@v.loewis.de>
	<47E2A8C1.9060906@trueblade.com> <47E2C69B.2080200@v.loewis.de>
Message-ID: <frvu06$k9a$2@ger.gmane.org>

Martin v. L?wis schrieb:
>>> It was proposed before, I don't know whether any implementation
>>> on that has started.
>> 
>> I don't see anything in the bug tracker.  I'd be willing to look at it, 
>> if this is what we want to do.
> 
> Neither could I. I vaguely remember having people mention it, but
> could not find anything, either. Perhaps you need to get
> approval/agreement first in a separate thread.

Doesn't the code for the -U flag do exactly this?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From brett at python.org  Fri Mar 21 21:50:47 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Mar 2008 13:50:47 -0700
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20080321084249.GA83712@nexus.in-nomine.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
Message-ID: <bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>

On Fri, Mar 21, 2008 at 1:42 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> (To provide counterweight.)
>
>
>  -On [20080320 20:44], Barry Warsaw (barry at python.org) wrote:
>  >We have not made a decision to move to Bazaar officially, nor have we made
>  >a decision to even move off of Subversion.
>
>  Good, because between this now and pytz the other 63 projects I follow use
>  Subversion or Mercurial.
>  Bazaar seems to be mostly limited to Ubuntu users and stuff Canonical does,
>  so the choice for a Bazaar setup next to Subversion strikes me a bit as odd.
>  Mercurial is also Python, distributed and with a, as far as I (can) track
>  things, bigger market share than Bazaar.
>

Just to head this off, this is not a specific vote of confidence for
Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
were willing to put the time and effort to get the mirror up and going
while the Bazaar team was nearby to answer questions. At this point
this is more of an experiment to see if people like the development
style of distributed VCS. If people do and someone steps forward to
put the time and effort to add Mercurial support, we can then consider
doing something similar to what was done for the issue tracker.

But for right now this is just to try out distributed VCS, nothing more.

-Brett

From musiccomposition at gmail.com  Fri Mar 21 21:54:04 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 21 Mar 2008 15:54:04 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <1afaf6160803211354v615ea33l528327e9a0b6dad9@mail.gmail.com>

On Thu, Mar 20, 2008 at 2:42 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
>
> The current Subversion repository is still the master copy of the
> source code.  We have not made a decision to move to Bazaar
> officially, nor have we made a decision to even move off of
> Subversion.  We're making these branches available exactly so that
> you, the Python developer community, can kick the tires and see if it
> makes sense to move to a different vcs.  Nothing will happen until
> after the Python 2.6/3.0 releases anyway.
>
> All the gory details are documented here:
>
>     http://www.python.org/dev/bazaar
>
> These branches are available both for core Python developers with
> commit privileges, and the wider world of developers without commit
> privileges.  It's this latter group that I think will find the most
> compelling immediate benefit from using Bazaar, because they will no
> longer need to maintain their own changes using a mass of patch files.
>
> For more information on Bazaar in general, see:
>
>     http://bazaar-vcs.org
>
> You will probably be most interested in the Bazaar mirrors of the
> Subversion master repository.  We have a cron job that updates Bazaar
> from Subversion every 15 minutes.  It is also possible to push changes
> made in your Bazaar branches into the Subversion master, so you can
> keep reasonably up-to-date and interact with the Python source code
> solely via Bazaar.

Great work! I love Bazaar. It's a lot more flexible and user-friendlier than
anything else out there. I hope we can switch to Bazaar entirely sometime!
:)

>
>
> Please let me know if you have any questions or anything in the docs
> referenced above aren't clear.  I know I need to document the Bazaar-
>  >Subversion workflow in more detail.
>
> Huge thanks go out especially to Thomas Wouters who sprinted with me
> yesterday on getting the whole infrastructure up and running.  Thanks
> also to Martin v. Loewis, Sean Reifschneider, and the folks here at
> Pycon from the Bazaar project, Ian, Andrew, John, and Edwin.
>
> Enjoy,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR+K+H3EjvBPtnXfVAQL6bwP/d0XKx0mRPgzdOD6zCPwwRl8y2kxWV9Vl
> zVwN07cK8IlwMa9M470MsERuXuD8hmeXnPgnrUcrX9HciwldmY8C33t0f8GaOk1J
> iD4Od1midlIaJJiMd+JcFk9NbX3Rwc4HMj3s8jKjjdlGrFe77ei9DCZ/HMl/iG5K
> fyyjXo4HLEE=
> =Gcjq
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080321/4d24b30e/attachment.htm 

From brett at python.org  Fri Mar 21 22:01:19 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Mar 2008 14:01:19 -0700
Subject: [Python-3000] Python source code on Bazaar vcs
In-Reply-To: <47E2DBEF.8010809@cheimes.de>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<47E2DBEF.8010809@cheimes.de>
Message-ID: <bbaeab100803211401o10f1d00if7571a55d2489c2f@mail.gmail.com>

On Thu, Mar 20, 2008 at 2:49 PM, Christian Heimes <lists at cheimes.de> wrote:
> Barry Warsaw schrieb:
>
> > I'm happy to announce that we now have available for public
>  > consumption, the Python source code for 2.5, 2.6 and 3.0 available
>  > under the Bazaar distributed version control system.
>
>  Somebody has to fix the subversion related code in Python/sysmodule.c:
>
>  heimes at hamiller:~/dev/python/bzr/trunk$ ./python
>  Fatal Python error: subversion keywords missing
>  Aborted (core dumped)

The ironic thing is that Barry is the one that added that code. =)

-Brett

From martin at v.loewis.de  Fri Mar 21 22:07:58 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 21 Mar 2008 22:07:58 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <frvtob$k9a$1@ger.gmane.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E251CF.2050104@v.loewis.de>	<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>	<47E255B8.9080007@v.loewis.de>	<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>	<932f8baf0803200538pb93d40di83f21db6e729386d@mail.gmail.com>	<e27efe130803200628i24ea382dnc61376367ee0f71e@mail.gmail.com>
	<frvtob$k9a$1@ger.gmane.org>
Message-ID: <47E423AE.6000907@v.loewis.de>

> See http://dev.pocoo.org/hg/sandbox/file/tip/auto2to3.py  - it's awfully
> slow.

When David Wolever checks in his latest changes, it won't be that 
awfully slow anymore.

Regards,
Martin


From martin at v.loewis.de  Fri Mar 21 22:09:28 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 21 Mar 2008 22:09:28 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <frvu06$k9a$2@ger.gmane.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>		<47E251CF.2050104@v.loewis.de>		<932f8baf0803200507m44ee7258jc0535cb353378ad6@mail.gmail.com>		<47E255B8.9080007@v.loewis.de>		<319e029f0803200530y67eda6d9kd0232d789d210082@mail.gmail.com>		<47E2700E.3050700@v.loewis.de>	<932f8baf0803200720q233a5b1p13cb00357179a524@mail.gmail.com>	<47E2906D.3090201@v.loewis.de>	<47E2A8C1.9060906@trueblade.com>
	<47E2C69B.2080200@v.loewis.de> <frvu06$k9a$2@ger.gmane.org>
Message-ID: <47E42408.2030907@v.loewis.de>

>> Neither could I. I vaguely remember having people mention it, but
>> could not find anything, either. Perhaps you need to get
>> approval/agreement first in a separate thread.
> 
> Doesn't the code for the -U flag do exactly this?

Not exactly. The future import does it on a per-module basis;
the -U flag globally.

I don't think the -U flag works already. It will only
(kind of) work in 3k :-)

Regards,
Martin

From p.f.moore at gmail.com  Fri Mar 21 22:28:07 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 21 Mar 2008 21:28:07 +0000
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
Message-ID: <79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>

On 21/03/2008, Brett Cannon <brett at python.org> wrote:
> Just to head this off, this is not a specific vote of confidence for
>  Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
>  were willing to put the time and effort to get the mirror up and going
>  while the Bazaar team was nearby to answer questions. At this point
>  this is more of an experiment to see if people like the development
>  style of distributed VCS. If people do and someone steps forward to
>  put the time and effort to add Mercurial support, we can then consider
>  doing something similar to what was done for the issue tracker.
>
>  But for right now this is just to try out distributed VCS, nothing more.

One thing I really like the idea of with Mercurial for my situation
(non-committer) is the mq extension, which lets me manage my changes
as a "stack of patches" - so I'm completely working with patches,
which is what I have to post to the tracker, etc.

Is there a similar workflow in Bazaar? I know there's the loom
extension (although I haven't used it much yet) but I'm not sure how
I'd use that.

Basically, can some Bazaar expert offer a suggestion as to how a
non-developer with read-only access would best use the Bazaar
repositories to maintain a number of patches to be posted to the
tracker?

Thanks,
Paul.

From musiccomposition at gmail.com  Fri Mar 21 22:57:34 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 21 Mar 2008 16:57:34 -0500
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
Message-ID: <1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>

On Fri, Mar 21, 2008 at 4:28 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 21/03/2008, Brett Cannon <brett at python.org> wrote:
> > Just to head this off, this is not a specific vote of confidence for
> >  Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
> >  were willing to put the time and effort to get the mirror up and going
> >  while the Bazaar team was nearby to answer questions. At this point
> >  this is more of an experiment to see if people like the development
> >  style of distributed VCS. If people do and someone steps forward to
> >  put the time and effort to add Mercurial support, we can then consider
> >  doing something similar to what was done for the issue tracker.
> >
> >  But for right now this is just to try out distributed VCS, nothing
> more.
>
> One thing I really like the idea of with Mercurial for my situation
> (non-committer) is the mq extension, which lets me manage my changes
> as a "stack of patches" - so I'm completely working with patches,
> which is what I have to post to the tracker, etc.
>
> Is there a similar workflow in Bazaar? I know there's the loom
> extension (although I haven't used it much yet) but I'm not sure how
> I'd use that.
>
bzr-loom is what you want.

>
>
> Basically, can some Bazaar expert offer a suggestion as to how a
> non-developer with read-only access would best use the Bazaar
> repositories to maintain a number of patches to be posted to the
> tracker?

I tend to make a repository and make a working copy for each patch in it.
The history is saved in the repository so it's efficient.

>
>
> Thanks,
> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080321/8d9cabd0/attachment-0001.htm 

From p.f.moore at gmail.com  Fri Mar 21 23:04:30 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 21 Mar 2008 22:04:30 +0000
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
	<1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
Message-ID: <79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>

On 21/03/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> I tend to make a repository and make a working copy for each patch in it.
> The history is saved in the repository so it's efficient.

OK, so just lots of copies, fair enough. Presumably just use bzr diff
to create patches? Much like Subversion, in practice, but with local
commits of partial work.

Paul.

From musiccomposition at gmail.com  Fri Mar 21 23:10:41 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 21 Mar 2008 17:10:41 -0500
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
	<1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
	<79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>
Message-ID: <1afaf6160803211510i3026e2f0n2ee534ff514be459@mail.gmail.com>

On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 21/03/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > I tend to make a repository and make a working copy for each patch in
> it.
> > The history is saved in the repository so it's efficient.
>
> OK, so just lots of copies, fair enough. Presumably just use bzr diff
> to create patches? Much like Subversion, in practice, but with local
> commits of partial work.

Yes, bzr diff should do the trick, although if you have local commits in it,
you'll have to give the revision number manually. Bazaar also has this cool
feature called merge directives. They let you bundle your branch (with all
the commits) in a patch-like file, which can be easily merged into the
mainline by core devs. Of course, Python hasn't moved to Bazaar, so
widespread use of those is unlikely soon.

>
>
> Paul.
>

Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080321/354dce99/attachment.htm 

From brett at python.org  Sat Mar 22 00:12:00 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Mar 2008 16:12:00 -0700
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803211510i3026e2f0n2ee534ff514be459@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
	<1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
	<79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>
	<1afaf6160803211510i3026e2f0n2ee534ff514be459@mail.gmail.com>
Message-ID: <bbaeab100803211612p6833ee65u4441859b38b3cd44@mail.gmail.com>

On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
>
>
>
>
> On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> >
> > On 21/03/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > > I tend to make a repository and make a working copy for each patch in
> it.
> > > The history is saved in the repository so it's efficient.
> >
> > OK, so just lots of copies, fair enough. Presumably just use bzr diff
> > to create patches? Much like Subversion, in practice, but with local
> > commits of partial work.
> Yes, bzr diff should do the trick, although if you have local commits in it,
> you'll have to give the revision number manually.

That's not really true. Let's say you have a trunk branch that you
keep which is pristine. You branch off of it and create a xxx branch.
You can diff between xxx and trunk by running  ``bzr diff xxx --old
trunk``. You can also run this from within xxx with ``bzr diff --old
../trunk``.

-Brett

From musiccomposition at gmail.com  Sat Mar 22 00:12:55 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 21 Mar 2008 18:12:55 -0500
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <bbaeab100803211612p6833ee65u4441859b38b3cd44@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
	<1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
	<79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>
	<1afaf6160803211510i3026e2f0n2ee534ff514be459@mail.gmail.com>
	<bbaeab100803211612p6833ee65u4441859b38b3cd44@mail.gmail.com>
Message-ID: <1afaf6160803211612v124fb7ft4b2455c6bda5d71f@mail.gmail.com>

On Fri, Mar 21, 2008 at 6:12 PM, Brett Cannon <brett at python.org> wrote:

> On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >
> >
> >
> >
> > On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> > >
> > > On 21/03/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > > > I tend to make a repository and make a working copy for each patch
> in
> > it.
> > > > The history is saved in the repository so it's efficient.
> > >
> > > OK, so just lots of copies, fair enough. Presumably just use bzr diff
> > > to create patches? Much like Subversion, in practice, but with local
> > > commits of partial work.
> > Yes, bzr diff should do the trick, although if you have local commits in
> it,
> > you'll have to give the revision number manually.
>
> That's not really true. Let's say you have a trunk branch that you
> keep which is pristine. You branch off of it and create a xxx branch.
> You can diff between xxx and trunk by running  ``bzr diff xxx --old
> trunk``. You can also run this from within xxx with ``bzr diff --old
> ../trunk``.

Well, I just learned something. ;)

>
>
> -Brett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080321/d15d263d/attachment.htm 

From larry at hastings.org  Sat Mar 22 00:26:23 2008
From: larry at hastings.org (Larry Hastings)
Date: Fri, 21 Mar 2008 16:26:23 -0700
Subject: [Python-3000] Reserve "pragma" keyword in Python 3.0?
Message-ID: <47E4441F.4000505@hastings.org>



I think Python needs a dedicated "pragma" syntax; we already have two 
pragma syntaxes ("from __future__ import" and "# coding"), and I think a 
syntax designed for expressing pragmas would be much clearer than using 
existing language features in weird ways to express pragmas.  But that's 
a debate for another day.

Today's topic is much smaller in scope: can I get support for making 
"pragma" a reserved keyword in Python?  Guido himself suggested doing 
that back in August of 2000 during a previous pragma-y discussion:

    http://mail.python.org/pipermail/python-dev/2000-August/008840.html

I'm not proposing that the keyword do anything, just that "pragma" be 
reserved for future expansion, and therefore be illegal for use as an 
identifier.  For now any use of it would be an error.

If there's some chance it would be accepted, I would happily make the patch.

Driving the thin end of the wedge,


/larry/

From lists at cheimes.de  Sat Mar 22 00:41:21 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 22 Mar 2008 00:41:21 +0100
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>	
	<47DD545D.6070300@cheimes.de>	
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>	
	<47DD613E.6090007@cheimes.de>
	<ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>
Message-ID: <47E447A1.6070208@cheimes.de>

Guido van Rossum schrieb:
> Even though the more popular PyInt_ APIs are still available (even if
> only as macros).

THe PyInt_* macros are only available when Include/intobject.h is
included explicitly. It's not in Python.h any more.

> I disagree. Bad merges are already a frequent cause of instability in
> 3.0. This could easily double the problems. And while I want to reduce
> the instability (I really wish you would no commit until all unittests
> pass), I also don't want the merges to cost more of your time!

I'm trying my best but sometimes I don't spot the cause of a failing
unit test. I got a slightly faster laptop so I'm now able to run the
full unit test suite every time I do a svnmerge.py.

> It doesn't have to be so black and white. Using the macro approach you
> propose we can fix the situation at any time later.
> 
> We could also make the changes in 2.6, so that the 2.6 code looks the
> same as 3.0. (However for binary compatibility I think it would be
> better if in 2.6 the linker sees PyString where in 3.0 it sees
> PyBytes.)

Let me get this straight. You propose that we replace PyString_ with
PyBytes_ in both Python 2.6 and 3.0 core code. In Python 2.6 some macros
replace the PyBytes_* functions with PyString_ so the linker sees
PyString_*? Mmh, it sounds like an interesting idea :]

Christian



From musiccomposition at gmail.com  Sat Mar 22 00:37:49 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 21 Mar 2008 18:37:49 -0500
Subject: [Python-3000] Reserve "pragma" keyword in Python 3.0?
In-Reply-To: <47E4441F.4000505@hastings.org>
References: <47E4441F.4000505@hastings.org>
Message-ID: <1afaf6160803211637i2c84b1c5h35fc72aee2c9f112@mail.gmail.com>

On Fri, Mar 21, 2008 at 6:26 PM, Larry Hastings <larry at hastings.org> wrote:

>
>
> I think Python needs a dedicated "pragma" syntax; we already have two
> pragma syntaxes ("from __future__ import" and "# coding"), and I think a
> syntax designed for expressing pragmas would be much clearer than using
> existing language features in weird ways to express pragmas.  But that's
> a debate for another day.
>
> Today's topic is much smaller in scope: can I get support for making
> "pragma" a reserved keyword in Python?  Guido himself suggested doing
> that back in August of 2000 during a previous pragma-y discussion:
>
>    http://mail.python.org/pipermail/python-dev/2000-August/008840.html
>
> I'm not proposing that the keyword do anything, just that "pragma" be
> reserved for future expansion, and therefore be illegal for use as an
> identifier.  For now any use of it would be an error.
>
> If there's some chance it would be accepted, I would happily make the
> patch.

If we did this, there'd be a deprecation warning in 2.x, and we'd make
keyword in 3.x

>
>
> Driving the thin end of the wedge,
>
>
> /larry/
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080321/6aecd2ca/attachment.htm 

From martin at v.loewis.de  Sat Mar 22 00:51:48 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 22 Mar 2008 00:51:48 +0100
Subject: [Python-3000] Reserve "pragma" keyword in Python 3.0?
In-Reply-To: <47E4441F.4000505@hastings.org>
References: <47E4441F.4000505@hastings.org>
Message-ID: <47E44A14.2030008@v.loewis.de>

> I think Python needs a dedicated "pragma" syntax; we already have two 
> pragma syntaxes ("from __future__ import" and "# coding"), and I think a 
> syntax designed for expressing pragmas would be much clearer than using 
> existing language features in weird ways to express pragmas.  But that's 
> a debate for another day.

See the (rejected) PEP 244.

> Today's topic is much smaller in scope: can I get support for making 
> "pragma" a reserved keyword in Python?  Guido himself suggested doing 
> that back in August of 2000 during a previous pragma-y discussion:
> 
>     http://mail.python.org/pipermail/python-dev/2000-August/008840.html
> 
> I'm not proposing that the keyword do anything, just that "pragma" be 
> reserved for future expansion, and therefore be illegal for use as an 
> identifier.  For now any use of it would be an error.
> 
> If there's some chance it would be accepted, I would happily make the patch.

I don't think there is. Making it a keyword now means essentially to
agree that the feature will be added later, so opponents of the feature
will oppose the first step.

Regards,
Martin

From charles.merriam at gmail.com  Sat Mar 22 01:02:29 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Fri, 21 Mar 2008 17:02:29 -0700
Subject: [Python-3000] (PEP 3000) Rethinking 2to3, __future__,
	and the migration path.
Message-ID: <b8c6f6c40803211702q482da16bo81ad78303b619872@mail.gmail.com>

I hate bringing up something that has been hashed over so many times,
but I'm a bear
of little brain and am not understanding the migration path.  The
whole use of the "2to3"
tools seems like an abrupt hack.  It is workable, but causes a serious
plan for near term
2.x to 3.x migration.   I'd like to present a different view.  Instead
of just yelling how it
must be wrong, consider it.  It's not far from the current migration
path and is less rocky.

Moving from 2.6 to 3.0 appears to encompass the following major tasks,
and some minor
ones:

1.  Change of Unadorned strings from default 'b' to default like the
(now illegal)  'u'
2.  Changed print becomes a function
3.  Changed meaning of keys(), items(), and values() changed
4.  Removed default ordering operators, string exceptions, old classes, etc.
5.  Changed repr() for Long.
6.  Completely predictable syntax modifications for Raise, Catch, etc.
etc., etc.

This is a lot for my head, and even a tool to translate is going to
cause odd warnings and
syntax errors everywhere.  It's especially hard as the advantages to
using 3.x are not
immediately realized upon conversion.

Now, for me this is (hopefully) academic:  I'm hoping not to port BLs
(metric) of code.  Still,
my consideration for programmers  would much prefer this sequence that
could, with changes
to 2.6, be done one module at a time in a way that converted and
unconverted code could live
side by side.  Over time, more of the transitional elements would be
'required' in my  build
environment.  That is, I would want to make my changes gradually and
have a reasonable
expectation that the first time I ran 2to3 would also be my last.

The biggest and most thoughtful cost is carefully looking at every
single string in my application
and deciding if it should be bytes or unicode, and adding the 'b' or
'u' adornment appropriately.
This would take an immense amount of time,  requiring rethinking APIs,
duplicating modules
when needing both byte and unicode processing, etc.  It's something to
do 'later'.  I expect a
transition period of adorning the strings whenever working on the code
anyway.  Eventually, I
would enable the Python warning about unadorned strings to catch the
last cases and times I
pull executable code from a file, database, or socket.

I would start banning deprecated and changed names, e.g., keys(),
range(), input() and the like.
When it makes sense,  I might use iter_keys(), xrange(), or
raw_input().  When it doesn't, I would
explicitly call functions,  not use idioms, to perform the old tasks:
range_as_list() or
input_with_eval().   Again the pattern of a period of  gradual change,
then pulling  the compiler
switch to warn about old usage.

I would start using the handy new printing function, named print3(),
instead of the print
statement.

Then I might, one day, switch to running 2.6 in the mode that warns
about old style classes,
default comparators, string  exceptions, and the like.   Likely, I
would use the fine grained control
to turn those warnings on one at a time over a  period of weeks or months.

Once there, I could confidently run 2to3 to build a 3.x version.  I
would do the same amount of
work, but spread my risk along a much longer schedule with more
options.  I would save time by
using serendipity when already maintaining code.   My 2.6 version
would always interact correctly
between modules which have been upgraded and those that have not.

In many ways, I'm not saying anything new.  Without fine grained
control in Python, I would expect
coders to start running the "-3" option or running "2to3" occasionally
to see what would need to
be fixed later in the module which has just been opened up.   With the
fine grained control, this
could be managed.   About 80% of the way could be done by judicial
control of static analyzers,
such as PyChecker or PyLInt.  100% would require options in Python.

Overall, the 2.x to 3.x transition needs to be fairly painless.  The
only immediate features for
developers are better unicode processing.  The other features are all
items that will be in 2.6
eventually, or have yet to be shown as really useful.    In a perfect
world, the gradual transition
looks like the more like the transition of C code to ANSI-C code to
ANSI-C compiled in a C++
compiler and less like the Perl leaps between version.

Once ready, the transition from 2.7 to 3.0 would be mechanical.

From guido at python.org  Sat Mar 22 01:18:04 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 21 Mar 2008 17:18:04 -0700
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <47E447A1.6070208@cheimes.de>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
	<47DD613E.6090007@cheimes.de>
	<ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>
	<47E447A1.6070208@cheimes.de>
Message-ID: <ca471dc20803211718r3c54ba1bud8691b6ab5c4fccc@mail.gmail.com>

On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum schrieb:
>
> > Even though the more popular PyInt_ APIs are still available (even if
>  > only as macros).
>
>  THe PyInt_* macros are only available when Include/intobject.h is
>  included explicitly. It's not in Python.h any more.
>
>
>  > I disagree. Bad merges are already a frequent cause of instability in
>  > 3.0. This could easily double the problems. And while I want to reduce
>  > the instability (I really wish you would no commit until all unittests
>  > pass), I also don't want the merges to cost more of your time!
>
>  I'm trying my best but sometimes I don't spot the cause of a failing
>  unit test. I got a slightly faster laptop so I'm now able to run the
>  full unit test suite every time I do a svnmerge.py.

:-)

>  > It doesn't have to be so black and white. Using the macro approach you
>  > propose we can fix the situation at any time later.
>  >
>  > We could also make the changes in 2.6, so that the 2.6 code looks the
>  > same as 3.0. (However for binary compatibility I think it would be
>  > better if in 2.6 the linker sees PyString where in 3.0 it sees
>  > PyBytes.)
>
>  Let me get this straight. You propose that we replace PyString_ with
>  PyBytes_ in both Python 2.6 and 3.0 core code. In Python 2.6 some macros
>  replace the PyBytes_* functions with PyString_ so the linker sees
>  PyString_*? Mmh, it sounds like an interesting idea :]

Right. We've done this 2-stage rename before, during the great
(sometimes known as grand) renaming, in the 1.x days.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rasky at develer.com  Sat Mar 22 01:39:47 2008
From: rasky at develer.com (Giovanni Bajo)
Date: Sat, 22 Mar 2008 00:39:47 +0000 (UTC)
Subject: [Python-3000] Reserve "pragma" keyword in Python 3.0?
References: <47E4441F.4000505@hastings.org> <47E44A14.2030008@v.loewis.de>
Message-ID: <fs1kgi$sd5$1@ger.gmane.org>

On Sat, 22 Mar 2008 00:51:48 +0100, Martin v. L?wis wrote:

>> I think Python needs a dedicated "pragma" syntax; we already have two
>> pragma syntaxes ("from __future__ import" and "# coding"), and I think
>> a syntax designed for expressing pragmas would be much clearer than
>> using existing language features in weird ways to express pragmas.  But
>> that's a debate for another day.
> 
> See the (rejected) PEP 244.

This PEP wasn't updated explaining the reasons of the rejection, so we 
can't tell if those reasons apply to Py3k as well.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


From ncoghlan at gmail.com  Sat Mar 22 09:53:25 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 22 Mar 2008 18:53:25 +1000
Subject: [Python-3000] (PEP 3000) Rethinking 2to3, __future__,
 and the migration path.
In-Reply-To: <b8c6f6c40803211702q482da16bo81ad78303b619872@mail.gmail.com>
References: <b8c6f6c40803211702q482da16bo81ad78303b619872@mail.gmail.com>
Message-ID: <47E4C905.9030309@gmail.com>

Charles Merriam wrote:
> I hate bringing up something that has been hashed over so many times,
> but I'm a bear
> of little brain and am not understanding the migration path.  The
> whole use of the "2to3"
> tools seems like an abrupt hack.  It is workable, but causes a serious
> plan for near term
> 2.x to 3.x migration.   I'd like to present a different view.  Instead
> of just yelling how it
> must be wrong, consider it.  It's not far from the current migration
> path and is less rocky.

I'm not understanding what you are asking for that isn't being done 
already. There are a variety of from __future__ or from future_builtins 
options to enable various bits and pieces, and if you don't want the 
warnings, don't switch on the py3k warnings flag.

If you're asking for multiple command line switches to enable different 
subsets of the py3k warnings, that isn't going to happen. The only 
reason even the py3k warnings flag exists is to prevent the warnings 
having too much of a speed impact during normal execution of Python 2.6 
code - aside from that specific optimisation, the intention is for 
developers to enable or disable warnings of interest via the normal 
mechanisms in the warnings module.

So you *have* fine grained control - right down to choosing which 
individual warnings you want to ignore (for the moment, anyway).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From regebro at gmail.com  Sat Mar 22 13:04:47 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 22 Mar 2008 13:04:47 +0100
Subject: [Python-3000] Reserve "pragma" keyword in Python 3.0?
In-Reply-To: <47E44A14.2030008@v.loewis.de>
References: <47E4441F.4000505@hastings.org> <47E44A14.2030008@v.loewis.de>
Message-ID: <319e029f0803220504v7c23335ds905dffcffd323176@mail.gmail.com>

On Sat, Mar 22, 2008 at 12:51 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  > If there's some chance it would be accepted, I would happily make the patch.
>
>  I don't think there is. Making it a keyword now means essentially to
>  agree that the feature will be added later, so opponents of the feature
>  will oppose the first step.

In any case, calling it "pragma" is C-damage. ;) There is no way you
can understand what that is supposed to do unless you have used enough
C to use #pragmas, more or less. I find the syntax from __future__
import <whatever> clearer. It tells you what it does: It imports a bit
of the future.

I dont' think there will be much use of other "pragmas", we don't WANT
to change the languages behaviour except when backwards compatibility
breaks. But if that happens at least call it something reasonable. As
"enable specialfeature" or "use specialfeature". "pragma
specialfeature" is just confusing.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From p.f.moore at gmail.com  Fri Mar 21 23:04:30 2008
From: p.f.moore at gmail.com (ext Paul Moore)
Date: Fri, 21 Mar 2008 22:04:30 +0000
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
	<1afaf6160803211457y29cb0ce8s58898876d2f96a5b@mail.gmail.com>
Message-ID: <79990c6b0803211504o78032f66vbe55064bdf7a9f3@mail.gmail.com>

On 21/03/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> I tend to make a repository and make a working copy for each patch in it.
> The history is saved in the repository so it's efficient.

OK, so just lots of copies, fair enough. Presumably just use bzr diff
to create patches? Much like Subversion, in practice, but with local
commits of partial work.

Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/jukka.p.laurila%40nokia.com

From barry at python.org  Sat Mar 22 15:54:04 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 22 Mar 2008 10:54:04 -0400
Subject: [Python-3000] Python source code on Bazaar vcs
In-Reply-To: <47E2DBEF.8010809@cheimes.de>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<47E2DBEF.8010809@cheimes.de>
Message-ID: <C1454D65-B8F9-4C8E-85C1-FD6A65984C8C@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 20, 2008, at 5:49 PM, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I'm happy to announce that we now have available for public
>> consumption, the Python source code for 2.5, 2.6 and 3.0 available
>> under the Bazaar distributed version control system.
>
> Somebody has to fix the subversion related code in Python/sysmodule.c:
>
> heimes at hamiller:~/dev/python/bzr/trunk$ ./python
> Fatal Python error: subversion keywords missing
> Aborted (core dumped)

Yep.  I've opened issue 2456 for this in the bug tracker.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UdjnEjvBPtnXfVAQKQ8gQAuh8ynIbNXFaFEViQAvJ84M/D6Db4q008
X3XgoEq0wJWpjO2pA3lzDY0uuowkXGUMuhgMOQ6qeTz+1nDeazQPDdHwKr2wdNff
yBBG+3jstDdiwr9uGjRA39gpu/29JVE0Kxd9aMyOorW48RYX6wGcfbg1nGYkOO0u
haY0pWG4g+0=
=q6Yg
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar 22 16:02:07 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 22 Mar 2008 11:02:07 -0400
Subject: [Python-3000] [Python-Dev]   Python source code on Bazaar vcs
In-Reply-To: <79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
Message-ID: <3EE240A4-8265-45A2-AEB8-2D53B21AEBEE@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 21, 2008, at 5:28 PM, Paul Moore wrote:
>
> One thing I really like the idea of with Mercurial for my situation
> (non-committer) is the mq extension, which lets me manage my changes
> as a "stack of patches" - so I'm completely working with patches,
> which is what I have to post to the tracker, etc.
>
> Is there a similar workflow in Bazaar? I know there's the loom
> extension (although I haven't used it much yet) but I'm not sure how
> I'd use that.

Yes, looms are awesome, I highly recommend you install the plugin and  
take a look.  There's a link to the loom plugin on <http://www.python.org/dev/bazaar 
 >.

I don't know much about Mercurial queues, but I've been told the  
feature is similar. I do have a lot of experience using Bazaar looms,  
and I'm a huge fan.

> Basically, can some Bazaar expert offer a suggestion as to how a
> non-developer with read-only access would best use the Bazaar
> repositories to maintain a number of patches to be posted to the
> tracker?

I used it in Mailman work all the time, and I've been using it on the  
train home from Pycon for working on the email package in Python 3.0.   
Quick tutorial:

bzr branch http://code.python.org/python/3.0 my30feature
cd my30feature
bzr nickname upstream
bzr loomify
bzr create-thread firststuff
<hack, hack, hack>
bzr commit
bzr create-thread secondstuff
<hack, hack, hack>
bzr commit
bzr create thread thirdstuff
<hack, hack, hack>
bzr commit
bzr down-thread secondstuff
# see what's different between secondstuff and firststuff
bzr diff -r thread:

rinse-and-repeat-ly y'rs,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+Ufb3EjvBPtnXfVAQI2ywP9GLK07pVEKmfb7K3s/I7oUnw3MA6uQPML
41rUi8fJQIIejPkmsKrrchSSkp3ZeSot4btxxXYD6G+HX3yzNgK3ydijZtpofIm1
dTIreCOYE9uGS6xk2Frj58rCrDwrsZ0eADyCZ4V18pBNEwpTsDw0wLFktqx2yzhH
BZBLqUy//NM=
=cuNj
-----END PGP SIGNATURE-----

From barry at python.org  Sat Mar 22 16:21:46 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 22 Mar 2008 11:21:46 -0400
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <47DDF318.4080303@v.loewis.de>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
	<47DDF318.4080303@v.loewis.de>
Message-ID: <96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 17, 2008, at 12:27 AM, Martin v. L?wis wrote:
>> 'critical' is fine (or 'immediate').  My problem before was that I   
>> couldn't do one query that gave me all the critical issues for  
>> both  2.6 and 3.0.  That certainly could have been pebkac though.   
>> Neal  mentioned that that kind of query should be possible, if it's  
>> not  already there.
>
> I just created a "Showstoppers" public query (go to Your Queries/ 
> *edit*,
> and set it to "leave in").
>
> This *just* searches for critical open issues, all versions. Given
> that there are currently really no critical issues, that semantically
> is the same as further restricting it to 2.6 and 3.0.
>
> Creating a query that searches for multiple versions is possible
> through URL editing, but not the form (currently). I'm not sure
> whether that would search for issues which are marked both 2.6
> and 3.0, or for issues that are either marked 2.6 *or* 3.0.

Thanks Martin, I think this will work for now.  Is there any way you  
can allow me to edit this query too?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UkDnEjvBPtnXfVAQItWgP9FF++/A19BvM4+wjf8xyV2oCbMa0KH1+D
ssTdA+pnB70c06CuGNe7Wf7OEGNNmJmMtGmTcHqa5irJc/BPVlOvZ4Uj9iC9qJKe
BW0P4BoCmQ1Dtap7tPa9ACb2+b0zwPLgXG3O/0WMwkG3sdeLYm6oscWYmXcYzF2V
do1rmkIAbmw=
=ziz3
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Mar 22 16:31:15 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 22 Mar 2008 16:31:15 +0100
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
	<47DDF318.4080303@v.loewis.de>
	<96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>
Message-ID: <47E52643.1080804@v.loewis.de>

> Thanks Martin, I think this will work for now.  Is there any way you can 
> allow me to edit this query too?

Not easily.

I could just remove it, and allow you to create a new one (or you create
one yourself, anyway, and I remove mine later).

Regards,
Martin

From barry at python.org  Sat Mar 22 16:46:06 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 22 Mar 2008 11:46:06 -0400
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 project management
In-Reply-To: <47E52643.1080804@v.loewis.de>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
	<47DDF318.4080303@v.loewis.de>
	<96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>
	<47E52643.1080804@v.loewis.de>
Message-ID: <3ECA8175-85BF-4350-8856-BBAB40AC0784@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 22, 2008, at 11:31 AM, Martin v. L?wis wrote:
>> Thanks Martin, I think this will work for now.  Is there any way  
>> you can allow me to edit this query too?
>
> Not easily.
>
> I could just remove it, and allow you to create a new one (or you  
> create
> one yourself, anyway, and I remove mine later).

Naw, no need for the extra work.  Thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UpvnEjvBPtnXfVAQLHDAP/WVC9IJpGbe0RgoG/5AkWki0AioEvvrPL
2i9+wSPJYXmNz1960tpH+iehjEtkxdCHFNSbSP9BAB71ANRQXJtpxcibNvdHnF55
yWI7lM/Qt1NMYyUD4vn8HDNSMLFSQqztvkCm4OmkzhO/ZdODp4kHdUUfhn7ggC72
jzSq9Qt9eJY=
=4xE2
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Mar 22 19:07:46 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 22 Mar 2008 19:07:46 +0100
Subject: [Python-3000] urllib and bytes
Message-ID: <47E54AF2.3020403@v.loewis.de>

In porting Django, I ran into this problem:

Python 3.0a3+ (py3k:61727, Mar 22 2008, 01:44:52)
[GCC 4.2.3 (Debian 4.2.3-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> import urllib
py> urllib.quote(b"/path")
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/tmp/lib/python3.0/urllib.py", line 1161, in quote
     return ''.join(res)
   File "/tmp/lib/python3.0/urllib.py", line 1126, in __call__
     if ord(c) < 256:
TypeError: ord() expected string of length 1, but int found

The problem here is that the elements of bytes are integers,
so the quoting algorithm fails.

Is this supposed to work, ie. should urllib operate on bytes?

I think it should: an URL *is* a sequence of bytes, not
characters, and to support characters, Python would have
to support IRIs (which it currently doesn't).

It might be helpful to still accept strings as the input
of quote, but (until IRIs are implemented) restricting that
to ASCII strings.

I'm skeptical about the entire non-ASCII quoting algorithm:
why does it check for characters below 256? It seems it
attempts something similar to IRIs for characters above 256,
encoding them as UTF-8, but encodes characters below 256
as if they were latin-1 ...

Regards,
Martin

From lists at cheimes.de  Sat Mar 22 19:20:15 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 22 Mar 2008 19:20:15 +0100
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803211718r3c54ba1bud8691b6ab5c4fccc@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>	
	<47DD545D.6070300@cheimes.de>	
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>	
	<47DD613E.6090007@cheimes.de>	
	<ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>	
	<47E447A1.6070208@cheimes.de>
	<ca471dc20803211718r3c54ba1bud8691b6ab5c4fccc@mail.gmail.com>
Message-ID: <47E54DDF.50208@cheimes.de>

Guido van Rossum schrieb:
> Right. We've done this 2-stage rename before, during the great
> (sometimes known as grand) renaming, in the 1.x days.

I haven't been around during the 1.x -> 2.x days. I was still in the
dark ages (aka PHP user).

How do you want me to tackle down the PyString / PyBytes problem?

Christian

From stephen at xemacs.org  Sat Mar 22 19:51:33 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 23 Mar 2008 03:51:33 +0900
Subject: [Python-3000] Editing "public" queries in tracker [was: ... project
	management]
In-Reply-To: <96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>
References: <ca471dc20803160651h567b6bcev4b21da47a5ec5ed3@mail.gmail.com>
	<2C2D7EC7-51F2-4F4E-8127-87ACCC6F8413@python.org>
	<ca471dc20803161356r4473eb6bocf7dd034af7f2349@mail.gmail.com>
	<5E86F9D7-4421-4C57-8294-B0EC6A4EE03C@python.org>
	<47DDF318.4080303@v.loewis.de>
	<96720E99-D5A3-46B8-BBAA-88C021F24653@python.org>
Message-ID: <87abkqfv7u.fsf@uwakimon.sk.tsukuba.ac.jp>

I think this howto is of general interest to the community, but I'm
crossposting to Tracker-Discuss and redirecting discussion there.
Reply-To set.

Barry Warsaw writes:

 > Thanks Martin, I think this will work for now.  Is there any way you  
 > can allow me to edit this query too?

While as Martin says only the author can edit a query, you can (in
Roundup 1.4.2, which bugs.python.org may not have yet?) edit a copy of
that query.  (Since a query is an object, you can keep the same name
for multiple queries.  **But:** This is a doubleplusungood idea
unless you coordinate with the first author to remove one of the
versions, because there is no way to distinguish multiple queries by
the same name except whether they are editable or not.)

What I see in the edit interface at first is

Query		Include ...	Edit      Private ...
YourQuery_	<leave in>	[not yours to edit]

(where trailing _ indicates a link and <> a GUI widget).  After
setting YourQuery "leave in: yes", I see

Query		Include ...	Edit      Private ...
YourQuery_	<leave in>	edit_     <yes>		[delete]
YourQuery_	<leave in>	[not yours to edit]

ie, it looks like Roundup automatically makes a copy for you to edit.
Urk ... once I've edited it, I now see

Query		Include ...	Edit      Private ...
YourQuery_	<leave in>	edit_     <yes>		[delete]
YourQuery_	<leave in>	edit_     <yes>		[delete]
YourQuery_	<leave in>	[not yours to edit]

where one of the editables is my version, and the other a copy of the
original query You wrote.  So even the editor is likely to find it
confusing unless he renames his new version.

Also, in 1.4.2 there seems to be a bug, such that my ordinary User was
unable retire or remove the query.  For now, you may not want to do
this a lot as your sidebar will get cluttered.

I wonder if it might be a good idea to have a convention to
distinguish public queries that may be used as templates?

From guido at python.org  Sat Mar 22 21:23:12 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 22 Mar 2008 13:23:12 -0700
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <47E54DDF.50208@cheimes.de>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
	<47DD545D.6070300@cheimes.de>
	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>
	<47DD613E.6090007@cheimes.de>
	<ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>
	<47E447A1.6070208@cheimes.de>
	<ca471dc20803211718r3c54ba1bud8691b6ab5c4fccc@mail.gmail.com>
	<47E54DDF.50208@cheimes.de>
Message-ID: <ca471dc20803221323h5af29024kf0c933c245ca20f4@mail.gmail.com>

>  I haven't been around during the 1.x -> 2.x days. I was still in the
>  dark ages (aka PHP user).

:-)

>  How do you want me to tackle down the PyString / PyBytes problem?

I think it can actually be simplified. I think maintaining binary
compatibility between 2.6 and earlier versions is hopeless anyway, so
we might as well just rename PyString to PyBytes in 2.6 and 3.0, and
have an extra set of macros so that code using PyString needs to be
recompiled but not otherwise touched. E.g.

typedef { ... } PyBytesObject;
#define PyStringObject PyBytesObject

... PyString_Type;
#define PyBytes_Type PyString_Type

<etc>

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Sat Mar 22 21:57:21 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 22 Mar 2008 21:57:21 +0100
Subject: [Python-3000] [Python-Dev] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803221323h5af29024kf0c933c245ca20f4@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>	<47DD545D.6070300@cheimes.de>	<ca471dc20803161032t5d81cfcdj2efef99559cac623@mail.gmail.com>	<47DD613E.6090007@cheimes.de>	<ca471dc20803161246x2873657ex60e7e5aed95aa883@mail.gmail.com>	<47E447A1.6070208@cheimes.de>	<ca471dc20803211718r3c54ba1bud8691b6ab5c4fccc@mail.gmail.com>	<47E54DDF.50208@cheimes.de>
	<ca471dc20803221323h5af29024kf0c933c245ca20f4@mail.gmail.com>
Message-ID: <47E572B1.5030202@v.loewis.de>

> I think it can actually be simplified. I think maintaining binary
> compatibility between 2.6 and earlier versions is hopeless anyway

ABI-wise or API-wise?

I would surely hope that the 2.6 API is "mostly" compatible with the
2.5 API.

Regards,
Martin

From lists at cheimes.de  Sat Mar 22 22:09:05 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 22 Mar 2008 22:09:05 +0100
Subject: [Python-3000] 2.6 and 3.0 tasks
In-Reply-To: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
References: <ca471dc20803160823w2374407ev73d4e433ae64b579@mail.gmail.com>
Message-ID: <47E57571.5050900@cheimes.de>

Guido van Rossum schrieb:
>>  When the new buffer protocol is available in 2.6 we can start back
>>  porting bytesarray and the new IO framework.
> 
> Are these really so closely tied that they have to wait before they
> can be backported?

I've started with the backport of the bytearray type in a new branch

  svn+ssh://pythondev at svn.python.org/python/branches/trunk-bytearray

Any help is appreciated. I already solved most issues.

Open tasks:

 * fix bytearray.extend()

 * add PyString support to bytearray.fromhex

 * Add old style char buffer interface to bytearray (for codecs)

 * Add old style read write buffer interface to bytearray (for
file.readinto)

 * Fix pickle and copy support for bytearray

Christian





From asmodai at in-nomine.org  Fri Mar 21 09:42:49 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Fri, 21 Mar 2008 09:42:49 +0100
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <20080321084249.GA83712@nexus.in-nomine.org>

(To provide counterweight.)

-On [20080320 20:44], Barry Warsaw (barry at python.org) wrote:
>We have not made a decision to move to Bazaar officially, nor have we made
>a decision to even move off of Subversion.

Good, because between this now and pytz the other 63 projects I follow use
Subversion or Mercurial. 
Bazaar seems to be mostly limited to Ubuntu users and stuff Canonical does,
so the choice for a Bazaar setup next to Subversion strikes me a bit as odd.
Mercurial is also Python, distributed and with a, as far as I (can) track
things, bigger market share than Bazaar.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
The fragrance always stays in the hand that gives the rose...

From jml at mumak.net  Sat Mar 22 01:13:13 2008
From: jml at mumak.net (Jonathan Lange)
Date: Sat, 22 Mar 2008 11:13:13 +1100
Subject: [Python-3000] [Python-Dev]  Python source code on Bazaar vcs
In-Reply-To: <79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<20080321084249.GA83712@nexus.in-nomine.org>
	<bbaeab100803211350i7bb3b5e4u40a1a2b6c45d0ef1@mail.gmail.com>
	<79990c6b0803211428h2eef9fa0s1032570cdf3fe162@mail.gmail.com>
Message-ID: <d06a5cd30803211713q2f983e00j787ebe78ddd6317@mail.gmail.com>

On Sat, Mar 22, 2008 at 8:28 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>  Basically, can some Bazaar expert offer a suggestion as to how a
>  non-developer with read-only access would best use the Bazaar
>  repositories to maintain a number of patches to be posted to the
>  tracker?
>

Here's what I'd do: get Python, make a branch for my patch, hack on
the patch in the branch, then use merge --preview to generate a diff.

If you want to maintain a long-lived branch of Python with patches,
say you're maintaining a distro package, then looms are your best bet.

For those inclined to specifics, here's a near-exact example of what I would do:

# Get Python
bzr init-repo ~/src/python
cd ~/src/python
bzr branch <url_of_python_trunk>

# Make a patch
bzr branch trunk docstring-fix-bug-123456
cd docstring-fix-bug-123456
<hack hack hack>
bzr ci -m 'Correct some spelling'
<hack hack hack>
bzr ci -m 'Oops. Make sure we use US English'
<hack hack hack -- notice this doesn't belong in the branch>

# Move the unrelated work to another branch.
cd ..
bzr branch trunk testcase-add-cleanup
cd testcase-add-cleanup
bzr merge --uncommitted ../docstring-fix-bug-123456
bzr ci -m "Add addCleanup method to TestCase. Schedules a nullary
callable to be run before tearDown"

# Prepare the patches
cd ../trunk
bzr merge --preview ../docstring-fix-bug-123456 > ~/Desktop/docstring.patch
bzr merge --preview ../testcase-add-cleanup > ~/Desktop/add-cleanup.patch

Hope this helps,
jml

From mwm at mired.org  Thu Mar 20 23:02:39 2008
From: mwm at mired.org (Mike Meyer)
Date: Thu, 20 Mar 2008 18:02:39 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
Message-ID: <20080320180239.79ee5b64@bhuda.mired.org>

On Thu, 20 Mar 2008 20:51:04 +0100
"Lennart Regebro" <regebro at gmail.com> wrote:
> In many other cases, this is not how code is developed. Both within
> larger organisations and within large communities like Zope and Plone
> (and I suspect the same is true for communities such as Turbogears and
> Django), many people are instead working on the same code base at the
> same time.
> 
> So, there are many people working on the same large set of modules.
> All are using direct svn checkouts, because during development of
> their product/site they need a module and they discover bugs or add
> features to this module. They also have wildly varying experience
> levels and python knowledge.
> 
> Either all of these people and modules need to switch to 3.0 at the
> same time, which is unrealistic

Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
you can't start using 2.6 features until everyone is using it, right?
Given that a simultaneous conversion is unrealistic, you clearly
expect to have some people running on 2.6 while others are running on
2.5.

> The 2to3 strategy in that case means that everybody that wants to
> go over to 3.0 needs to have two complete development environments for
> every instance of the software that they need. Basically, for every
> website they develop, they would need one instance that runs under 2.6
> and one under 3.0.

Why? Once you've got your web site working on 3.0, what's the point of
keeping the 2.6 web site around? Yes, you need to keep the 2.6 *code*
around, but that's a different issue, dealt with below.  In
particular, what about 3.0 would makes you want to keep a 2.6 version
of the web site that doesn't apply to keeping a 2.5 version of the web
site when the world is split between 2.5 and 2.6 and you're on 2.6?

> This even though most of the code developed only would run under 3.0
> or 2.6, as it's custom for that particular website. The developer
> would then have to check out the 2.6 code in the 2.6 site, change it
> there, and test the change, and then run 2to3 copying over the code
> to the 3.0 instance, and test it there.  Basically, any sort of code
> change, no matter how minor, requires a "change -> test -> copy ->
> 2to3 -> test" dance, instead of the normal "change -> test". This
> doubles the effort of making any change.

Why the insistence on checking it on the 2.6 site? That only makes
sense if you're actually going to have it, and you haven't provided a
reason for doing so.

Sure, you don't want to check in code that breaks someones web site
who's still running on 2.6, but you can't test on their web
site. Hopefully, you have some application-specific tests that you
expect people to run to prevent that from happening, but those by
their very nature are going to be independent of any given users web
site.

And, once you split between 2.6 and 3.0, you'll want to add -3 to the
package tests to minimize breaking things for those on 3.0 when people
who aren't on 3.0 yet check them in.

Given that a more realistic original model is:

change -> application tests -> install? -> web site tests -> checkin

(or maybe you do the two tests in the opposite order.)

then someone on 3.0 with a 2.6/3.0 split would do:

change -> application tests -> install w/2to3 -> web site tests -> checkin

(with only one web site, there's no need to copy to test on the second
one).

> And since testing on the
> web often means testing with some sort of browser (zope.testbrowser
> or Selenium or the like) this means restarting a webserver before
> running the tests. Running tests this was often takes a significant
> time.

True, but it's only worse if you actually keep both versions
around. The package testing should be sufficient for the 2.6 code you
checked in? Nuts, this is better than the 2.5/2.6 split, as you know
the code checked in passed the 2.6 package tests, as you pretty much
said that those running 2.6 won't be running the tests with 2.5.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From tony.meyer at gmail.com  Thu Mar 20 07:55:09 2008
From: tony.meyer at gmail.com (Tony Meyer)
Date: Wed, 19 Mar 2008 23:55:09 -0700 (PDT)
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <18400.63795.52233.902170@montanaro-dyndns-org.local>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
Message-ID: <01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>

Hi Skip!

[Skip]
>> After the next SpamBayes release I plan to branch the code and work on
>> porting it to Python 3.0, mostly as an experiment in porting code from
>> Python 2.x to 3.x whose results I can feed back to the larger Python
>> community.

Cool :)

>> I'm curious about how best to approach the problem.

It's a guess, but I think SpamBayes supporting Python 2.2 will cause
issues with this.  I'm sure that it'll be possible to create code that
works (when 2to3'd) with Python 2.6 and Python 3.0 - maybe even 2.5 or
2.4 as well.  However, having a single version (plus 2to3'd copy) that
works with 2.2, 2.3, 2.4, 2.5, 2.6 and 3.0 seems to be asking for a
lot.

This probably belongs on spambayes-dev as much as here (although maybe
someone here will tell me that 2.2 and 3.0 will be fine), but perhaps
SpamBayes 1.2 (2.0?) could require 2.4 or 2.5?  It's obviously not a
problem for OS X/Windows people, and most *nix users running SB would
be at 2.4 by now, right?  (Or if not, unlikely to upgrade SB either?)

>> My first thought is to run as many SpamBayes apps and tests as I can with the -3 flag
>> and resolve as many problems as it finds.

(This bit in particular probably ought to be @spambayes-dev).  I think
I'll probably have some time in 2008 to actually work on SpamBayes
again (and check in all my local changes!), so sing out if you want
help with this.  I'm also quite curious, since I wrote chunks of the
code and am familiar with most of it, so it'll possibly correspond
with how well other code I have will migrate (in 2010, probably).

[Martin]
> Sure. As an exercise, I think it would be most useful if you actually
> tried to implement some strategy for SpamBayes that you think other
> projects could realistically also follow, and the report if and how
> this strategy falls short.

If you're (Skip) willing to be this methodical (even notes in SVN or a
wiki or something would be good) that would be great from my
perspective (unrelated to my SpamBayes [once-]developer status).

Cheers,
Tony

From ncoghlan at gmail.com  Sun Mar 23 11:42:09 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 23 Mar 2008 20:42:09 +1000
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
Message-ID: <47E63401.4060405@gmail.com>

Tony Meyer wrote:
> Hi Skip!
> 
> [Skip]
>>> After the next SpamBayes release I plan to branch the code and work on
>>> porting it to Python 3.0, mostly as an experiment in porting code from
>>> Python 2.x to 3.x whose results I can feed back to the larger Python
>>> community.
> 
> Cool :)
> 
>>> I'm curious about how best to approach the problem.
> 
> It's a guess, but I think SpamBayes supporting Python 2.2 will cause
> issues with this.  I'm sure that it'll be possible to create code that
> works (when 2to3'd) with Python 2.6 and Python 3.0 - maybe even 2.5 or
> 2.4 as well.  However, having a single version (plus 2to3'd copy) that
> works with 2.2, 2.3, 2.4, 2.5, 2.6 and 3.0 seems to be asking for a
> lot.

Hmm, I wonder if a 2to3 fixer could be developed to drop dead portions 
of version checks like "if sys.version_info < (2, 5):" since it knows 
version_info will also be at least (3, 0) for the produced code.

It seems like that would be a fairly powerful means of including "2.x 
only" code and have it automatically removed in the conversion to 3.0 
(e.g. by using a condition like "if sys.version_info < (3, 0):" to mark 
the 2.x specific code).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From skip at pobox.com  Sun Mar 23 13:46:56 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 23 Mar 2008 07:46:56 -0500
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
Message-ID: <18406.20800.103949.74960@montanaro-dyndns-org.local>


(Diverting from python-3000 to spambayes-dev.)

    Skip> After the next SpamBayes release I plan to branch the code and
    Skip> work on porting it to Python 3.0, mostly as an experiment in
    Skip> porting code from Python 2.x to 3.x whose results I can feed back
    Skip> to the larger Python community.

    Tony> Cool :)

    Skip> I'm curious about how best to approach the problem.

    Tony> It's a guess, but I think SpamBayes supporting Python 2.2 will
    Tony> cause issues with this.  I'm sure that it'll be possible to create
    Tony> code that works (when 2to3'd) with Python 2.6 and Python 3.0 -
    Tony> maybe even 2.5 or 2.4 as well.  However, having a single version
    Tony> (plus 2to3'd copy) that works with 2.2, 2.3, 2.4, 2.5, 2.6 and 3.0
    Tony> seems to be asking for a lot.

I'm thinking we will have to give up support for 2.2 at least.  I can't see
that continuing to support it is buying us much at this point.  There's also
the possibility of just maintaining separate 2.x and 3.x branches of the
code.  This would only affect the source distribution.  Windows users would
just get whatever we bundled in the binary installer.

    Tony> This probably belongs on spambayes-dev as much as here (although
    Tony> maybe someone here will tell me that 2.2 and 3.0 will be fine),
    Tony> but perhaps SpamBayes 1.2 (2.0?) could require 2.4 or 2.5?  It's
    Tony> obviously not a problem for OS X/Windows people, and most *nix
    Tony> users running SB would be at 2.4 by now, right?  (Or if not,
    Tony> unlikely to upgrade SB either?)

    Skip> My first thought is to run as many SpamBayes apps and tests as I
    Skip> can with the -3 flag and resolve as many problems as it finds.

    Tony> (This bit in particular probably ought to be @spambayes-dev).  I
    Tony> think I'll probably have some time in 2008 to actually work on
    Tony> SpamBayes again (and check in all my local changes!), so sing out
    Tony> if you want help with this.  I'm also quite curious, since I wrote
    Tony> chunks of the code and am familiar with most of it, so it'll
    Tony> possibly correspond with how well other code I have will migrate
    Tony> (in 2010, probably).

La La La!  I spoke briefly with Mark Hammond at PyCon.  (I think we must
have gotten interrupted at least three times by people wanting to talk to
Mark about totally unrelated topics!  He's one popular guy!)  If you have
some local changes you think are stable enough for a 1.1 release now would
be a good time to check them in.  We talked about terminating this seemingly
neverending chain alpha releases and just push 1.1 out the door (maybe a
quick beta, then 1.1 final).

    Martin> Sure. As an exercise, I think it would be most useful if you
    Martin> actually tried to implement some strategy for SpamBayes that you
    Martin> think other projects could realistically also follow, and the
    Martin> report if and how this strategy falls short.

    Tony> If you're (Skip) willing to be this methodical (even notes in SVN
    Tony> or a wiki or something would be good) that would be great from my
    Tony> perspective (unrelated to my SpamBayes [once-]developer status).

My thought would be to try and be pretty methodical with a page on either the
Python or SpamBayes wikis.  There is a page here:

    http://wiki.python.org/moin/Early2to3Migrations

with links to other software already being ported.

Skip


From regebro at gmail.com  Sun Mar 23 21:20:11 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 23 Mar 2008 21:20:11 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <20080320180239.79ee5b64@bhuda.mired.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
Message-ID: <319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>

On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <mwm at mired.org> wrote:
>  Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
>  you can't start using 2.6 features until everyone is using it, right?

No, but you can start using 2.6 before everyone is using it, since 2.6
is backwards compatible with 2.5. So you write 2.5 code, and run it
under 2.5 or 2.6. This is not possible with 3.0. You can't write 2.5
code and run it under 3.0.

>  Given that a simultaneous conversion is unrealistic, you clearly
>  expect to have some people running on 2.6 while others are running on
>  2.5.

Yes I can.

>  Why? Once you've got your web site working on 3.0, what's the point of
>  keeping the 2.6 web site around? Yes, you need to keep the 2.6 *code*
>  around, but that's a different issue, dealt with below.

Yeah, you are right about that point, except for the compilation and
the fact that you are debugging a different version of the code than
the one you are writing, which of course is highly confusing, it is
similar to having 2.5/2.6. The difference is that with 2.5/2.6 you
develop for one, and then when that works, you make sure it works on
the other. With 2.6/3.0 you have to develop both at once. You are
right that you don't have to test them at once, though.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Sun Mar 23 22:52:17 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 23 Mar 2008 22:52:17 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<47E23C60.6030306@gmail.com>	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	<47E2A69B.9080509@v.loewis.de>	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
Message-ID: <47E6D111.1030607@v.loewis.de>

Lennart Regebro wrote:
> On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <mwm at mired.org> wrote:
>>  Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
>>  you can't start using 2.6 features until everyone is using it, right?
> 
> No, but you can start using 2.6 before everyone is using it, since 2.6
> is backwards compatible with 2.5.

Maybe I'm confusing backwards and forwards compatibility again.

If you add __future__ imports to the 2.6 code, it will stop running
on 2.5. Does that make it "not backwards compatible", or "not forwards
compatible".

> So you write 2.5 code, and run it
> under 2.5 or 2.6. This is not possible with 3.0. You can't write 2.5
> code and run it under 3.0.

Right. You can't do that either if a __future__ import is added to
2.6.

> Yeah, you are right about that point, except for the compilation and
> the fact that you are debugging a different version of the code than
> the one you are writing, which of course is highly confusing, it is
> similar to having 2.5/2.6. The difference is that with 2.5/2.6 you
> develop for one, and then when that works, you make sure it works on
> the other. With 2.6/3.0 you have to develop both at once.

How so? You develop for 2.6, and then make sure it runs on 3.0 -
*exactly* the same as for 2.5/2.6.

Regards,
Martin




From martin at v.loewis.de  Sun Mar 23 22:58:09 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 23 Mar 2008 22:58:09 +0100
Subject: [Python-3000] Strategy for porting to 3.0?
In-Reply-To: <01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
References: <18400.63795.52233.902170@montanaro-dyndns-org.local>
	<01cb5bc6-3b52-49a7-94c2-3fcaa023c4ca@i7g2000prf.googlegroups.com>
Message-ID: <47E6D271.8020300@v.loewis.de>

> This probably belongs on spambayes-dev as much as here (although maybe
> someone here will tell me that 2.2 and 3.0 will be fine), but perhaps
> SpamBayes 1.2 (2.0?) could require 2.4 or 2.5?

I can't talk about 2.2, but my experience with Django suggests that
support 2.3..3.0 is feasible. It's a lot of testing, of course.

So if you still have 2.2 users, I think it would be possible to
support them. Of course, dropping 2.2 support (and perhaps 2.3
as well) would simplify the testing, and perhaps may allow removing
some quirks, before new quirks get added.

Regards,
Martin

From regebro at gmail.com  Sun Mar 23 23:12:55 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 23 Mar 2008 23:12:55 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <47E6D111.1030607@v.loewis.de>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<47E6D111.1030607@v.loewis.de>
Message-ID: <319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>

On Sun, Mar 23, 2008 at 10:52 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Lennart Regebro wrote:
>  > On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <mwm at mired.org> wrote:
>  >>  Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
>  >>  you can't start using 2.6 features until everyone is using it, right?
>  >
>  > No, but you can start using 2.6 before everyone is using it, since 2.6
>  > is backwards compatible with 2.5.
>
>  Maybe I'm confusing backwards and forwards compatibility again.
>
>  If you add __future__ imports to the 2.6 code, it will stop running
>  on 2.5. Does that make it "not backwards compatible", or "not forwards
>  compatible".

That makes it not backwards compatible, and it makes it forwards compatible.

>  Right. You can't do that either if a __future__ import is added to
>  2.6.

No, but then you can run it under 3.0.

> You develop for 2.6, and then make sure it runs on 3.0 -
> *exactly* the same as for 2.5/2.6.

Uh... no. You develop for 2.5, and then you don't do anything else. It
*will* run under 2.6. No need to check. Because it's backwards
compatible. And 3.0 is not. So it's definitely not the same. However,
if 2.6 were forwards compatible, this would be true for the 2.6 to 3.0
port.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From martin at v.loewis.de  Mon Mar 24 00:25:54 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Mar 2008 00:25:54 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	
	<47E2A69B.9080509@v.loewis.de>	
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	
	<20080320180239.79ee5b64@bhuda.mired.org>	
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>	
	<47E6D111.1030607@v.loewis.de>
	<319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
Message-ID: <47E6E702.5040207@v.loewis.de>

>>  If you add __future__ imports to the 2.6 code, it will stop running
>>  on 2.5. Does that make it "not backwards compatible", or "not forwards
>>  compatible".
> 
> That makes it not backwards compatible, and it makes it forwards compatible.

Just to get the terminology straight:

Python x.y is forwards compatible iff all programs written for Python
x.y will run on Python a.b, with a>x or a=x and b>y.

Correct?

>> You develop for 2.6, and then make sure it runs on 3.0 -
>> *exactly* the same as for 2.5/2.6.
> 
> Uh... no. You develop for 2.5, and then you don't do anything else. It
> *will* run under 2.6. No need to check. Because it's backwards
> compatible. And 3.0 is not. So it's definitely not the same. However,
> if 2.6 were forwards compatible, this would be true for the 2.6 to 3.0
> port.

There is no way on earth Python 2.6 can be forwards compatible. Even
a simple program like

open("/etc/passwd").read().decode("ascii")

will work differently (i.e. raise an exception in 3k).

AFAIR, no Python release ever was forwards-compatible, by the definition
above. It was always possible to construct programs that ran in the old
version, but changed their behavior in the new version.

Or, more precisely, 2.x.0 was "mostly" forwards compatible with 2.x.n,
except for behavior changes involving bug fixes.

Regards,
Martin


From martin at v.loewis.de  Mon Mar 24 00:36:45 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Mar 2008 00:36:45 +0100
Subject: [Python-3000] Porting Django
Message-ID: <47E6E98D.2080200@v.loewis.de>

I finished my first round of porting Django to 3.0, and summarized my
experience at

http://wiki.python.org/moin/PortingDjangoTo3k

If you have any comments, please let me know.

Regards,
Martin

From barry at python.org  Mon Mar 24 01:03:25 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 23 Mar 2008 20:03:25 -0400
Subject: [Python-3000] Porting Django
In-Reply-To: <47E6E98D.2080200@v.loewis.de>
References: <47E6E98D.2080200@v.loewis.de>
Message-ID: <BB037774-0407-4133-9DC4-764A2B913592@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 23, 2008, at 7:36 PM, Martin v. L?wis wrote:
> I finished my first round of porting Django to 3.0, and summarized my
> experience at
>
> http://wiki.python.org/moin/PortingDjangoTo3k
>
> If you have any comments, please let me know.

Note that the lowercase email package module names are available in  
Python 2.5, so I recommend its uses be renamed when Python 2.5 is your  
minimum requirement.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+bvznEjvBPtnXfVAQI8OQQAtHwh1FMdPyaaZZHhtFv7xVQcZH5p+Lcr
A1TcwgVXgsI3dT0nzbrwdjJeesyH96AuPq4FH8utEvsqH5NrM2j4qJpqgM3aHMba
C0RS7C15We5yuoklqvV0OwjNUPzYrbuSUpKOO96hXm+EhR0RQ60AmCfLFshLUsyS
b91E83GWLRM=
=STnk
-----END PGP SIGNATURE-----

From greg at krypto.org  Mon Mar 24 01:17:23 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 23 Mar 2008 17:17:23 -0700
Subject: [Python-3000] binascii.crc32 vs zlib.crc32
In-Reply-To: <ca471dc20803200002y840c081if3191f50f280ba1e@mail.gmail.com>
References: <52dc1c820803181521s5cd7e01ia29fac02740fe739@mail.gmail.com>
	<ca471dc20803200002y840c081if3191f50f280ba1e@mail.gmail.com>
Message-ID: <52dc1c820803231717v6212c79dh437c12d422fcbce4@mail.gmail.com>

trunk r61823 now compiles binascii to use zlib's crc32 rather than its own
if the zlib library is available at compile time (that should shave a
kilobyte off binascii.so on most systems).

{binascii,zlib}.crc32, zlib.adler32 and binascii.crc_hqx could all
potentially live in the hashlib module but their APIs are a notably
different as they return a number rather than a string (leaving
serialization byte order up to the user and are functions that allow passing
in the start value rather than objects that maintain an internal state to be
retrieved when done adding data.  It'd be easy enough to wrap them to have
the same API in python but that'd destroy any speed benefit.

The hashlib documentation and docstring mention that people should look at
zlib if they want crc32 or adler32.  IMHO thats enough even if zlib (or
binascii) is a "weird" place in an overly logical sense.  They're not really
the same class of hash function.

-g

On Thu, Mar 20, 2008 at 12:02 AM, Guido van Rossum <guido at python.org> wrote:

> Hm.  zlib is an odd place to find this API (unless you know way more
> about gzip than healthy :-).  Though binascii isn't much better.  I'd
> rather expect this in the vicinity of md5 and sha... Is it possible to
> tweak that C code to use the zlib version if present and the old C
> code otherwise?
>
> On Tue, Mar 18, 2008 at 3:21 PM, Gregory P. Smith <greg at krypto.org> wrote:
> > Both modules have a crc32 function.  The zlib version is faster when
> zlib
> > has been compiled optimally or about the same when zlib is old or uses
> its C
> > code.
> >
> > Should we ditch the binascii.crc32 version in py3k?
> >
> >  64bit Linux (CentOS 5.1):
> >
> > $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import binascii as
> mod'
> > 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
> >  10 loops, best of 3: 108 msec per loop
> > $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import zlib as mod'
> 'f =
> > mod.crc32' 'for x in xrange(100000): f(foo)'
> >  10 loops, best of 3: 40.5 msec per loop
> >
> > 32bit MacOS X 10.4:
> >
> > % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10'
> 'import
> > binascii as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
> >  10 loops, best of 3: 7.37e+04 usec per loop
> > % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10'
> 'import
> > zlib as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'
> >  10 loops, best of 3: 4.62e+04 usec per loop
> >
> > Removal from binascii would break things for platforms or embedded
> systems
> > wanting crc32 that don't want to include zlib.  Anyone care?
> >
> > What about 2.x?  if we remove the redundancy in py3k i guess we
> deprecate
> > binascii.crc32 and remove in 2.7?
> >
> > -gps
> >
> > _______________________________________________
> >  Python-3000 mailing list
> >  Python-3000 at python.org
> >  http://mail.python.org/mailman/listinfo/python-3000
> >  Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080323/95e38479/attachment-0001.htm 

From ncoghlan at gmail.com  Mon Mar 24 02:37:07 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 24 Mar 2008 11:37:07 +1000
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>	<47E2A69B.9080509@v.loewis.de>	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>	<20080320180239.79ee5b64@bhuda.mired.org>	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>	<47E6D111.1030607@v.loewis.de>
	<319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
Message-ID: <47E705C3.40006@gmail.com>

Lennart Regebro wrote:
> On Sun, Mar 23, 2008 at 10:52 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> You develop for 2.6, and then make sure it runs on 3.0 -
>> *exactly* the same as for 2.5/2.6.
> 
> Uh... no. You develop for 2.5, and then you don't do anything else. It
> *will* run under 2.6. No need to check. Because it's backwards
> compatible.

This is only true if you aren't using anything from 2.4 or earlier that 
was deprecated in 2.5 and then removed entirely in 2.6. For example, the 
following code snippet may work in 2.5, but gives a Syntax Error in 2.6 
(as with statements are now available without a __future__ import):

  with = self.get_something()
  self.do_action(with)

You always need to test on both to be certain of code compatibility - 
this isn't something new with the 2.6/3.0 transition. The only 
difference is that working with 3.0 currently involves a compilation step.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From regebro at gmail.com  Mon Mar 24 09:06:29 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 24 Mar 2008 09:06:29 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <20080323201832.60203a0b@bhuda.mired.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<20080323201832.60203a0b@bhuda.mired.org>
Message-ID: <319e029f0803240106j2ccf8290oc99e0eb8a4480d99@mail.gmail.com>

On Mon, Mar 24, 2008 at 1:18 AM, Mike Meyer <mwm at mired.org> wrote:
>  > under 2.5 or 2.6. This is not possible with 3.0. You can't write 2.5
>  > code and run it under 3.0.
>
>  I don't think anyone proposed writing 2.5 code to run on 3.0.

I meant to write 2.6, not 2.5.

>  It really does appear that, for such a project (and I think two of
>  mine - python-xlib & plwm - qualify) 2.5->2.6 and 2.6->3.0 aren't that
>  far apart. You can write code for the old version, and run it (with
>  suitable preprocessing) on the new version. You can't use features
>  available in the new version until everyone is off the old version.

Note how this is libraries with a small set of developers and a well
defined API that gets released on (ir)regular intervals and whos users
use the release. Just the type of project I many times agreed 2to3
will work well on.

>  Um, I hate to tell you this, but the vast majority of programmers
>  debug a different version of the code than they write, because they
>  are using a compiled language. They write in a nice character based
>  language like C, but then debug a binary machine code. Yeah, smart
>  compilers and debuggers help, by building a mapping from the machine
>  code back to the character code, and then using it so it looks like
>  you're debugging the character code.
>
>  Which brings up a feature request for 2to3/3.0: the ability to leave
>  cookies in the 3.0 file that "smart" debuggers can use to help with
>  debugging code from 2to3? At the very least, each time a line is
>  changed, the ability to add a comment with the original line and the
>  file and line number it came from.

A complicated solution for a problem that isn't necessary, and only
solves it if you are using a smart debugger...

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From regebro at gmail.com  Mon Mar 24 09:08:41 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 24 Mar 2008 09:08:41 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <20080323204906.0d540bc1@bhuda.mired.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<47E6D111.1030607@v.loewis.de>
	<319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
	<20080323204906.0d540bc1@bhuda.mired.org>
Message-ID: <319e029f0803240108t31c777dwf423d4f7710af95c@mail.gmail.com>

On Mon, Mar 24, 2008 at 1:49 AM, Mike Meyer <mwm at mired.org> wrote:
>  This is, to be blunt, wishful thinking.

Funny. 8 years of Python development experience is wishful thinking.
Whaddayouknow.

I'm done now.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From regebro at gmail.com  Mon Mar 24 16:30:46 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 24 Mar 2008 16:30:46 +0100
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <20080324105129.1d8fc41c@bhuda.mired.org>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<20080323201832.60203a0b@bhuda.mired.org>
	<319e029f0803240106j2ccf8290oc99e0eb8a4480d99@mail.gmail.com>
	<20080324105129.1d8fc41c@bhuda.mired.org>
Message-ID: <319e029f0803240830p33f93350vf6d022f3ca86a234@mail.gmail.com>

On Mon, Mar 24, 2008 at 3:51 PM, Mike Meyer <mwm at mired.org> wrote:
>  Complicated? Really? On extra option, and an optional print when you
>  emit a line? And if you don't read the 2to3 code when debugging, or
>  don't consider yourself smart, I'd say that's your problem. Seriously,
>  the pdb 'l' command will shows you the source file when you're
>  debugging with it. Having a comment there that the code you're looking
>  at was generated by 2to3 should help avoid confusion if you decide
>  that's what needs to change.

(I said I was finished, and I am, but I'll answer this anyway, as I
evidently misunderstood what you said, and I don't want to leave my
misunderstandings as a last word, as that would misrepresent the
debate.)

You are right, it's not complicated, I misunderstood you as suggesting
that the debugger showed the orginal 2.6 code and not the the 3.0
code. Which would be complicated, but also much more useful, and it
would also make your parallell to compiled code and debugging
relevant. Indeed such a solution would remove this problem when
debugging.

But this would more or less mean that 2to3 needs to compile the 2.6
code directly to pyc-files, as I understand it.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From charles.merriam at gmail.com  Mon Mar 24 19:05:17 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Mon, 24 Mar 2008 11:05:17 -0700
Subject: [Python-3000] Enough with the u"string" already!
Message-ID: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>

OK.  54 long messages into it, the argument is stuck at:

1.  But 3.0 code is different.
2.  But 3.0 shouldn't gratuitously break 2.6 code.

So make u"sting" a deprecated structure with a warning and kill it in
3.1.  Why write a novel about it?  Just make what programmers expect
to happen happen.


Charles

From guido at python.org  Mon Mar 24 19:21:05 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 24 Mar 2008 11:21:05 -0700
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
Message-ID: <ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>

I haven't read that thread yet (and probably never will), but I want
to draw a line in the sand. In order to avoid a slippery slope, I'm
not putting backwards compatibility in 3.0 for stuff we want killed
*except* for certain exceptions that 2to3 can't fix. (The only one I
am aware of being % formatting, which will survive alongside .format()
for now.)

Hopefully this will kill the discussion.

--Guido

On Mon, Mar 24, 2008 at 11:05 AM, Charles Merriam
<charles.merriam at gmail.com> wrote:
> OK.  54 long messages into it, the argument is stuck at:
>
>  1.  But 3.0 code is different.
>  2.  But 3.0 shouldn't gratuitously break 2.6 code.
>
>  So make u"sting" a deprecated structure with a warning and kill it in
>  3.1.  Why write a novel about it?  Just make what programmers expect
>  to happen happen.
>
>
>  Charles
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From regebro at gmail.com  Mon Mar 24 19:33:39 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 24 Mar 2008 19:33:39 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>
Message-ID: <319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>

On Mon, Mar 24, 2008 at 7:21 PM, Guido van Rossum <guido at python.org> wrote:
> I haven't read that thread yet (and probably never will), but I want
>  to draw a line in the sand. In order to avoid a slippery slope, I'm
>  not putting backwards compatibility in 3.0 for stuff we want killed
>  *except* for certain exceptions that 2to3 can't fix. (The only one I
>  am aware of being % formatting, which will survive alongside .format()
>  for now.)
>
>  Hopefully this will kill the discussion.

The discussion pretty much immediately moved from u"" in 3.0 to a
__future__ import in 2.6. The rest of the discussion proved ultimately
pointless and can safely be ignored.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From guido at python.org  Mon Mar 24 19:56:03 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 24 Mar 2008 11:56:03 -0700
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
Message-ID: <ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>

On Mon, Mar 24, 2008 at 11:33 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Mar 24, 2008 at 7:21 PM, Guido van Rossum <guido at python.org> wrote:
>  > I haven't read that thread yet (and probably never will), but I want
>  >  to draw a line in the sand. In order to avoid a slippery slope, I'm
>  >  not putting backwards compatibility in 3.0 for stuff we want killed
>  >  *except* for certain exceptions that 2to3 can't fix. (The only one I
>  >  am aware of being % formatting, which will survive alongside .format()
>  >  for now.)
>  >
>  >  Hopefully this will kill the discussion.
>
>  The discussion pretty much immediately moved from u"" in 3.0 to a
>  __future__ import in 2.6. The rest of the discussion proved ultimately
>  pointless and can safely be ignored.

Thanks; the __future__ import in 2.6 sounds great.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Mon Mar 24 20:38:46 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 24 Mar 2008 20:38:46 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
Message-ID: <47E80346.3050608@cheimes.de>

Guido van Rossum schrieb:
> Thanks; the __future__ import in 2.6 sounds great.

I'm working on it. However it's not as easy as we first thought.

Christian


From musiccomposition at gmail.com  Mon Mar 24 21:40:41 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 24 Mar 2008 15:40:41 -0500
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E80346.3050608@cheimes.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
	<47E80346.3050608@cheimes.de>
Message-ID: <1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:38 PM, Christian Heimes <lists at cheimes.de> wrote:

> Guido van Rossum schrieb:
> > Thanks; the __future__ import in 2.6 sounds great.
>
> I'm working on it. However it's not as easy as we first thought.

What's the problem?

>
>
> Christian
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080324/064ee5c2/attachment.htm 

From lists at cheimes.de  Mon Mar 24 23:06:34 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 24 Mar 2008 23:06:34 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>	
	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>	
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>	
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>	
	<47E80346.3050608@cheimes.de>
	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
Message-ID: <47E825EA.30607@cheimes.de>

Benjamin Peterson schrieb:
> On Mon, Mar 24, 2008 at 2:38 PM, Christian Heimes <lists at cheimes.de> wrote:
> 
>> Guido van Rossum schrieb:
>>> Thanks; the __future__ import in 2.6 sounds great.
>> I'm working on it. However it's not as easy as we first thought.
> 
> What's the problem?

Since 2.4  Python uses the AST tree to access the future flags. But the
string unicode literals require the information before the AST tree is
created.

I solved the problem using some code from Python 2.3. A patch is
available at
bzr+ssh://pythonbzr at code.python.org/python/users/christian.heimes/unicode_string_literals
It's very rough, hacky but it works. :]

from __future__ import unicode_string_literals, print_function
print(type("test"), type(u"test"), type(b"test"))

<type 'unicode'> <type 'unicode'> <type 'str'>

It doesn't work in the interactive shell yet.

Christian

From martin at v.loewis.de  Mon Mar 24 23:02:39 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Mar 2008 23:02:39 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E80346.3050608@cheimes.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
	<47E80346.3050608@cheimes.de>
Message-ID: <47E824FF.30406@v.loewis.de>

>> Thanks; the __future__ import in 2.6 sounds great.
> 
> I'm working on it. However it's not as easy as we first thought.

BTW, did you see parser.c:future_hack?

Regards,
Martin

From martin at v.loewis.de  Mon Mar 24 23:05:04 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Mar 2008 23:05:04 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E825EA.30607@cheimes.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>		<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>		<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>		<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>		<47E80346.3050608@cheimes.de>	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
	<47E825EA.30607@cheimes.de>
Message-ID: <47E82590.7060003@v.loewis.de>

> Since 2.4  Python uses the AST tree to access the future flags. But the
> string unicode literals require the information before the AST tree is
> created.

"We" should have considered that 2.5 still had to support future
statements in the parser, for the with_statement, so I think this would
have been unnecessary.

Whoever implemented "from __future__ import print_function" knew about
that, and added it were it belongs (even though the function name
has the work "hack" in it).

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Tue Mar 25 01:18:49 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 25 Mar 2008 12:18:49 +1200
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803240830p33f93350vf6d022f3ca86a234@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<20080323201832.60203a0b@bhuda.mired.org>
	<319e029f0803240106j2ccf8290oc99e0eb8a4480d99@mail.gmail.com>
	<20080324105129.1d8fc41c@bhuda.mired.org>
	<319e029f0803240830p33f93350vf6d022f3ca86a234@mail.gmail.com>
Message-ID: <47E844E9.6030508@canterbury.ac.nz>

Lennart Regebro wrote:

> I misunderstood you as suggesting
> that the debugger showed the orginal 2.6 code and not the the 3.0
> code. 
> 
> But this would more or less mean that 2to3 needs to compile the 2.6
> code directly to pyc-files, as I understand it.

Either that or Python would have to grow something
like a #line directive.

-- 
Greg

From lists at cheimes.de  Tue Mar 25 02:10:48 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 25 Mar 2008 02:10:48 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E82590.7060003@v.loewis.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>		<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>		<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>		<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>		<47E80346.3050608@cheimes.de>	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
	<47E825EA.30607@cheimes.de> <47E82590.7060003@v.loewis.de>
Message-ID: <47E85118.9000409@cheimes.de>

Martin v. L?wis schrieb:
>> Since 2.4  Python uses the AST tree to access the future flags. But the
>> string unicode literals require the information before the AST tree is
>> created.
> 
> "We" should have considered that 2.5 still had to support future
> statements in the parser, for the with_statement, so I think this would
> have been unnecessary.
> 
> Whoever implemented "from __future__ import print_function" knew about
> that, and added it were it belongs (even though the function name
> has the work "hack" in it).

I tried to use the future_hack. However there is no way to access
parser_state->p_flags in PyAST_FromNode(). I don't see a way to get the
information from the parser into the AST code. The current API has no
means to transfer the information. The flags option doesn't do the trick.

Christian

From skip at pobox.com  Tue Mar 25 04:06:23 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 24 Mar 2008 22:06:23 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <18408.27695.339064.649345@montanaro-dyndns-org.local>

    Barry> All the gory details are documented here:

    Barry>      http://www.python.org/dev/bazaar

Thanks.  I checked out, made a branch named test3, changed Makefile.pre.in
to have a test3 target, checked it in, then tried to push it:

    % pwd
    /Users/skip/src/python-bzr/test3
    % bzr push bzr+ssh://pythonbzr at code.python.org/python/users/skip/test3
    bzr: ERROR: Parent directory of bzr+ssh://pythonbzr at code.python.org/python/users/skip/test3 does not exist.
    You may supply --create-prefix to create all leading parent directories.

Did I misread the directions or do I really need the --create-prefix arg?

Skip



From mnordhoff at mattnordhoff.com  Tue Mar 25 05:24:53 2008
From: mnordhoff at mattnordhoff.com (Matt Nordhoff)
Date: Tue, 25 Mar 2008 04:24:53 +0000
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <18408.27695.339064.649345@montanaro-dyndns-org.local>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<18408.27695.339064.649345@montanaro-dyndns-org.local>
Message-ID: <47E87E95.6090500@mattnordhoff.com>

skip at pobox.com wrote:
>     Barry> All the gory details are documented here:
> 
>     Barry>      http://www.python.org/dev/bazaar
> 
> Thanks.  I checked out, made a branch named test3, changed Makefile.pre.in
> to have a test3 target, checked it in, then tried to push it:
> 
>     % pwd
>     /Users/skip/src/python-bzr/test3
>     % bzr push bzr+ssh://pythonbzr at code.python.org/python/users/skip/test3
>     bzr: ERROR: Parent directory of bzr+ssh://pythonbzr at code.python.org/python/users/skip/test3 does not exist.
>     You may supply --create-prefix to create all leading parent directories.
> 
> Did I misread the directions or do I really need the --create-prefix arg?
> 
> Skip

I don't know if there's a special setup here, but
<http://code.python.org/python/users/> doesn't list a "skip" directory
yet. You'll need to use --create-prefix to get bzr to create it.
-- 

From nnorwitz at gmail.com  Tue Mar 25 07:18:21 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 25 Mar 2008 01:18:21 -0500
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E85118.9000409@cheimes.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
	<47E80346.3050608@cheimes.de>
	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
	<47E825EA.30607@cheimes.de> <47E82590.7060003@v.loewis.de>
	<47E85118.9000409@cheimes.de>
Message-ID: <ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>

On Mon, Mar 24, 2008 at 8:10 PM, Christian Heimes <lists at cheimes.de> wrote:
> Martin v. L?wis schrieb:
>
> >> Since 2.4  Python uses the AST tree to access the future flags. But the
>  >> string unicode literals require the information before the AST tree is
>  >> created.
>  >
>  > "We" should have considered that 2.5 still had to support future
>  > statements in the parser, for the with_statement, so I think this would
>  > have been unnecessary.
>  >
>  > Whoever implemented "from __future__ import print_function" knew about
>  > that, and added it were it belongs (even though the function name
>  > has the work "hack" in it).
>
>  I tried to use the future_hack. However there is no way to access
>  parser_state->p_flags in PyAST_FromNode(). I don't see a way to get the
>  information from the parser into the AST code. The current API has no
>  means to transfer the information. The flags option doesn't do the trick.

Two options exist here:  http://bugs.python.org/issue2477
I have no plans to finish this patch off anytime soon.  But this
should be enough to make further progress.

n

From lists at cheimes.de  Tue Mar 25 12:08:32 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 25 Mar 2008 12:08:32 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>	<ca471dc20803241121w28f15d72t3f715c9c7b1b7a66@mail.gmail.com>	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>	<47E80346.3050608@cheimes.de>	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>	<47E825EA.30607@cheimes.de>
	<47E82590.7060003@v.loewis.de>	<47E85118.9000409@cheimes.de>
	<ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>
Message-ID: <47E8DD30.7040202@cheimes.de>

Neal Norwitz schrieb:
> Two options exist here:  http://bugs.python.org/issue2477
> I have no plans to finish this patch off anytime soon.  But this
> should be enough to make further progress.

Thank you very much, Neal!

I've merged your patch with mine. It works very well. The new patch is
available in my bzr branch:

bzr+ssh://pythonbzr at code.python.org/python/users/christian.heimes/unicode_string_literals/

Christian

PS: I'm starting to like bzr ;)

From schmir at gmail.com  Tue Mar 25 12:20:39 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 25 Mar 2008 12:20:39 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <47E8DD30.7040202@cheimes.de>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
	<47E80346.3050608@cheimes.de>
	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
	<47E825EA.30607@cheimes.de> <47E82590.7060003@v.loewis.de>
	<47E85118.9000409@cheimes.de>
	<ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>
	<47E8DD30.7040202@cheimes.de>
Message-ID: <932f8baf0803250420p33b89620r2a8b62b5778e117b@mail.gmail.com>

On Tue, Mar 25, 2008 at 12:08 PM, Christian Heimes <lists at cheimes.de> wrote:

> Neal Norwitz schrieb:
> > Two options exist here:  http://bugs.python.org/issue2477
> > I have no plans to finish this patch off anytime soon.  But this
> > should be enough to make further progress.
>
> Thank you very much, Neal!
>
> I've merged your patch with mine. It works very well. The new patch is
> available in my bzr branch:
>
>
> bzr+ssh://pythonbzr at code.python.org/python/users/christian.heimes/unicode_string_literals/
>

Is there a webinterface for viewing that patch?

- Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080325/4c379121/attachment.htm 

From lists at cheimes.de  Tue Mar 25 14:02:46 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 25 Mar 2008 14:02:46 +0100
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <932f8baf0803250420p33b89620r2a8b62b5778e117b@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>	<47E80346.3050608@cheimes.de>	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>	<47E825EA.30607@cheimes.de>
	<47E82590.7060003@v.loewis.de>	<47E85118.9000409@cheimes.de>	<ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>	<47E8DD30.7040202@cheimes.de>
	<932f8baf0803250420p33b89620r2a8b62b5778e117b@mail.gmail.com>
Message-ID: <47E8F7F6.4040003@cheimes.de>

Ralf Schmitt schrieb:
> Is there a webinterface for viewing that patch?

I don't know but I've appended the patch to the feature request
http://bugs.python.org/issue2477

Christian

From barry at python.org  Tue Mar 25 15:35:49 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 25 Mar 2008 10:35:49 -0400
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <18408.27695.339064.649345@montanaro-dyndns-org.local>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<18408.27695.339064.649345@montanaro-dyndns-org.local>
Message-ID: <08E8188C-AEA2-4E78-B74C-AF213757DEA0@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mar 24, 2008, at 11:06 PM, skip at pobox.com wrote:
>    Barry> All the gory details are documented here:
>
>    Barry>      http://www.python.org/dev/bazaar
>
> Thanks.  I checked out, made a branch named test3, changed  
> Makefile.pre.in
> to have a test3 target, checked it in, then tried to push it:
>
>    % pwd
>    /Users/skip/src/python-bzr/test3
>    % bzr push bzr+ssh://pythonbzr at code.python.org/python/users/skip/ 
> test3
>    bzr: ERROR: Parent directory of bzr+ssh:// 
> pythonbzr at code.python.org/python/users/skip/test3 does not exist.
>    You may supply --create-prefix to create all leading parent  
> directories.
>
> Did I misread the directions or do I really need the --create-prefix  
> arg?

You do, the first time you push a user branch because users/skip  
doesn't exist yet.  It's mentioned in the docs, but it's pretty easy  
to overlook ;).

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+kNxXEjvBPtnXfVAQJMWQP8DJrB6QbXt7O/lT2Y/CzxpuEqa09rOSGq
QxE6RDro/k4dvuwRGh3WKjo+AwKcSSTsUAp48o3O1fM7X3u54JxhtbwoEeZj7xnv
9Nw6ZCpN+DDY83QAtNjkWtSkNfRaL3K1Y4gZsnsxsIDGs3y0HV5a2n8vZh18b+gV
xfJzxu+hb/o=
=BsR5
-----END PGP SIGNATURE-----

From barry at python.org  Tue Mar 25 16:38:00 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 25 Mar 2008 11:38:00 -0400
Subject: [Python-3000] Enough with the u"string" already!
In-Reply-To: <932f8baf0803250420p33b89620r2a8b62b5778e117b@mail.gmail.com>
References: <b8c6f6c40803241105u5c4fa24epaf9c135205b1316b@mail.gmail.com>
	<319e029f0803241133v573b7961k30aace7f81f9dca5@mail.gmail.com>
	<ca471dc20803241156t6dc5e83ew5f3b38485ed0bf25@mail.gmail.com>
	<47E80346.3050608@cheimes.de>
	<1afaf6160803241340p47a14917h4678a39b216e540b@mail.gmail.com>
	<47E825EA.30607@cheimes.de> <47E82590.7060003@v.loewis.de>
	<47E85118.9000409@cheimes.de>
	<ee2a432c0803242318seae5292p4f31d9d7fa36c58e@mail.gmail.com>
	<47E8DD30.7040202@cheimes.de>
	<932f8baf0803250420p33b89620r2a8b62b5778e117b@mail.gmail.com>
Message-ID: <E2C2DCA0-44F1-46C3-8547-41431C20D222@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 25, 2008, at 7:20 AM, Ralf Schmitt wrote:
>
>
> On Tue, Mar 25, 2008 at 12:08 PM, Christian Heimes  
> <lists at cheimes.de> wrote:
> Neal Norwitz schrieb:
> > Two options exist here:  http://bugs.python.org/issue2477
> > I have no plans to finish this patch off anytime soon.  But this
> > should be enough to make further progress.
>
> Thank you very much, Neal!
>
> I've merged your patch with mine. It works very well. The new patch is
> available in my bzr branch:
>
> bzr+ssh://pythonbzr at code.python.org/python/users/christian.heimes/ 
> unicode_string_literals/
>
> Is there a webinterface for viewing that patch?

Not yet.

I plan on making loggerhead (think ViewCS for Bazaar) available on  
python.org at some point.  In the meantime, I've just registered the  
code.python.org branches with Launchpad.  See

https://code.launchpad.net/python

I set these up as mirrored branches, so when the mirroring completes,  
you should be able to view diffs to the main 3 branches via  
Launchpad's loggerhead.

Christian could also register his branches there to get LP's  
loggerhead view.  That's the idea anyway. ;)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+kcWHEjvBPtnXfVAQLlBgQAmw3gcgC/38E6NW6QHDCXbdLa/ux2NOyD
uaCEyHTu1VSspXZF6NZaLcSr/b5yRmPlmB5Ck3TC75G/22xCK8te+jmJEXDv2vmT
bjP4XJKQvM7g/x642AWc75w28rDWigFvA7qur8EWrd+OytGG+24+sTQGoYA3Yj8r
7ml38pH7kO0=
=vd0D
-----END PGP SIGNATURE-----

From skip at pobox.com  Tue Mar 25 19:05:17 2008
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 25 Mar 2008 13:05:17 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <08E8188C-AEA2-4E78-B74C-AF213757DEA0@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<18408.27695.339064.649345@montanaro-dyndns-org.local>
	<08E8188C-AEA2-4E78-B74C-AF213757DEA0@python.org>
Message-ID: <18409.16093.799920.286191@montanaro-dyndns-org.local>


    >> Did I misread the directions or do I really need the --create-prefix
    >> arg?

    Barry> You do, the first time you push a user branch because users/skip
    Barry> doesn't exist yet.  It's mentioned in the docs, but it's pretty
    Barry> easy to overlook ;).

Well, I noticed the mention in .../dev/bazaar, where it reads, "the first
time you do this, you might need to add --create-prefix".  Perhaps that
should read "... you will need to ...".

It pushed fine with --create-prefix.

Thanks,

Skip

From alexander.belopolsky at gmail.com  Tue Mar 25 19:35:14 2008
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 25 Mar 2008 14:35:14 -0400
Subject: [Python-3000] Dict literal bytecode
Message-ID: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>

Python 3.0 set and dict literals produce very different bytecode:

>>> dis(lambda:{1,2,3})
  1           0 LOAD_CONST               0 (1)
              3 LOAD_CONST               1 (2)
              6 LOAD_CONST               2 (3)
              9 BUILD_SET                3
             12 RETURN_VALUE

>>> dis(lambda:{1:1,2:2,3:3})
  1           0 BUILD_MAP                3
              3 LOAD_CONST               0 (1)
              6 LOAD_CONST               0 (1)
              9 STORE_MAP
             10 LOAD_CONST               1 (2)
             13 LOAD_CONST               1 (2)
             16 STORE_MAP
             17 LOAD_CONST               2 (3)
             20 LOAD_CONST               2 (3)
             23 STORE_MAP
             24 RETURN_VALUE

I have recently proposed a patch that would make dict bytecode similar
to set.  (See http://bugs.python.org/issue2197).  I have later
realized that a similar idea has been proposed before
(http://bugs.python.org/issue402227) and rejected because it slowed
down pybench dict creation benchmark.  However, in my tests (on Linux
and Mac OS X) my patch gives a slight improvement 1-2% on the same
benchmark.

Two other issues have been raised with respect to my proposal:

1. The patch "changes semantics by executing all of the stores after the inputs
are generated."

2. All of the pending item pairs get built-up on an ever-growing stack
instead of
being consumed pairwise.

I have promised to think some more about these issues and here are my thoughts:

1. The only case I can think of when the change of semantics would be
noticeable is when keys have custom comparison/hash methods with
side-effects.  I doubt this can be an issue in real life and I don't
think python makes any guarantees in this respect.  If, however, it is
desirable to have this order specified (note that we are not talking
about the order of insertions, which is preserved, but whether keys
are created between insertions or before the first insertion) than it
is hard to justify the difference between set and dict literals
semantics.

2.  If I understand correctly how the code works, frame stack does not
grow during code execution.  The required stack size is precomputed
during calculation and the necessary array is allocated during
execution.  So the growing stack should not slow things down.  With
respect to memory usage, note that the frame stack allocation is
transient  while bytecode is loaded permanently.  In some applications
bytecode size reduction may be more important (in terms of peak memory
usage) than stack size increase for some frames.

There are further optimizations that I would like to try once this
issue is resolved.  (These optimizations are not strictly speaking
dependent on the acceptance of my patch, but a unification of dict and
set literals would make the coding easier.)   I understand that the
idea of making set literal produce a frozenset was accepted
<http://mail.python.org/pipermail/python-3000/2008-January/011814.html>.
 Once that is implemented, it will be natural to fold constant set
literals in the peephole optimizer.   While a similar optimization
will not be immediately available for (mutable) dictionaries, the
following approach is conceivable: for the dicts with constant keys,
push a frozen set of keys constant on the stack preceded by the values
in the order that they will be stored in the hash table.  Indicate
this situation with a -1 argument to BUILD_MAP (the size of the
dictionary will be inferred from the size of the frozenset at the top
of the stack).  Now as long as the hash table implementation is
compatible between dicts and sets, dictionary creation will be a
simple copy operation with all the hard work done during compilation.

Do you think any of these ideas are worth pursuing?

From rhamph at gmail.com  Tue Mar 25 20:32:43 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 25 Mar 2008 13:32:43 -0600
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
Message-ID: <aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>

On Tue, Mar 25, 2008 at 12:35 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> Python 3.0 set and dict literals produce very different bytecode:
>
>  >>> dis(lambda:{1,2,3})
>   1           0 LOAD_CONST               0 (1)
>               3 LOAD_CONST               1 (2)
>               6 LOAD_CONST               2 (3)
>               9 BUILD_SET                3
>              12 RETURN_VALUE
>
>  >>> dis(lambda:{1:1,2:2,3:3})
>   1           0 BUILD_MAP                3
>               3 LOAD_CONST               0 (1)
>               6 LOAD_CONST               0 (1)
>               9 STORE_MAP
>              10 LOAD_CONST               1 (2)
>              13 LOAD_CONST               1 (2)
>              16 STORE_MAP
>              17 LOAD_CONST               2 (3)
>              20 LOAD_CONST               2 (3)
>              23 STORE_MAP
>              24 RETURN_VALUE
>
>  I have recently proposed a patch that would make dict bytecode similar
>  to set.  (See http://bugs.python.org/issue2197).  I have later
>  realized that a similar idea has been proposed before
>  (http://bugs.python.org/issue402227) and rejected because it slowed
>  down pybench dict creation benchmark.  However, in my tests (on Linux
>  and Mac OS X) my patch gives a slight improvement 1-2% on the same
>  benchmark.
>
>  Two other issues have been raised with respect to my proposal:
>
>  1. The patch "changes semantics by executing all of the stores after the inputs
>  are generated."
>
>  2. All of the pending item pairs get built-up on an ever-growing stack
>  instead of
>  being consumed pairwise.
>
>  I have promised to think some more about these issues and here are my thoughts:
>
>  1. The only case I can think of when the change of semantics would be
>  noticeable is when keys have custom comparison/hash methods with
>  side-effects.  I doubt this can be an issue in real life and I don't
>  think python makes any guarantees in this respect.  If, however, it is
>  desirable to have this order specified (note that we are not talking
>  about the order of insertions, which is preserved, but whether keys
>  are created between insertions or before the first insertion) than it
>  is hard to justify the difference between set and dict literals
>  semantics.
>
>  2.  If I understand correctly how the code works, frame stack does not
>  grow during code execution.  The required stack size is precomputed
>  during calculation and the necessary array is allocated during
>  execution.  So the growing stack should not slow things down.  With
>  respect to memory usage, note that the frame stack allocation is
>  transient  while bytecode is loaded permanently.  In some applications
>  bytecode size reduction may be more important (in terms of peak memory
>  usage) than stack size increase for some frames.

I worry that there might be generated code using disgustingly large
literals.  Does batch creation still work for that?


>  There are further optimizations that I would like to try once this
>  issue is resolved.  (These optimizations are not strictly speaking
>  dependent on the acceptance of my patch, but a unification of dict and
>  set literals would make the coding easier.)   I understand that the
>  idea of making set literal produce a frozenset was accepted
>  <http://mail.python.org/pipermail/python-3000/2008-January/011814.html>.
>   Once that is implemented, it will be natural to fold constant set
>  literals in the peephole optimizer.   While a similar optimization
>  will not be immediately available for (mutable) dictionaries, the
>  following approach is conceivable: for the dicts with constant keys,
>  push a frozen set of keys constant on the stack preceded by the values
>  in the order that they will be stored in the hash table.  Indicate
>  this situation with a -1 argument to BUILD_MAP (the size of the
>  dictionary will be inferred from the size of the frozenset at the top
>  of the stack).  Now as long as the hash table implementation is
>  compatible between dicts and sets, dictionary creation will be a
>  simple copy operation with all the hard work done during compilation.

Guido's support for frozenset was later withdrawn:
http://mail.python.org/pipermail/python-3000/2008-January/011868.html

In certain contexts, such as "if i in {1, 2, 3}:", you can reuse the
literal regardless of whether it's a set or a frozenset.  I don't know
if anybody has begun implementing that though.

Playing around a bit, I've found that "_x = {1, 2, 3}; x = set(_x)"
(assuming _x were precomputed) is faster for larger literals, with the
break even point at about 10.  Perhaps you could investigate that as
well?

-- 
Adam Olsen, aka Rhamphoryncus

From alexander.belopolsky at gmail.com  Tue Mar 25 21:11:27 2008
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 25 Mar 2008 16:11:27 -0400
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
Message-ID: <d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>

On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <rhamph at gmail.com> wrote:
..
>  I worry that there might be generated code using disgustingly large
>  literals.

I don't see how this would presents a bigger problem to the stack
scheme compared to the current insert as you go scheme.   Note that
for "disgustingly large" (>65535 elements) literals, the current code
does not preallocate the hash table.  This means that the hash table
may need to be reallocated during dict creation, which is certainly
more expensive than the extra stack space.

>  Does batch creation still work for that?

I don't understand.  What is "batch creation?" (If this is something
related to py2exe, then I have no idea.)

>  Guido's support for frozenset was later withdrawn:
>  http://mail.python.org/pipermail/python-3000/2008-January/011868.html
>

I missed that.  However, we peephole optimizer can still use the same
trick as I proposed for dict literals.

>  In certain contexts, such as "if i in {1, 2, 3}:", you can reuse the
>  literal regardless of whether it's a set or a frozenset.  I don't know
>  if anybody has begun implementing that though.
>

Do you suggest that peephole optimizer can detect cases when set
literal is not bound and replace it with a frozenset constant?  This
looks like a worthwhile optimization that should also work for list
literals.  At the very least the optimizer should be able to deal with
the frozenset({...}) case.

>  Playing around a bit, I've found that "_x = {1, 2, 3}; x = set(_x)"
>  (assuming _x were precomputed) is faster for larger literals, with the
>  break even point at about 10.  Perhaps you could investigate that as
>  well?

I think you mean it is faster than "x =  {1, 2, 3}."  This is exactly
the speed-up that I am hoping to exploit.  The set(_x) constructor
does not need to recompute the hash values that are already stored in
_x.

From rhamph at gmail.com  Tue Mar 25 21:26:44 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 25 Mar 2008 14:26:44 -0600
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
Message-ID: <aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>

On Tue, Mar 25, 2008 at 2:11 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  ..
>  >  I worry that there might be generated code using disgustingly large
>  >  literals.
>
>  I don't see how this would presents a bigger problem to the stack
>  scheme compared to the current insert as you go scheme.   Note that
>  for "disgustingly large" (>65535 elements) literals, the current code
>  does not preallocate the hash table.  This means that the hash table
>  may need to be reallocated during dict creation, which is certainly
>  more expensive than the extra stack space.
>
>  >  Does batch creation still work for that?
>
>  I don't understand.  What is "batch creation?" (If this is something
>  related to py2exe, then I have no idea.)

Sorry, I wasn't clear here.  I meant that there may be disgustingly
large globals that exceed some maximum size the stack allows.
Performance is not an issue as it is done only once.  Can you
confirm/disprove that the maximum size will be the same after as it
was before?

By "batch" I only mean that you load all the constants onto the stack,
then process them in a single pass, rather than loading and processing
as you go.


>  >  Guido's support for frozenset was later withdrawn:
>  >  http://mail.python.org/pipermail/python-3000/2008-January/011868.html
>  >
>
>  I missed that.  However, we peephole optimizer can still use the same
>  trick as I proposed for dict literals.
>
>
>  >  In certain contexts, such as "if i in {1, 2, 3}:", you can reuse the
>  >  literal regardless of whether it's a set or a frozenset.  I don't know
>  >  if anybody has begun implementing that though.
>  >
>
>  Do you suggest that peephole optimizer can detect cases when set
>  literal is not bound and replace it with a frozenset constant?  This
>  looks like a worthwhile optimization that should also work for list
>  literals.  At the very least the optimizer should be able to deal with
>  the frozenset({...}) case.

It does not even have to be a frozenset.  A set works just as well,
never modified by the produced bytecode.


>  >  Playing around a bit, I've found that "_x = {1, 2, 3}; x = set(_x)"
>  >  (assuming _x were precomputed) is faster for larger literals, with the
>  >  break even point at about 10.  Perhaps you could investigate that as
>  >  well?
>
>  I think you mean it is faster than "x =  {1, 2, 3}."  This is exactly
>  the speed-up that I am hoping to exploit.  The set(_x) constructor
>  does not need to recompute the hash values that are already stored in
>  _x.

Ahh, yes.


-- 
Adam Olsen, aka Rhamphoryncus

From zelbier at gmail.com  Tue Mar 25 21:42:25 2008
From: zelbier at gmail.com (Olivier Verdier)
Date: Tue, 25 Mar 2008 21:42:25 +0100
Subject: [Python-3000] lambda
Message-ID: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>

If you ask a scientist, even a computer scientist, what "lambda" means he
will invariably answer that it is a letter in the Greek alphabet. Only a few
people working with lambda calculus will think of "lambda" as being related
to a function. Many beginners (included myself) were puzzled by "lambda" the
first time they meet it. It doesn't look as clean as the rest of python
syntax where you hardly need explain what the keywords mean.

Guido once said that he hadn't found a better name. Well, I think that
almost *any* name will do better! ;-) Especially a name that emphasizes the
fact that lambda construction are in fact functions. This is what Guido
repeats over and over again: lambda is just synctactic sugar for a function
definition. Here are suggestion for a new name for lambda, which will much
better describe what it is, namely a *function*. Since function are defined
with the keyword "def" i'd suggest the following possibilities:
- ldef (local definition, or indeed, lambda definition ;-))
- idef (inline definition)
- cdef (compact definition)
- sdef (shorthand definition)
etc.
anything along theses lines will be more descriptive than "lambda" and most
newcommers will immediately guess what it is about without wading through
the manual. The python code will also be more readable for non python
specialists.

It's too late to change the name lambda in Python 2.x but why not change it
in python 3000 since this release breaks backwards compatibility anyway?

Any thoughts about that? Any ideas of other better names than "lambda"?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080325/6edfff1d/attachment.htm 

From alexander.belopolsky at gmail.com  Tue Mar 25 21:43:10 2008
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 25 Mar 2008 16:43:10 -0400
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
Message-ID: <d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>

On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <rhamph at gmail.com> wrote:

>  I meant that there may be disgustingly
>  large globals that exceed some maximum size the stack allows.

I am to aware of any hard limit on the stack size other than whatever
the limit for a contiguous in-memory array may be.


>  Can you confirm/disprove that the maximum size will be the same after as it
>  was before?
>
It is possible to design an artificial program that will have a larger
peak memory footprint with batch processing than without, but my
argument is that it is unlikely encounter such a program in the wild.


>  It does not even have to be a frozenset.  A set works just as well,
>  never modified by the produced bytecode.
>

With the current implementation, precomputed constants must be
hashable because the compiler uses a dictionary lookup in order to
eliminate duplicates.  This is of course just an implementation
detail, but it would actually be hard to work around it.

From musiccomposition at gmail.com  Tue Mar 25 21:48:06 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 25 Mar 2008 15:48:06 -0500
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
Message-ID: <1afaf6160803251348g706d512cwe780bbd3ba7f5e04@mail.gmail.com>

On Tue, Mar 25, 2008 at 3:42 PM, Olivier Verdier <zelbier at gmail.com> wrote:

> If you ask a scientist, even a computer scientist, what "lambda" means he
> will invariably answer that it is a letter in the Greek alphabet. Only a few
> people working with lambda calculus will think of "lambda" as being related
> to a function. Many beginners (included myself) were puzzled by "lambda" the
> first time they meet it. It doesn't look as clean as the rest of python
> syntax where you hardly need explain what the keywords mean.

It's actually recommended that inline functions be used anyway.

>
>
> Guido once said that he hadn't found a better name. Well, I think that
> almost *any* name will do better! ;-) Especially a name that emphasizes the
> fact that lambda construction are in fact functions. This is what Guido
> repeats over and over again: lambda is just synctactic sugar for a function
> definition. Here are suggestion for a new name for lambda, which will much
> better describe what it is, namely a *function*. Since function are defined
> with the keyword "def" i'd suggest the following possibilities:
> - ldef (local definition, or indeed, lambda definition ;-))
> - idef (inline definition)
> - cdef (compact definition)
> - sdef (shorthand definition)
> etc.

These are all abbreviations, which I find don't help much. How about just
local?

>
> anything along theses lines will be more descriptive than "lambda" and
> most newcommers will immediately guess what it is about without wading
> through the manual. The python code will also be more readable for non
> python specialists.
>
> It's too late to change the name lambda in Python 2.x but why not change
> it in python 3000 since this release breaks backwards compatibility anyway?

Yeah, probably too late.

>
>
> Any thoughts about that? Any ideas of other better names than "lambda"?
>
> Thanks!
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
>


-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080325/f1c4b43d/attachment.htm 

From g.brandl at gmx.net  Tue Mar 25 22:01:18 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 25 Mar 2008 22:01:18 +0100
Subject: [Python-3000] lambda
In-Reply-To: <1afaf6160803251348g706d512cwe780bbd3ba7f5e04@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<1afaf6160803251348g706d512cwe780bbd3ba7f5e04@mail.gmail.com>
Message-ID: <fsbp71$aq5$1@ger.gmane.org>

Benjamin Peterson schrieb:

>     Guido once said that he hadn't found a better name. Well, I think
>     that almost *any* name will do better! ;-) Especially a name that
>     emphasizes the fact that lambda construction are in fact functions.
>     This is what Guido repeats over and over again: lambda is just
>     synctactic sugar for a function definition. Here are suggestion for
>     a new name for lambda, which will much better describe what it is,
>     namely a *function*. Since function are defined with the keyword
>     "def" i'd suggest the following possibilities:
>     - ldef (local definition, or indeed, lambda definition ;-))
>     - idef (inline definition)
>     - cdef (compact definition)
>     - sdef (shorthand definition)
>     etc.
> 
> These are all abbreviations, which I find don't help much. How about 
> just local?

Please don't start this again. The past has shown that
a) there isn't a better name that everyone agrees with, and
b) there isn't a better name that Guido agrees with.

(re "local", its glaring asymmetry to "global" and "nonlocal"
makes it a non-starter.)

>     anything along theses lines will be more descriptive than "lambda"
>     and most newcommers will immediately guess what it is about without
>     wading through the manual. The python code will also be more
>     readable for non python specialists.
> 
>     It's too late to change the name lambda in Python 2.x but why not
>     change it in python 3000 since this release breaks backwards
>     compatibility anyway?
> 
> Yeah, probably too late.

Quite so. :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From rhamph at gmail.com  Tue Mar 25 22:06:48 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 25 Mar 2008 15:06:48 -0600
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
Message-ID: <aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>

On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  >  It does not even have to be a frozenset.  A set works just as well,
>  >  never modified by the produced bytecode.
>
>  With the current implementation, precomputed constants must be
>  hashable because the compiler uses a dictionary lookup in order to
>  eliminate duplicates.  This is of course just an implementation
>  detail, but it would actually be hard to work around it.

Only builtin types with literal syntax may be deemed "constant"
anyway.  I fail to see how that's relevant to my frozenset vs set
comment.

-- 
Adam Olsen, aka Rhamphoryncus

From phd at phd.pp.ru  Tue Mar 25 22:14:59 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 26 Mar 2008 00:14:59 +0300
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
Message-ID: <20080325211459.GC15586@phd.pp.ru>

On Tue, Mar 25, 2008 at 09:42:25PM +0100, Olivier Verdier wrote:
> Many beginners (included myself) were puzzled by "lambda" the
> first time they meet it. It doesn't look as clean as the rest of python

   How many beginners know the meaning of "list comprehension"?
"generator"? "tuple"?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From adlaiff6 at gmail.com  Wed Mar 26 03:04:08 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Tue, 25 Mar 2008 22:04:08 -0400
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
Message-ID: <cc7430500803251904v2fc3d3f2sbc8903f419c44b0d@mail.gmail.com>

On Tue, Mar 25, 2008 at 4:42 PM, Olivier Verdier <zelbier at gmail.com> wrote:
> If you ask a scientist, even a computer scientist, what "lambda" means he
> will invariably answer that it is a letter in the Greek alphabet. Only a few
> people working with lambda calculus will think of "lambda" as being related
> to a function. Many beginners (included myself) were puzzled by "lambda" the
> first time they meet it. It doesn't look as clean as the rest of python
> syntax where you hardly need explain what the keywords mean.

I really don't think that "some people won't get it" is a good reason
to change a symbol anyway.  Lambda is already used in plenty of other
languages, for the same idea, so if someone comes to python without
having seen lambda before, sure, they'll have to learn what it means
(they'd have to learn ldef or whatever anyway), but then they'll
understand better if they ever program in Lisp.

I also must ask, would you rather get rid of "string" too?  Last time
I heard, cats played with them and they might make up the universe.

-- 
Cheers,
Leif

From talin at acm.org  Wed Mar 26 03:01:32 2008
From: talin at acm.org (Talin)
Date: Tue, 25 Mar 2008 19:01:32 -0700
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
Message-ID: <47E9AE7C.7090408@acm.org>

Olivier Verdier wrote:
> Any thoughts about that? Any ideas of other better names than "lambda"?

A while back I created and proposed a patch that would change the syntax 
of lambda to be more like a generator expression. So instead of writing:

    lambda x: x * x

you would write:

    (x * x given x)

So for example:

    >>> (x * x given x)(2)
    4

However, the patch and the general concept were rejected. For myself, I 
thought the idea was cute, but not a huge improvement, and I'm not 
willing to spend any serious effort lobbying for it.

-- Talin

From nnorwitz at gmail.com  Wed Mar 26 07:21:04 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 25 Mar 2008 23:21:04 -0700
Subject: [Python-3000] the release gods are angry at python
Message-ID: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>

The next releases of 2.6/3.0 are planned for April 2, just over a week
from now.  There is much work that needs to be done.  The buildbots
are in a pretty sad state and the gods are seeing too much red.

  http://www.python.org/dev/buildbot/stable/
  http://www.python.org/dev/buildbot/all/

See my other mail that discusses the stable buildbots.  The criteria
for release is that all the stable buildbots are passing all the
tests.  So we really gotta get these green before Barry notices.  You
don't want to see Barry angry.  You wouldn't like him when he's angry.

I propose a code chill for new features.  Changes to doc and tests can
continue as usual.  However, only submit a new feature *after* you fix
a broken test first.  If we have to get draconian, we can start
breaking fingers when you break a test just like we do at work. :-)

Specifically tests that need some TLC are:
 * test_winsound
    - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0
 * test_threading - test_no_refcycle_through_target
    - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0
 * test_socket deadlocks and times out
    - http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0
 * test_ssl deadlocks and times out
    - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0
 * test_xmlrpc transient socket errors
    - http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0
 * test_mailbox
    - http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0
 * test_asynchat
    - http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0

Hopefully test_timeout is fixed, but that might be flaky too.  There
have been other tests that have also been flaky like  test_asynchat,
test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
test_xmlrpc_net and some of the tests that use  networking.  These all
need to be fixed so the tests are 100% reliable and only fail when
there is a real error.

There are currently no release blocker issues:
  http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=1&%40group=priority&status=1&%40action=search

There are 48 critical issues:

http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=2&%40group=priority&status=1&%40action=search

If you believe any issue should block the release, set the priority to
release blocker and assign it to me (nnorwitz).  Many of the critical
issues are those that require 2to3 fixers.  These can be checked in as
they are written.  Be sure to test them thoroughly and try to think of
all the conditions that could possibly cause the fixer to fail or do
the wrong thing.

Right now, I don't know of any reason to hold up the release other
than the failing tests.

n

From nnorwitz at gmail.com  Wed Mar 26 07:21:11 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 25 Mar 2008 23:21:11 -0700
Subject: [Python-3000] stable buildbots
Message-ID: <ee2a432c0803252321i2e6b666cubfb2c88f126bb626@mail.gmail.com>

We need to get the tests for Python to be more stable so we can push
out solid releases.  In order to achieve this result, we need tests
that are *100% reliable* and fail _only when there is a problem with
Python_.  While we aren't nearly as close to that goal as we need to
be, we have to work towards it.  The buildbots that have been more
reliable are separated onto their own page:

http://www.python.org/dev/buildbot/stable/

This is the page that should be tracked by most people.  This is the
page we will use to determine if Python is ready for release.  All
green means the release is ready to ship.  This page should *always*
show all green.  Any change that causes any buildbot to fail, should
be immediately reverted.  When you commit code, make sure to refresh
the stable buildbot page to ensure you haven't broken anything.

The stable buildbots need to represent all major platforms, at least
Windows, Mac OSX, and Linux.  All of those are currently represented
on the page along with several others.  Unfortunately some of the
tests, particularly on Windows, are not passing.  We need to get these
in better shape.  Please help out.  See my other mail for details or
use the link above to find the current set of problems.

As we fix more tests and more platforms become stable, I will add them
to the stable page.  This requires restarting the server, so I plan to
do this during quiet times when all the buildbot slaves are idle.

n

From regebro at gmail.com  Wed Mar 26 08:51:12 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 26 Mar 2008 08:51:12 +0100
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
Message-ID: <319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>

On Tue, Mar 25, 2008 at 9:42 PM, Olivier Verdier <zelbier at gmail.com> wrote:
> repeats over and over again: lambda is just synctactic sugar for a function
> definition. Here are suggestion for a new name for lambda, which will much
> better describe what it is, namely a *function*.

More specifically, an anonymous function.  Best would be if you could
just use def anonymously. And preferrably use normal return syntax:

   def(a,b): return a+b

instead of

   lambda a, b: a+b

would actually make it readable enough that I might start using it. ;)
Calling it anondef, or adef instead of just def would of course be OK too.

But as mentioned, that's probably too late. And I'm sure everybody
that actually likes lambda would hate it. :) Different mindsets there
I think.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From paul.dubois at gmail.com  Wed Mar 26 08:52:56 2008
From: paul.dubois at gmail.com (Paul Du Bois)
Date: Wed, 26 Mar 2008 00:52:56 -0700
Subject: [Python-3000] lambda
In-Reply-To: <47E9AE7C.7090408@acm.org>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<47E9AE7C.7090408@acm.org>
Message-ID: <85f6a31f0803260052w22987a1cw2c4aef5f0d4c2da4@mail.gmail.com>

> Olivier Verdier wrote:
>  > Any thoughts about that? Any ideas of other better names than "lambda"?

arc uses "fn"

On Tue, Mar 25, 2008 at 7:01 PM, Talin <talin at acm.org> wrote:
>  A while back I created and proposed a patch that would change the syntax
>  of lambda to be more like a generator expression. So instead of writing:

You can almost have it now in pure python; (or not 'almost' if you're
willing to assume cpython or give up thread safety)

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/361452

;-)

p

From ncoghlan at gmail.com  Wed Mar 26 10:21:02 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 26 Mar 2008 19:21:02 +1000
Subject: [Python-3000] lambda
In-Reply-To: <319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
Message-ID: <47EA157E.5080903@gmail.com>

Lennart Regebro wrote:
> On Tue, Mar 25, 2008 at 9:42 PM, Olivier Verdier <zelbier at gmail.com> wrote:
>> repeats over and over again: lambda is just synctactic sugar for a function
>> definition. Here are suggestion for a new name for lambda, which will much
>> better describe what it is, namely a *function*.
> 
> More specifically, an anonymous function.  Best would be if you could
> just use def anonymously. And preferrably use normal return syntax:
> 
>    def(a,b): return a+b
> 
> instead of
> 
>    lambda a, b: a+b
> 
> would actually make it readable enough that I might start using it. ;)

Some might say that the ugliness of the current syntax is a point in its 
favour ;)

The code will almost always become more readable and self-documenting if 
the function is given a name.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From regebro at gmail.com  Wed Mar 26 10:33:49 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 26 Mar 2008 10:33:49 +0100
Subject: [Python-3000] lambda
In-Reply-To: <47EA157E.5080903@gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
Message-ID: <319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>

On Wed, Mar 26, 2008 at 10:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>  Some might say that the ugliness of the current syntax is a point in its
>  favour ;)

Well, it stops people using it. That's good. :)

>  The code will almost always become more readable and self-documenting if
>  the function is given a name.

Yup.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From zelbier at gmail.com  Wed Mar 26 11:32:47 2008
From: zelbier at gmail.com (Olivier Verdier)
Date: Wed, 26 Mar 2008 11:32:47 +0100
Subject: [Python-3000] lambda
In-Reply-To: <319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
Message-ID: <b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>

There is a dislike of the lambda construction that I just don't understand.
Lambda is very practical in all sorts of situations, like: lambda x,y: x+y.
I just find the name plain silly, that's all. Perhaps you think that all
python programmers or beginners have a LISP background, but that's just not
the case. For me and my mathematician colleagues, lambda is just a letter of
the greek language. Imagine you see something like that in a code:

omicron x, y: x+y

What would you think this means?? As Paul suggests, "fn" would be better.
Anything that suggests "definition" or "function" would work.

Python has a very clear syntax and is increasingly used instead of
pseudo-code in text books. Some of you seem not to be aware of the clarity
of the language. List comprehensions, and strings are all very clear for
beginners (the name "string" is not needed to understand: x = "message").
Reading a python code is a pleasure, *even for one not versed in python*.
This is a crucial advantage of the language. "lambda" is not as clear as the
rest of the language. I hope you understand my point.

I thought that the upcoming of python 3000 would be a good opportunity to
change this name but since few or no python beginners or newcommers are
reading this mailing list I don't think that I will get a lot of support
here. :-)

Thanks for reading my ramblings anyway.

== Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080326/f81b0b9d/attachment-0001.htm 

From regebro at gmail.com  Wed Mar 26 11:56:20 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 26 Mar 2008 11:56:20 +0100
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
Message-ID: <319e029f0803260356i331765d9p5c2f848720607d80@mail.gmail.com>

On Wed, Mar 26, 2008 at 11:32 AM, Olivier Verdier <zelbier at gmail.com> wrote:
> Python has a very clear syntax

Yup. Except the lambda statement of course. :)
(And the clarity of list comprehensions is debateble, but I used them
anyway, because they are dead practical, even though it hurts my
readability nerve. :-) )

Which I guess shows that fanatical adherence to readability isn't
always such a hot idea.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From facundobatista at gmail.com  Wed Mar 26 13:14:21 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 26 Mar 2008 09:14:21 -0300
Subject: [Python-3000] [Python-Dev] stable buildbots
In-Reply-To: <ee2a432c0803252321i2e6b666cubfb2c88f126bb626@mail.gmail.com>
References: <ee2a432c0803252321i2e6b666cubfb2c88f126bb626@mail.gmail.com>
Message-ID: <e04bdf310803260514g6352a578v339abe22e06c6d94@mail.gmail.com>

2008/3/26, Neal Norwitz <nnorwitz at gmail.com>:

> We need to get the tests for Python to be more stable so we can push
>  out solid releases.  In order to achieve this result, we need tests
>  that are *100% reliable* and fail _only when there is a problem with

+1


>  Python_.  While we aren't nearly as close to that goal as we need to
>  be, we have to work towards it.  The buildbots that have been more
>  reliable are separated onto their own page:
>
>  http://www.python.org/dev/buildbot/stable/

This is for trunk or 3k?

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From skip at pobox.com  Wed Mar 26 13:07:00 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 26 Mar 2008 07:07:00 -0500
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
Message-ID: <18410.15460.389322.124982@montanaro-dyndns-org.local>

Folks,

How about we not start a complete rehash of lambda?  There was a long thread
several months (or a year?) ago about this.  At that time no useful
replacement appeared and Guido decreed the status quo would remain the
status quo.  Instead of dreaming up clever lambda replacements, maybe take a
look at the red buildbots. ;-)

Skip

From ncoghlan at gmail.com  Wed Mar 26 15:46:02 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 27 Mar 2008 00:46:02 +1000
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>	<47EA157E.5080903@gmail.com>	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
Message-ID: <47EA61AA.2030607@gmail.com>

Olivier Verdier wrote:
> There is a dislike of the lambda construction that I just don't 
> understand. Lambda is very practical in all sorts of situations, like: 
> lambda x,y: x+y. I just find the name plain silly, that's all. Perhaps 
> you think that all python programmers or beginners have a LISP 
> background, but that's just not the case. For me and my mathematician 
> colleagues, lambda is just a letter of the greek language.

I think if I come across a keyword I didn't know in a language I was 
learning, I'd look it up to find out what it means. Lambda calculus is a 
well established field of mathematics, so it's a perfectly valid name 
for the construct.

> Python has a very clear syntax and is increasingly used instead of 
> pseudo-code in text books. Some of you seem not to be aware of the 
> clarity of the language. List comprehensions, and strings are all very 
> clear for beginners (the name "string" is not needed to understand: x = 
> "message"). Reading a python code is a pleasure, *even for one not 
> versed in python*. This is a crucial advantage of the language. "lambda" 
> is not as clear as the rest of the language. I hope you understand my point.

So don't use it. Use a named function instead. Then it will be even more 
of a pleasure to read, because the name you choose will tell the reader 
what the function is for. You can even attach a docstring to make it 
really obvious.

> I thought that the upcoming of python 3000 would be a good opportunity 
> to change this name but since few or no python beginners or newcommers 
> are reading this mailing list I don't think that I will get a lot of 
> support here. :-)

For a long time, lambda functionality wasn't going to exist in Py3k at 
all. It certainly isn't going to get enough care and attention to 
warrant Guido expending the mental energy needed to arbitrarily choose a 
new name, and anyone else going through the code and docs changing it.

Python beginners and newcomers should be steered completely clear of 
anonymous functions anyway. Give you functions a name, or use one of the 
builtin callables from the operator module.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Wed Mar 26 16:09:53 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 26 Mar 2008 08:09:53 -0700
Subject: [Python-3000] lambda
In-Reply-To: <47EA61AA.2030607@gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EA61AA.2030607@gmail.com>
Message-ID: <ca471dc20803260809s70b6465cheb6a897eab83dfb3@mail.gmail.com>

What is this discussion doing in python-3000? Please move it to python-ideas.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From alexander.belopolsky at gmail.com  Wed Mar 26 16:18:29 2008
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 26 Mar 2008 11:18:29 -0400
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
Message-ID: <d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>

On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <rhamph at gmail.com> wrote:
> On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
>
> <alexander.belopolsky at gmail.com> wrote:
>
> > On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <rhamph at gmail.com> wrote:
>
> >  >  It does not even have to be a frozenset.  A set works just as well,
>  >  >  never modified by the produced bytecode.
>  >
>  >  With the current implementation, precomputed constants must be
>  >  hashable because the compiler uses a dictionary lookup in order to
>  >  eliminate duplicates.  This is of course just an implementation
>  >  detail, but it would actually be hard to work around it.
>
>  Only builtin types with literal syntax may be deemed "constant"
>  anyway.  I fail to see how that's relevant to my frozenset vs set
>  comment.

I realized that right after I hit the "send" button, so my comment
about optimizing
frozenset({...}) was wrong.  With respect to frozenset vs set comment,
I understand
your proposal as transforming current

>>> dis(lambda: i in {1,2,3})
  1           0 LOAD_GLOBAL              0 (i)
              3 LOAD_CONST               0 (1)
              6 LOAD_CONST               1 (2)
              9 LOAD_CONST               2 (3)
             12 BUILD_SET                3
             15 COMPARE_OP               6 (in)
             18 RETURN_VALUE


to

  1           0 LOAD_GLOBAL              0 (i)
              3 LOAD_CONST               3 ({1, 2, 3})
              6 COMPARE_OP               6 (in)
              9 RETURN_VALUE

This will not work because {1, 2, 3} is not hashable, but it should be
possible to do

  1           0 LOAD_GLOBAL              0 (i)
              3 LOAD_CONST               3 (frozenset({1, 2, 3}))
              6 COMPARE_OP               6 (in)
              9 RETURN_VALUE


On the other hand, our dialog is increasingly off-topic.  My original
question was whether or not it will be a good idea to unify how set
and dict literals are processed.  Please comment on the following
options:

1. Do nothing: dicts are built incrementally, and sets in batch.
2. Implement batch processing for dict literals.
3. Implement incremental processing for sets.

My order of preference is 2, 1, 3.

From theller at ctypes.org  Wed Mar 26 16:30:34 2008
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 26 Mar 2008 16:30:34 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
Message-ID: <fsdq6u$vp6$1@ger.gmane.org>

Neal Norwitz schrieb:
> The next releases of 2.6/3.0 are planned for April 2, just over a week
> from now.  There is much work that needs to be done.  The buildbots
> are in a pretty sad state and the gods are seeing too much red.
> 
>   http://www.python.org/dev/buildbot/stable/
>   http://www.python.org/dev/buildbot/all/
> 
> See my other mail that discusses the stable buildbots.  The criteria
> for release is that all the stable buildbots are passing all the
> tests.  So we really gotta get these green before Barry notices.  You
> don't want to see Barry angry.  You wouldn't like him when he's angry.
> 
> I propose a code chill for new features.  Changes to doc and tests can
> continue as usual.  However, only submit a new feature *after* you fix
> a broken test first.  If we have to get draconian, we can start
> breaking fingers when you break a test just like we do at work. :-)
> 
> Specifically tests that need some TLC are:
>  * test_winsound
>     - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0

test_winsound on this buildbot only passes when I have an open remote desktop
connection to the (virtual) machine.  I have not found any other way to make these
tests pass (I tried 'net stop beep', disabling the sound driver, removing the
sound driver, disconnecting the hosts sound driver, and maybe other things).

The only other thing hat I can image would be to disable the winsound tests...

Thomas


From barry at python.org  Wed Mar 26 16:38:09 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 26 Mar 2008 11:38:09 -0400
Subject: [Python-3000] [Python-Dev] the release gods are angry at python
In-Reply-To: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
Message-ID: <86F37BB3-1545-4F68-A0B2-A7F5C09821E2@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 2:21 AM, Neal Norwitz wrote:
> The next releases of 2.6/3.0 are planned for April 2, just over a week
> from now.  There is much work that needs to be done.  The buildbots
> are in a pretty sad state and the gods are seeing too much red.
>
>  http://www.python.org/dev/buildbot/stable/
>  http://www.python.org/dev/buildbot/all/
>
> See my other mail that discusses the stable buildbots.  The criteria
> for release is that all the stable buildbots are passing all the
> tests.  So we really gotta get these green before Barry notices.  You
> don't want to see Barry angry.  You wouldn't like him when he's angry.

Of course, most people don't like me when I'm /not/ angry either! :)

Thanks for being the Bad Cop on this Neal.  Please folks, please help  
make these buildbots go green!  I think we should all be disappointed  
if the releases have to slip because our stable buildbots are red.   
Neal and I will have free rein to back out changes if that turns them  
green so if your code changes cause a failure, and you want your  
changes to stay in, please spend some time fixing them.

> I propose a code chill for new features.  Changes to doc and tests can
> continue as usual.  However, only submit a new feature *after* you fix
> a broken test first.

+1

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+pt4XEjvBPtnXfVAQKHQwP/WXCoUtJY7nq3xFExs5RCCEeWFceSBRJR
XBjymIVVODaWyhzh2obCuD/reHiEHneVWBzrS+kuQPEdigR6R4wJIyLQNqol5bfD
auDJzUAa4vrMjfJtf2+i3/GRaHPHzgwPfgyj1t5rlyE/3pLbSh+d4+qhtH8Hq0MY
ExF6WVIWRDc=
=FP2J
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Wed Mar 26 16:40:32 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 26 Mar 2008 16:40:32 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <fsdq6u$vp6$1@ger.gmane.org>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<fsdq6u$vp6$1@ger.gmane.org>
Message-ID: <fsdqpk$2h4$1@ger.gmane.org>

Thomas Heller schrieb:
> Neal Norwitz schrieb:
>> The next releases of 2.6/3.0 are planned for April 2, just over a week
>> from now.  There is much work that needs to be done.  The buildbots
>> are in a pretty sad state and the gods are seeing too much red.
>> 
>>   http://www.python.org/dev/buildbot/stable/
>>   http://www.python.org/dev/buildbot/all/
>> 
>> See my other mail that discusses the stable buildbots.  The criteria
>> for release is that all the stable buildbots are passing all the
>> tests.  So we really gotta get these green before Barry notices.  You
>> don't want to see Barry angry.  You wouldn't like him when he's angry.
>> 
>> I propose a code chill for new features.  Changes to doc and tests can
>> continue as usual.  However, only submit a new feature *after* you fix
>> a broken test first.  If we have to get draconian, we can start
>> breaking fingers when you break a test just like we do at work. :-)
>> 
>> Specifically tests that need some TLC are:
>>  * test_winsound
>>     - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0
> 
> test_winsound on this buildbot only passes when I have an open remote desktop
> connection to the (virtual) machine.  I have not found any other way to make these
> tests pass (I tried 'net stop beep', disabling the sound driver, removing the
> sound driver, disconnecting the hosts sound driver, and maybe other things).
> 
> The only other thing hat I can image would be to disable the winsound tests...

Perhaps make it an optional resource?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From theller at ctypes.org  Wed Mar 26 16:52:09 2008
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 26 Mar 2008 16:52:09 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <fsdqpk$2h4$1@ger.gmane.org>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>	<fsdq6u$vp6$1@ger.gmane.org>
	<fsdqpk$2h4$1@ger.gmane.org>
Message-ID: <fsdrfe$2iv$1@ger.gmane.org>

>> test_winsound on this buildbot only passes when I have an open remote desktop
>> connection to the (virtual) machine.  I have not found any other way to make these
>> tests pass (I tried 'net stop beep', disabling the sound driver, removing the
>> sound driver, disconnecting the hosts sound driver, and maybe other things).
>> 
>> The only other thing hat I can image would be to disable the winsound tests...
> 
> Perhaps make it an optional resource?

What I would like to see is a way to disable certain tests on certain machines;
maybe by setting environment variables?

Thomas


From lists at cheimes.de  Wed Mar 26 16:59:16 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 26 Mar 2008 16:59:16 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <fsdqpk$2h4$1@ger.gmane.org>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>	<fsdq6u$vp6$1@ger.gmane.org>
	<fsdqpk$2h4$1@ger.gmane.org>
Message-ID: <47EA72D4.8000709@cheimes.de>

Georg Brandl schrieb:
> Perhaps make it an optional resource?

In the py3k branch I've assigned the audio resource to the winsound
tests. Only regrtest.py -uall or -uaudio runs the winsound test. Reason:
the test sound was freaking out my poor cat. :/

Christian

From p.f.moore at gmail.com  Wed Mar 26 17:04:01 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 26 Mar 2008 16:04:01 +0000
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <fsdrfe$2iv$1@ger.gmane.org>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<fsdq6u$vp6$1@ger.gmane.org> <fsdqpk$2h4$1@ger.gmane.org>
	<fsdrfe$2iv$1@ger.gmane.org>
Message-ID: <79990c6b0803260904w7a8df216md8b67cbf160c6cd4@mail.gmail.com>

On 26/03/2008, Thomas Heller <theller at ctypes.org> wrote:
> What I would like to see is a way to disable certain tests on certain machines;
> maybe by setting environment variables?

Could this be done by something like the following (completely
untested!!!! no time at the moment) change to regrtest.py?

--- Lib\test\regrtest.py.orig	2008-03-26 15:36:24.519590600 +0000
+++ Lib\test\regrtest.py	2008-03-26 16:02:52.513001800 +0000
@@ -341,6 +341,12 @@
                 stdtests.remove(arg)
         nottests[:0] = args
         args = []
+
+    exclusions = os.getenv('EXCLUDE_TESTS').split()
+    for excl in exclusions:
+        if excl in stdtests:
+            stdtests.remove(excl)
+
     tests = tests or args or findtests(testdir, stdtests, nottests)
     if single:
         tests = tests[:1]

Paul.

From barry at python.org  Wed Mar 26 17:04:30 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 26 Mar 2008 12:04:30 -0400
Subject: [Python-3000] [Python-Dev] stable buildbots
In-Reply-To: <e04bdf310803260514g6352a578v339abe22e06c6d94@mail.gmail.com>
References: <ee2a432c0803252321i2e6b666cubfb2c88f126bb626@mail.gmail.com>
	<e04bdf310803260514g6352a578v339abe22e06c6d94@mail.gmail.com>
Message-ID: <D11EE454-0711-4BA5-BA4D-E87DDDB42059@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote:
> 2008/3/26, Neal Norwitz <nnorwitz at gmail.com>:
>
>> We need to get the tests for Python to be more stable so we can push
>> out solid releases.  In order to achieve this result, we need tests
>> that are *100% reliable* and fail _only when there is a problem with
>
> +1
>
>
>> Python_.  While we aren't nearly as close to that goal as we need to
>> be, we have to work towards it.  The buildbots that have been more
>> reliable are separated onto their own page:
>>
>> http://www.python.org/dev/buildbot/stable/
>
> This is for trunk or 3k?

The page has stable buildbots for trunk, 2.5, and 3.0.  I'm thinking  
that we should remove the 2.5 buildbots from the stable page.  Neal,  
if you agree, can you do that?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR+p0D3EjvBPtnXfVAQIHPgP/XxK3gSSlh4WRhJs3IGdohWvr00wGFkv4
CZOvdjxFtCoQ96kJlOGuBl8QZDpImD7xAROM+mH20IxXbhnWC5CVEXmaxOdVT412
53HZFViPKq7f0j/I7wNOSXOlmEm7lrCvOQ1afNcnkxQ7B3k2aeqBHtLiKAE4eQHZ
o04LCvyetnw=
=seJD
-----END PGP SIGNATURE-----

From rhamph at gmail.com  Wed Mar 26 17:01:38 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Wed, 26 Mar 2008 10:01:38 -0600
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
	<d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
Message-ID: <aac2c7cb0803260901p6066ebbbpf7547f2ee63d51ce@mail.gmail.com>

On Wed, Mar 26, 2008 at 9:18 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  > On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
>  >
>  > <alexander.belopolsky at gmail.com> wrote:
>  >
>  > > On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  >
>  > >  >  It does not even have to be a frozenset.  A set works just as well,
>  >  >  >  never modified by the produced bytecode.
>  >  >
>  >  >  With the current implementation, precomputed constants must be
>  >  >  hashable because the compiler uses a dictionary lookup in order to
>  >  >  eliminate duplicates.  This is of course just an implementation
>  >  >  detail, but it would actually be hard to work around it.
>  >
>  >  Only builtin types with literal syntax may be deemed "constant"
>  >  anyway.  I fail to see how that's relevant to my frozenset vs set
>  >  comment.
>
>  I realized that right after I hit the "send" button, so my comment
>  about optimizing
>  frozenset({...}) was wrong.  With respect to frozenset vs set comment,
>  I understand
>  your proposal as transforming current
>
>  >>> dis(lambda: i in {1,2,3})
>   1           0 LOAD_GLOBAL              0 (i)
>
>               3 LOAD_CONST               0 (1)
>               6 LOAD_CONST               1 (2)
>               9 LOAD_CONST               2 (3)
>              12 BUILD_SET                3
>              15 COMPARE_OP               6 (in)
>              18 RETURN_VALUE
>
>
>  to
>
>   1           0 LOAD_GLOBAL              0 (i)
>               3 LOAD_CONST               3 ({1, 2, 3})
>               6 COMPARE_OP               6 (in)
>               9 RETURN_VALUE
>
>  This will not work because {1, 2, 3} is not hashable, but it should be
>  possible to do
>
>   1           0 LOAD_GLOBAL              0 (i)
>               3 LOAD_CONST               3 (frozenset({1, 2, 3}))
>               6 COMPARE_OP               6 (in)
>               9 RETURN_VALUE

Ahh, I see!  It's "safe" to use a set, but it internally gets stuck in
a dict to intern it, which a set doesn't allow.  Fixable, but
annoying.


>  On the other hand, our dialog is increasingly off-topic.  My original
>  question was whether or not it will be a good idea to unify how set
>  and dict literals are processed.  Please comment on the following
>  options:
>
>  1. Do nothing: dicts are built incrementally, and sets in batch.
>  2. Implement batch processing for dict literals.
>  3. Implement incremental processing for sets.
>
>  My order of preference is 2, 1, 3.

IMHO, just go ahead with 2.

-- 
Adam Olsen, aka Rhamphoryncus

From nnorwitz at gmail.com  Wed Mar 26 17:29:10 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 26 Mar 2008 09:29:10 -0700
Subject: [Python-3000] [Python-Dev] stable buildbots
In-Reply-To: <D11EE454-0711-4BA5-BA4D-E87DDDB42059@python.org>
References: <ee2a432c0803252321i2e6b666cubfb2c88f126bb626@mail.gmail.com>
	<e04bdf310803260514g6352a578v339abe22e06c6d94@mail.gmail.com>
	<D11EE454-0711-4BA5-BA4D-E87DDDB42059@python.org>
Message-ID: <ee2a432c0803260929m4c46d3e3r25d92e65b6bbca23@mail.gmail.com>

On Wed, Mar 26, 2008 at 9:04 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
>  On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote:
>  > 2008/3/26, Neal Norwitz <nnorwitz at gmail.com>:
>  >
>  >> We need to get the tests for Python to be more stable so we can push
>  >> out solid releases.  In order to achieve this result, we need tests
>  >> that are *100% reliable* and fail _only when there is a problem with
>  >
>  > +1
>  >
>  >
>  >> Python_.  While we aren't nearly as close to that goal as we need to
>  >> be, we have to work towards it.  The buildbots that have been more
>  >> reliable are separated onto their own page:
>  >>
>  >> http://www.python.org/dev/buildbot/stable/
>  >
>  > This is for trunk or 3k?
>
>  The page has stable buildbots for trunk, 2.5, and 3.0.  I'm thinking
>  that we should remove the 2.5 buildbots from the stable page.  Neal,
>  if you agree, can you do that?

I'm fine with removing 2.5, but I'm not sure if it's easy.

HINT HINT.  If everyone else fixes the broken and flaky tests, I'll
have more than enough time to fix this.

n

From theller at ctypes.org  Wed Mar 26 17:39:24 2008
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 26 Mar 2008 17:39:24 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <47EA72D4.8000709@cheimes.de>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>	<fsdq6u$vp6$1@ger.gmane.org>	<fsdqpk$2h4$1@ger.gmane.org>
	<47EA72D4.8000709@cheimes.de>
Message-ID: <fsdu7o$fo1$1@ger.gmane.org>

Christian Heimes schrieb:
> Georg Brandl schrieb:
>> Perhaps make it an optional resource?
> 
> In the py3k branch I've assigned the audio resource to the winsound
> tests. Only regrtest.py -uall or -uaudio runs the winsound test. Reason:
> the test sound was freaking out my poor cat. :/

I feel with your cat ;-).
This would not help on the buildbot since it runs 'rt.bat -d -q -uall -rw'.

For now, I try to keep rdp connections open, but in the long run I'd like
to see something like Paul's suggestion.

Thomas


From musiccomposition at gmail.com  Wed Mar 26 22:10:41 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 26 Mar 2008 16:10:41 -0500
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
Message-ID: <1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>

On Wed, Mar 26, 2008 at 1:21 AM, Neal Norwitz <nnorwitz at gmail.com> wrote:

> The next releases of 2.6/3.0 are planned for April 2, just over a week
> from now.  There is much work that needs to be done.  The buildbots
> are in a pretty sad state and the gods are seeing too much red.
>
>  http://www.python.org/dev/buildbot/stable/
>  http://www.python.org/dev/buildbot/all/
>
> See my other mail that discusses the stable buildbots.  The criteria
> for release is that all the stable buildbots are passing all the
> tests.  So we really gotta get these green before Barry notices.  You
> don't want to see Barry angry.  You wouldn't like him when he's angry.
>
> I propose a code chill for new features.  Changes to doc and tests can
> continue as usual.  However, only submit a new feature *after* you fix
> a broken test first.  If we have to get draconian, we can start
> breaking fingers when you break a test just like we do at work. :-)
>
> Specifically tests that need some TLC are:
>  * test_winsound
>    -
> http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0
>  * test_threading - test_no_refcycle_through_target
>    -
> http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0
>  * test_socket deadlocks and times out
>    -
> http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0
>  * test_ssl deadlocks and times out
>    -
> http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0
>  * test_xmlrpc transient socket errors
>    -
> http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0
>  * test_mailbox
>    -
> http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0
>  * test_asynchat
>    -
> http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0
>
> Hopefully test_timeout is fixed, but that might be flaky too.  There
> have been other tests that have also been flaky like  test_asynchat,
> test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
> test_xmlrpc_net and some of the tests that use  networking.  These all
> need to be fixed so the tests are 100% reliable and only fail when
> there is a real error.
>
> There are currently no release blocker issues:
>
> http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=1&%40group=priority&status=1&%40action=search
>
> There are 48 critical issues:
>
>
> http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=2&%40group=priority&status=1&%40action=search
>
> If you believe any issue should block the release, set the priority to
> release blocker and assign it to me (nnorwitz).  Many of the critical
> issues are those that require 2to3 fixers.  These can be checked in as
> they are written.  Be sure to test them thoroughly and try to think of
> all the conditions that could possibly cause the fixer to fail or do
> the wrong thing.

There are also some backporting issues in that pile. Should those hold up
betas? (when we get there)

>
>
> Right now, I don't know of any reason to hold up the release other
> than the failing tests.
>
> n
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080326/0d8af3d1/attachment-0001.htm 

From barry at python.org  Wed Mar 26 22:26:13 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 26 Mar 2008 17:26:13 -0400
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>
Message-ID: <8E0A8347-66EF-428D-94A1-60C8F9D00388@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 5:10 PM, Benjamin Peterson wrote:

> There are also some backporting issues in that pile. Should those  
> hold up
> betas? (when we get there)

Yes, but I would simply release the monthly alpha and push the beta  
back a month.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+q/dXEjvBPtnXfVAQJYJAP9En+87NRtSOKcnEB4Om/BYE+Jw7KZ08JI
HY1MGAHleya8MHIgaEkaQf142pzfHKWxWZLNWD5UShHPlarwfvIxHdT07q5ozGda
l4J95FU2EaLMGxN+5HvxlY+pdXAiVcNAnO12TO1Gqahf9Mmk1eXkKM0p6vBPJHqZ
vtekrWIzeck=
=3v/o
-----END PGP SIGNATURE-----

From greg.ewing at canterbury.ac.nz  Thu Mar 27 00:34:37 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 27 Mar 2008 11:34:37 +1200
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
Message-ID: <47EADD8D.4090208@canterbury.ac.nz>

If this were ever to change, my preference would be to
find a syntax that doesn't use a keyword at all.

Lambdas are most useful when the body is extremely
short. But in those cases, the word 'lambda' itself
is nearly as long as the body, which destroys about
half the benefit of using it in the first place.

What's needed is something very concise and unobtrusive,
such as

   x, y => x + y

-- 
Greg

From greg.ewing at canterbury.ac.nz  Thu Mar 27 00:48:01 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 27 Mar 2008 11:48:01 +1200
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
	<d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
Message-ID: <47EAE0B1.3010900@canterbury.ac.nz>

Alexander Belopolsky wrote:

> 1. Do nothing: dicts are built incrementally, and sets in batch.
> 2. Implement batch processing for dict literals.
> 3. Implement incremental processing for sets.

My thought is that sets are the odd one out here.

Tuples are created batchwise because, being immutable,
that's the only way to do it. But if set literals are
to produce mutable objects, there's no need for them
to be created batchwise, and doing so has unfortunate
stack size and memory use consequences in the worst case.

Keep in mind that large set constructions are likely
to be done at the module level, and if the module
then goes on to call the main function of a program,
that big stack frame is going to stay around for
the life of the process.

-- 
Greg

From talin at acm.org  Thu Mar 27 05:33:11 2008
From: talin at acm.org (Talin)
Date: Wed, 26 Mar 2008 21:33:11 -0700
Subject: [Python-3000] Python 3.0 Porting Strategies
Message-ID: <47EB2387.4060502@acm.org>

We had a short discussion about Python 3.0 porting during our bi-weekly 
Python meeting at Google, and it was suggested that I write up what was 
discussed.

 From reading the Python 3000 mailing list over the last several months, 
it is apparent that there are many different approaches to making the 
transition between 2.6 and 3.0. Some of the approaches involve 
source-to-source translation using the 2to3 tool, but not all of them do.

A couple of different strategies have been discussed in this forum and 
others:

   -- Maintaining two parallel branches of the application, one for 2.6 
and one for 3.0, and using 2to3 to keep them in sync.

   -- Maintaining two parallel branches of the application, and manually 
applying fixes to both branches without synchronizing them.

   -- Using 2to3 to generate a "just in time" 3.0 version as needed, but 
doing all development work on the 2.6 branch.

There has also been some discussion of a "3to2" tool which would 
reverse-migrate code from 3.0 to 2.6. This could potentially be a much 
simpler tool than 2to3, since there are many obscure cases in 2to3 which 
it would not have to handle.

For new code, however, there is an alternative strategy that doesn't 
involve 2to3 at all, which is to write code in the "greatest common 
subset" of 2.6 and 3.0.

As Lennart Regbro pointed out earlier, this common subset is actually 
quite large (larger than Guido originally intended, I think), and you 
can write some fairly substantial applications in it. With the ability 
to turn on default unicode strings on a per-module basis, one of the 
last hurdles to effective programming in this dialect of Python has been 
removed.

Writing code in the subset dialect will take some care, however. Many 
modules in the standard library have slightly different semantics in 3.0 
as compared to 2.6. Some of these can be dealt with simply by avoiding 
legacy APIs; Others can be handled by creating a library of utility 
functions which isolate differences in the underlying Python implementation.

So, as part of the general effort to document the various 3.0 porting 
strategies, what we would like to see is:

-- A document describing the "common subset", and how to write programs 
in it. This doesn't have to be a complete standalone manual, just an 
addendum to the regular Python docs explaining what things to avoid and 
how to get around them.

-- That document could include a description of (or for extra credit, an 
implementation of) the utility library mentioned earlier, that isolates 
the difference between the two Python versions.

Any volunteers?

-- Talin

From martin at v.loewis.de  Thu Mar 27 07:09:18 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 27 Mar 2008 07:09:18 +0100
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EB2387.4060502@acm.org>
References: <47EB2387.4060502@acm.org>
Message-ID: <47EB3A0E.60008@v.loewis.de>

> For new code, however, there is an alternative strategy that doesn't 
> involve 2to3 at all, which is to write code in the "greatest common 
> subset" of 2.6 and 3.0.
> 
> As Lennart Regbro pointed out earlier, this common subset is actually 
> quite large (larger than Guido originally intended, I think), and you 
> can write some fairly substantial applications in it.

I think it's worth noting that the subset is large only for 3.0 and 2.6.
If you need to support 2.5 as well, the subset is significantly smaller;
and if you also want to support 2.4, the subset is again even smaller.

Regards,
Martin

From talin at acm.org  Thu Mar 27 07:17:31 2008
From: talin at acm.org (Talin)
Date: Wed, 26 Mar 2008 23:17:31 -0700
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EB3A0E.60008@v.loewis.de>
References: <47EB2387.4060502@acm.org> <47EB3A0E.60008@v.loewis.de>
Message-ID: <47EB3BFB.1030804@acm.org>

Martin v. L?wis wrote:
>> For new code, however, there is an alternative strategy that doesn't 
>> involve 2to3 at all, which is to write code in the "greatest common 
>> subset" of 2.6 and 3.0.
>>
>> As Lennart Regbro pointed out earlier, this common subset is actually 
>> quite large (larger than Guido originally intended, I think), and you 
>> can write some fairly substantial applications in it.
> 
> I think it's worth noting that the subset is large only for 3.0 and 2.6.
> If you need to support 2.5 as well, the subset is significantly smaller;
> and if you also want to support 2.4, the subset is again even smaller.

I'm assuming not only 2.6, but 2.6 with all of the various __future__ 
imports enabled. Anything less than that is not worth considering from a 
practical standpoint. Yes, you can avoid things like print (just don't 
call it), but you can't realistically avoid strings and exceptions in a 
non-trivial program.

> Regards,
> Martin
> 

From greg.ewing at canterbury.ac.nz  Thu Mar 27 08:13:38 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 27 Mar 2008 19:13:38 +1200
Subject: [Python-3000] lambda
In-Reply-To: <cc7430500803262208t24945a06m6b8c1254ab4d0021@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EADD8D.4090208@canterbury.ac.nz>
	<cc7430500803262208t24945a06m6b8c1254ab4d0021@mail.gmail.com>
Message-ID: <47EB4922.3090807@canterbury.ac.nz>

Leif Walsh wrote:
> On Wed, Mar 26, 2008 at 7:34 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>>   x, y => x + y
> 
> If something like this is adopted, I plead that := is chosen.

No, that would be massively confusing, since := is
an assignment operator in some languages, notably
Pascal.

The => is meant to suggest a mapping, and it resembles
notation used in mathematics and some functional
languages to denote a function.

For example, Haskell, if I remember rightly, would
write this as

   \(x, y) -> x + y

-- 
Greg

From barry at python.org  Thu Mar 27 08:33:25 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 27 Mar 2008 03:33:25 -0400
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EB3A0E.60008@v.loewis.de>
References: <47EB2387.4060502@acm.org> <47EB3A0E.60008@v.loewis.de>
Message-ID: <2D8EB58D-8C5A-43DD-A402-81F9B01F7EB2@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 27, 2008, at 2:09 AM, Martin v. L?wis wrote:
>> For new code, however, there is an alternative strategy that doesn't
>> involve 2to3 at all, which is to write code in the "greatest common
>> subset" of 2.6 and 3.0.
>>
>> As Lennart Regbro pointed out earlier, this common subset is actually
>> quite large (larger than Guido originally intended, I think), and you
>> can write some fairly substantial applications in it.
>
> I think it's worth noting that the subset is large only for 3.0 and  
> 2.6.
> If you need to support 2.5 as well, the subset is significantly  
> smaller;
> and if you also want to support 2.4, the subset is again even smaller.

And borrowing Guido's time machine (always a risky prospect), the  
subset should be larger still for 3.1 and 2.7.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+tNyHEjvBPtnXfVAQI4pAP/XjPzG+YZuDZ7LBpK/gYnmFxNSP5QqmHD
NhPaGIKVnj2bBIVIbyHm0Jl0Dw3aszih7ws5gulFx69TqZs+8320px/wE9PrNRj8
B3ryqR/ge1vDZkrMLWCi1vCKrinPR0WOgQXevxsSEHin+FlojnITB9sx2HabZB1W
gANIu0oNjdg=
=u8xx
-----END PGP SIGNATURE-----

From abpillai at gmail.com  Thu Mar 27 08:49:48 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Thu, 27 Mar 2008 13:19:48 +0530
Subject: [Python-3000] Help on builtin keywords
Message-ID: <8548c5f30803270049v19971a18ic520d16e558366cb@mail.gmail.com>

Hi,

       I recently noticed that the "help" function behaves rather
unhelpfully when one tries it on builtin keywords, as opposed
to functions.

      For example, taking the much abused "lambda", a newbie
might try to do the following to get more enlightened about lambda.

>>> help(lambda)
  File "<stdin>", line 1
    help(lambda)
               ^
SyntaxError: invalid syntax

What he gets is a very unhelpful syntax error!

Similarly for any keyword. For example, for all Python versions
before 3.0...

>>> help(exec)
  File "<stdin>", line 1
    help(exec)
            ^
SyntaxError: invalid syntax

I don't have a problem with "help" not helping out with keywords. The
problem is that it advertises itself so...

$ python3
>>> help(help)
Help on _Helper in module site:

Type help() for interactive help, or help(object) for help about object.

 So, the advertisement it gives is that it can help on any object, and
newbies to Python might interpret this as help on anything, including
keywords.

I did not check if there is a bug on this, but if the situation can be fixed
in Py3k, it would be great. I suggest that "help()" either gives a single-line
help for keywords also, or gracefully die down with a proper error string,
telling "<keyword> is a Python keyword" instead of the ugly SyntaxError.

Thanks

-- 
-Anand

From charles.merriam at gmail.com  Thu Mar 27 08:53:46 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Thu, 27 Mar 2008 00:53:46 -0700
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EB2387.4060502@acm.org>
References: <47EB2387.4060502@acm.org>
Message-ID: <b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>

On Wed, Mar 26, 2008 at 9:33 PM, Talin <talin at acm.org> wrote:
...
>  For new code, however, there is an alternative strategy that doesn't
>  involve 2to3 at all, which is to write code in the "greatest common
>  subset" of 2.6 and 3.0.
>
>  As Lennart Regbro pointed out earlier, this common subset is actually
>  quite large (larger than Guido originally intended, I think), and you
>  can write some fairly substantial applications in it.

Ok, I'll bite.  How can I write the greatest common denominator of this code:

print "Hello World!"  # yes, that needs to be Unicode.

I thought the greatest common denominator method was killed by Guido
to prevent slippery slopes.

From ncoghlan at gmail.com  Thu Mar 27 09:23:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 27 Mar 2008 18:23:21 +1000
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
References: <47EB2387.4060502@acm.org>
	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
Message-ID: <47EB5979.1040006@gmail.com>

Charles Merriam wrote:
> On Wed, Mar 26, 2008 at 9:33 PM, Talin <talin at acm.org> wrote:
> ...
>>  For new code, however, there is an alternative strategy that doesn't
>>  involve 2to3 at all, which is to write code in the "greatest common
>>  subset" of 2.6 and 3.0.
>>
>>  As Lennart Regbro pointed out earlier, this common subset is actually
>>  quite large (larger than Guido originally intended, I think), and you
>>  can write some fairly substantial applications in it.
> 
> Ok, I'll bite.  How can I write the greatest common denominator of this code:
> print "Hello World!"  # yes, that needs to be Unicode.

# This code will run on both 2.6 and 3.0
# And the string will be Unicode in both
from __future__ import unicode_literals
print "Hello World!"

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From lists at cheimes.de  Thu Mar 27 09:40:31 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 27 Mar 2008 09:40:31 +0100
Subject: [Python-3000] Help on builtin keywords
In-Reply-To: <8548c5f30803270049v19971a18ic520d16e558366cb@mail.gmail.com>
References: <8548c5f30803270049v19971a18ic520d16e558366cb@mail.gmail.com>
Message-ID: <47EB5D7F.3020200@cheimes.de>

Anand Balachandran Pillai schrieb:
> I did not check if there is a bug on this, but if the situation can be fixed
> in Py3k, it would be great. I suggest that "help()" either gives a single-line
> help for keywords also, or gracefully die down with a proper error string,
> telling "<keyword> is a Python keyword" instead of the ugly SyntaxError.

Try help("lambda")

Or try help(), keywords, lambda ;)

Christian

From lists at cheimes.de  Thu Mar 27 09:45:26 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 27 Mar 2008 09:45:26 +0100
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
References: <47EB2387.4060502@acm.org>
	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
Message-ID: <47EB5EA6.5070209@cheimes.de>

Charles Merriam schrieb:
> On Wed, Mar 26, 2008 at 9:33 PM, Talin <talin at acm.org> wrote:
> ....
>>  For new code, however, there is an alternative strategy that doesn't
>>  involve 2to3 at all, which is to write code in the "greatest common
>>  subset" of 2.6 and 3.0.
>>
>>  As Lennart Regbro pointed out earlier, this common subset is actually
>>  quite large (larger than Guido originally intended, I think), and you
>>  can write some fairly substantial applications in it.
> 
> Ok, I'll bite.  How can I write the greatest common denominator of this code:
> 
> print "Hello World!"  # yes, that needs to be Unicode.


>>> from __future__ import unicode_literals
>>> print "Hello World!" # this is unicode

>>> from __future__ import print_function
>>> print("Hello World!")

>>> ""
u''
>>> type("") is unicode
True
>>> type("") is str
False
>>> type(b"") is bytes
True
>>> type(b"") is str
True
>>> type(u"") is unicode
True

Christian

From regebro at gmail.com  Thu Mar 27 11:17:55 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 27 Mar 2008 11:17:55 +0100
Subject: [Python-3000] lambda
In-Reply-To: <47EADD8D.4090208@canterbury.ac.nz>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EADD8D.4090208@canterbury.ac.nz>
Message-ID: <319e029f0803270317t6b05efd5vb007ff2d12296dd2@mail.gmail.com>

On Thu, Mar 27, 2008 at 12:34 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
>    x, y => x + y

I know this is off topic and that we should stop, but this is actually
quite nice. Remember that one for Python 4000. ;)
-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From regebro at gmail.com  Thu Mar 27 11:52:03 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 27 Mar 2008 11:52:03 +0100
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EB2387.4060502@acm.org>
References: <47EB2387.4060502@acm.org>
Message-ID: <319e029f0803270352r245247c0o1b066790fdb4c83e@mail.gmail.com>

On Thu, Mar 27, 2008 at 5:33 AM, Talin <talin at acm.org> wrote:
>  -- A document describing the "common subset", and how to write programs
>  in it. This doesn't have to be a complete standalone manual, just an
>  addendum to the regular Python docs explaining what things to avoid and
>  how to get around them.
>
>  -- That document could include a description of (or for extra credit, an
>  implementation of) the utility library mentioned earlier, that isolates
>  the difference between the two Python versions.
>
>  Any volunteers?

I've done a buch of tests to see what works and what doesn't and how
to get around it that could serve as a starting point. Any ideas of
where to check these in?

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From skip at pobox.com  Thu Mar 27 01:52:34 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 26 Mar 2008 19:52:34 -0500
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>
Message-ID: <18410.61394.801284.968850@montanaro-dyndns-org.local>

    >> The next releases of 2.6/3.0 are planned for April 2, just over a
    >> week from now.  There is much work that needs to be done.  The
    >> buildbots are in a pretty sad state and the gods are seeing too much
    >> red.
    >> 
    >> http://www.python.org/dev/buildbot/stable/
    >> http://www.python.org/dev/buildbot/all/

Is there some reason the "g4 osx.4 trunk" buildbot isn't running?  When I
checked it this morning it was idle with two pending.  I forced a run.  I
checked later today and it showed five pending.  Now it shows 10 pending.
It looks like its last run was about 18 hours ago.  You would think by now
it would have been able to make another run.  It pings fine.

Skip

From zelbier at gmail.com  Thu Mar 27 16:22:41 2008
From: zelbier at gmail.com (Olivier Verdier)
Date: Thu, 27 Mar 2008 16:22:41 +0100
Subject: [Python-3000] lambda
In-Reply-To: <47EA61AA.2030607@gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EA61AA.2030607@gmail.com>
Message-ID: <b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>

On 26/03/2008, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> I think if I come across a keyword I didn't know in a language I was
> learning, I'd look it up to find out what it means.


Yes but it doesn't look like a keyword, does it? It looks like a letter of
the greek alphabet to me. :-) The first time I came across lambda I looked
for the definition of the variable "lambda" in the whole program and
wondered about that strange syntax: "variable x,y: x+y".

Lambda calculus is a
> well established field of mathematics, so it's a perfectly valid name
> for the construct.
>

In my university in Sweden lambda calculus is never taught neither in pure
nor applied math. It is only a part of a course in computer science applied
to linguistics. The word "lambda" however is  used all over the place as an
eigenvalue, or a wave length, or parameter, or Lam? coefficient in many of
our courses.


So don't use it. Use a named function instead. Then it will be even more
> of a pleasure to read, because the name you choose will tell the reader
> what the function is for. You can even attach a docstring to make it
> really obvious.


I don't use lambda. I never ever use it. But people use it. I am talking
about beginners in front of a code where lambda is used. I am also talking
about a beginner writing "lambda = 3." and getting a weird syntax error
message.


> I thought that the upcoming of python 3000 would be a good opportunity
> > to change this name but since few or no python beginners or newcommers
> > are reading this mailing list I don't think that I will get a lot of
> > support here. :-)
>
>
> For a long time, lambda functionality wasn't going to exist in Py3k at
> all. It certainly isn't going to get enough care and attention to
> warrant Guido expending the mental energy needed to arbitrarily choose a
> new name, and anyone else going through the code and docs changing it.
>
> Python beginners and newcomers should be steered completely clear of
> anonymous functions anyway.



They can't. lambda is used all over the place. I'm teaching python for
scientific computing and I don't teach lambda but I have to tell students
never to use the name "lambda" as a variable.

I also agree with the idea that the lambda construct should rather use a
keyword free syntax like "x -> 3*x" or something of that kind. That would be
gorgeous.

Sorry if I posted this in the wrong mailing list. I was not aware of the
python-ideas mailing list but you will sure get messages from me over there
as well. :-)

Thanks for all the responses.

== Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080327/79b94cbc/attachment.htm 

From ntoronto at cs.byu.edu  Thu Mar 27 17:19:12 2008
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Thu, 27 Mar 2008 10:19:12 -0600
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>	<47EA157E.5080903@gmail.com>	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>	<47EA61AA.2030607@gmail.com>
	<b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
Message-ID: <47EBC900.5000201@cs.byu.edu>

Olivier Verdier wrote:
> On 26/03/2008, *Nick Coghlan* <ncoghlan at gmail.com 
>     Lambda calculus is a
>     well established field of mathematics, so it's a perfectly valid name
>     for the construct.
> 
> In my university in Sweden lambda calculus is never taught neither in 
> pure nor applied math. It is only a part of a course in computer science 
> applied to linguistics. The word "lambda" however is  used all over the 
> place as an eigenvalue, or a wave length, or parameter, or Lam? 
> coefficient in many of our courses.

Yep. In my seven years of CS instruction so far, I've only come across 
this once, in a theory of programming languages course. "Lambda" simply 
doesn't show up unless you do language theory or program in a Lisp... or 
in Python.

> I also agree with the idea that the lambda construct should rather use a 
> keyword free syntax like "x -> 3*x" or something of that kind. That 
> would be gorgeous.

How about reusing "def" to make a lambda expression?

     f = def x, y: x**2 + y**2

or

     f = def(x, y): x**2 + y**2

By the time someone comes across this:

     map(def(x): x**2, lst)

in code, they've already created plenty of functions using "def", so it 
should be immediately obvious what it's doing. It's a little less terse 
than Haskell's "\->" or Greg's "=>", but not much. It also frees up a 
keyword and doesn't create a new operator-ish looking one. Lastly, I 
can't imagine that it would be *too* difficult to parse, especially the 
variation with parenthesis.

Neil


From adlaiff6 at gmail.com  Thu Mar 27 17:18:39 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Thu, 27 Mar 2008 12:18:39 -0400
Subject: [Python-3000] lambda
In-Reply-To: <47EB4922.3090807@canterbury.ac.nz>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EADD8D.4090208@canterbury.ac.nz>
	<cc7430500803262208t24945a06m6b8c1254ab4d0021@mail.gmail.com>
	<47EB4922.3090807@canterbury.ac.nz>
Message-ID: <cc7430500803270918r19401816p135c8c6eaf1a6599@mail.gmail.com>

On Thu, Mar 27, 2008 at 3:13 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Leif Walsh wrote:
>  > On Wed, Mar 26, 2008 at 7:34 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>  >
>
> >>   x, y => x + y
>  >
>  > If something like this is adopted, I plead that := is chosen.
>
>  No, that would be massively confusing, since := is
>  an assignment operator in some languages, notably
>  Pascal.

Wow, I was entirely too tired when I came up with that.  Don't pay any
attention to me.

-- 
Cheers,
Leif

From janssen at parc.com  Thu Mar 27 19:31:56 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 27 Mar 2008 11:31:56 PDT
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com> 
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
Message-ID: <08Mar27.113204pdt."58696"@synergy1.parc.xerox.com>

> There
> have been other tests that have also been flaky like  test_asynchat,
> test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
> test_xmlrpc_net and some of the tests that use  networking.

Some of the *other* tests that use networking, I think you mean.
Sounds like networking tests in general are flaky.

>     - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0

Unfortunately, this log has no information about why the test is
failing, and I do not have a Debian-unstable machine to try it on
(much less a six-processor IBM S/390 mainframe running Debian-unstable
-- cool!).  I'm unsure about how to make progress here.  It's
interesting to see that most of the stable buildbots running Debian
are doing so on big-endian (PPC, Sparc) hardware.

I also can't tell which branch of Python is being tested, from this
logfile.  That would be nice to add.  Is this 2.6 (known problems with
SSL) or 3.0 (no known problems with SSL)?  Is this information in the
logfile somewhere and I'm not seeing it?

Bill

From nnorwitz at gmail.com  Thu Mar 27 19:43:25 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 27 Mar 2008 11:43:25 -0700
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <18410.61394.801284.968850@montanaro-dyndns-org.local>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<1afaf6160803261410n4e0067a3waa779d62a4fcc777@mail.gmail.com>
	<18410.61394.801284.968850@montanaro-dyndns-org.local>
Message-ID: <ee2a432c0803271143h3e65a37enf7a23d73e2d01b39@mail.gmail.com>

On Wed, Mar 26, 2008 at 5:52 PM,  <skip at pobox.com> wrote:
>     >> The next releases of 2.6/3.0 are planned for April 2, just over a
>     >> week from now.  There is much work that needs to be done.  The
>     >> buildbots are in a pretty sad state and the gods are seeing too much
>     >> red.
>     >>
>     >> http://www.python.org/dev/buildbot/stable/
>     >> http://www.python.org/dev/buildbot/all/
>
>  Is there some reason the "g4 osx.4 trunk" buildbot isn't running?  When I
>  checked it this morning it was idle with two pending.  I forced a run.  I
>  checked later today and it showed five pending.  Now it shows 10 pending.
>  It looks like its last run was about 18 hours ago.  You would think by now
>  it would have been able to make another run.  It pings fine.

I logged in to the machine an the buildbot is running.  I think what
happens is that sometimes the master loses track of the slaves.  The
fix requires restarting the master, but I didn't want to do that last
night while there were still builds going on.  I'll try to find a
quiet time tonight and restart the master.  I expect that will fix the
problem.

n

From g.brandl at gmx.net  Thu Mar 27 20:42:37 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 27 Mar 2008 20:42:37 +0100
Subject: [Python-3000] lambda
In-Reply-To: <b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>	<47EA157E.5080903@gmail.com>	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>	<47EA61AA.2030607@gmail.com>
	<b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
Message-ID: <fsgtbh$rh7$1@ger.gmane.org>

Olivier Verdier schrieb:
> 
> 
> On 26/03/2008, *Nick Coghlan* <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
> 
>     I think if I come across a keyword I didn't know in a language I was
>     learning, I'd look it up to find out what it means. 
> 
> 
> Yes but it doesn't look like a keyword, does it? It looks like a letter 
> of the greek alphabet to me. :-) The first time I came across lambda I 
> looked for the definition of the variable "lambda" in the whole program 
> and wondered about that strange syntax: "variable x,y: x+y".

You should have used a proper highlighting editor <wink>

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From schmir at gmail.com  Thu Mar 27 22:20:01 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 27 Mar 2008 22:20:01 +0100
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
Message-ID: <932f8baf0803271420y6288e25cu65e0980822cf9b50@mail.gmail.com>

On Wed, Mar 26, 2008 at 7:21 AM, Neal Norwitz <nnorwitz at gmail.com> wrote:

>  * test_xmlrpc transient socket errors
>    -
> http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0
>
>

These are caused by the accept call returning a nonblocking socket, when the
listening socket itself is nonblocking (which it is). see
http://bugs.python.org/issue1503 for more details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080327/b54e49b0/attachment-0001.htm 

From greg.ewing at canterbury.ac.nz  Fri Mar 28 00:06:19 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 28 Mar 2008 11:06:19 +1200
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
References: <47EB2387.4060502@acm.org>
	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
Message-ID: <47EC286B.3020102@canterbury.ac.nz>

Charles Merriam wrote:
> How can I write the greatest common denominator of this code:
> 
> print "Hello World!"  # yes, that needs to be Unicode.

Something like

   from __future__ import unicode_literals
   from py3k_compat import Print

   Print("Hello World!") # yes, that indeed is Unicode.

given suitable implementations of py3k_compat for
each environment.

-- 
Greg

From eric+python-dev at trueblade.com  Fri Mar 28 01:26:30 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 27 Mar 2008 20:26:30 -0400
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EC286B.3020102@canterbury.ac.nz>
References: <47EB2387.4060502@acm.org>	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>
	<47EC286B.3020102@canterbury.ac.nz>
Message-ID: <47EC3B36.7090405@trueblade.com>

Greg Ewing wrote:
> Charles Merriam wrote:
>> How can I write the greatest common denominator of this code:
>>
>> print "Hello World!"  # yes, that needs to be Unicode.
> 
> Something like
> 
>    from __future__ import unicode_literals
>    from py3k_compat import Print
> 
>    Print("Hello World!") # yes, that indeed is Unicode.
> 
> given suitable implementations of py3k_compat for
> each environment.
> 

Am I missing something here?  What's wrong with:

$ ./python.exe
Python 2.6a1+ (trunk:61978, Mar 27 2008, 12:48:39)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from __future__ import unicode_literals
 >>> from __future__ import print_function
 >>> print('hello, world')
hello, world
 >>> type('hello, world')
<type 'unicode'>
 >>>

The only problem I see is that the __future__ import of unicode_literals 
doesn't work in 3.0 yet.  I'll look into fixing that.

Eric.

From eric+python-dev at trueblade.com  Fri Mar 28 02:09:03 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 27 Mar 2008 21:09:03 -0400
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EC3B36.7090405@trueblade.com>
References: <47EB2387.4060502@acm.org>	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>	<47EC286B.3020102@canterbury.ac.nz>
	<47EC3B36.7090405@trueblade.com>
Message-ID: <47EC452F.4060007@trueblade.com>

Eric Smith wrote:
> Greg Ewing wrote:
>> Charles Merriam wrote:
>>> How can I write the greatest common denominator of this code:
>>>
>>> print "Hello World!"  # yes, that needs to be Unicode.
>> Something like
>>
>>    from __future__ import unicode_literals
>>    from py3k_compat import Print
>>
>>    Print("Hello World!") # yes, that indeed is Unicode.
>>
>> given suitable implementations of py3k_compat for
>> each environment.
>>
> 
> Am I missing something here?  What's wrong with:
> 
> $ ./python.exe
> Python 2.6a1+ (trunk:61978, Mar 27 2008, 12:48:39)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> from __future__ import unicode_literals
>  >>> from __future__ import print_function
>  >>> print('hello, world')
> hello, world
>  >>> type('hello, world')
> <type 'unicode'>
>  >>>
> 
> The only problem I see is that the __future__ import of unicode_literals 
> doesn't work in 3.0 yet.  I'll look into fixing that.

Someone beat me to it.  Those exact same statements already work in 
trunk and py3k (except the type of a string literal is str, of course).



From nnorwitz at gmail.com  Fri Mar 28 05:33:04 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 27 Mar 2008 21:33:04 -0700
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <319e029f0803270352r245247c0o1b066790fdb4c83e@mail.gmail.com>
References: <47EB2387.4060502@acm.org>
	<319e029f0803270352r245247c0o1b066790fdb4c83e@mail.gmail.com>
Message-ID: <ee2a432c0803272133n1141b12i9c70767de6b3c05d@mail.gmail.com>

On Thu, Mar 27, 2008 at 3:52 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Thu, Mar 27, 2008 at 5:33 AM, Talin <talin at acm.org> wrote:
>  >  -- A document describing the "common subset", and how to write programs
>  >  in it. This doesn't have to be a complete standalone manual, just an
>  >  addendum to the regular Python docs explaining what things to avoid and
>  >  how to get around them.
>  >
>  >  -- That document could include a description of (or for extra credit, an
>  >  implementation of) the utility library mentioned earlier, that isolates
>  >  the difference between the two Python versions.
>  >
>  >  Any volunteers?
>
>  I've done a buch of tests to see what works and what doesn't and how
>  to get around it that could serve as a starting point. Any ideas of
>  where to check these in?

Thanks for volunteering Lennart!

For now, it's best to put this on the wiki.  That will allow many
people to contribute.

Cheers,
n

From nnorwitz at gmail.com  Fri Mar 28 06:41:26 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 27 Mar 2008 22:41:26 -0700
Subject: [Python-3000] the release gods are angry at python
In-Reply-To: <8526353492909807871@unknownmsgid>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<8526353492909807871@unknownmsgid>
Message-ID: <ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>

On Thu, Mar 27, 2008 at 11:31 AM, Bill Janssen <janssen at parc.com> wrote:
> > There
>  > have been other tests that have also been flaky like  test_asynchat,
>  > test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
>  > test_xmlrpc_net and some of the tests that use  networking.
>
>  Some of the *other* tests that use networking, I think you mean.

Yes, primarily networking tests.  Also things like signals and threading.

>  Sounds like networking tests in general are flaky.

Anything that connects to a remote host is definitely flaky.  Most of
the tests that connect to localhost are flaky for one reason or
another.  One reason used to be port allocation.  That is mostly fixed
now.

The big reason that most tests fail now is EAGAIN or some other error,
typically on non-blocking sockets.  Switching to blocking sockets
isn't really a great option since the tests are much more likely to
hang.

>  >     - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0
>
>  Unfortunately, this log has no information about why the test is
>  failing, and I do not have a Debian-unstable machine to try it on
>  (much less a six-processor IBM S/390 mainframe running Debian-unstable
>  -- cool!).  I'm unsure about how to make progress here.  It's
>  interesting to see that most of the stable buildbots running Debian
>  are doing so on big-endian (PPC, Sparc) hardware.
>
>  I also can't tell which branch of Python is being tested, from this
>  logfile.  That would be nice to add.  Is this 2.6 (known problems with
>  SSL) or 3.0 (no known problems with SSL)?  Is this information in the
>  logfile somewhere and I'm not seeing it?

The information happens to be encoded in the URL.  The URL above is for trunk.
You can see more info here:  http://www.python.org/dev/buildbot/all/
That is the landing page for all the info you could want.  Well,
mostly.  The logs often don't really have enough info to debug the
problem.  In that case, it would be better to add more debugging to
the tests.

n

From regebro at gmail.com  Fri Mar 28 08:01:50 2008
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 28 Mar 2008 08:01:50 +0100
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <ee2a432c0803272133n1141b12i9c70767de6b3c05d@mail.gmail.com>
References: <47EB2387.4060502@acm.org>
	<319e029f0803270352r245247c0o1b066790fdb4c83e@mail.gmail.com>
	<ee2a432c0803272133n1141b12i9c70767de6b3c05d@mail.gmail.com>
Message-ID: <319e029f0803280001r45ac4321xaa1f2147a6a6693@mail.gmail.com>

On Fri, Mar 28, 2008 at 5:33 AM, Neal Norwitz <nnorwitz at gmail.com> wrote:
>  For now, it's best to put this on the wiki.  That will allow many
>  people to contribute.

Yeah, but the code would be more practical in an svn. But some docs in
the wiki would be a good idea. I'll see what I can do next week.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From lists at cheimes.de  Fri Mar 28 10:25:56 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 28 Mar 2008 10:25:56 +0100
Subject: [Python-3000] Python 3.0 Porting Strategies
In-Reply-To: <47EC3B36.7090405@trueblade.com>
References: <47EB2387.4060502@acm.org>	<b8c6f6c40803270053u1cc6f454w262cea9faf4e1924@mail.gmail.com>	<47EC286B.3020102@canterbury.ac.nz>
	<47EC3B36.7090405@trueblade.com>
Message-ID: <47ECB9A4.5000102@cheimes.de>

Eric Smith schrieb:
> The only problem I see is that the __future__ import of unicode_literals 
> doesn't work in 3.0 yet.  I'll look into fixing that.

The __future__ import of unicode_literals was added to py3k 26 hours
earlier:

Author: christian.heimes
Date: Wed Mar 26 23:34:47 2008
New Revision: 61955

Christian

From skip at pobox.com  Fri Mar 28 11:31:44 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 28 Mar 2008 05:31:44 -0500
Subject: [Python-3000] [Python-Dev] the release gods are angry at python
In-Reply-To: <ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<8526353492909807871@unknownmsgid>
	<ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>
Message-ID: <18412.51472.322043.137606@montanaro-dyndns-org.local>


    Neal> Anything that connects to a remote host is definitely flaky.

Would it maybe help to set up a dedicated host (or virtual host) to serve as
the sole target of all network tests?

Skip

From qrczak at knm.org.pl  Fri Mar 28 17:46:51 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Fri, 28 Mar 2008 17:46:51 +0100
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <47EAE0B1.3010900@canterbury.ac.nz>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
	<d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
	<47EAE0B1.3010900@canterbury.ac.nz>
Message-ID: <1206722811.3933.10.camel@qrnik>

Dnia 27-03-2008, Cz o godzinie 11:48 +1200, Greg Ewing pisze:

> Tuples are created batchwise because, being immutable,
> that's the only way to do it. But if set literals are
> to produce mutable objects, there's no need for them
> to be created batchwise, and doing so has unfortunate
> stack size and memory use consequences in the worst case.

What about lists? I guess (haven't checked) that they are made like
tuples. If so, has it caused problems with the stack size? If not,
perhaps we should not worry about dicts either.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From nnorwitz at gmail.com  Fri Mar 28 18:48:54 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 28 Mar 2008 10:48:54 -0700
Subject: [Python-3000] [Python-Dev] the release gods are angry at python
In-Reply-To: <18412.51472.322043.137606@montanaro-dyndns-org.local>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<8526353492909807871@unknownmsgid>
	<ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>
	<18412.51472.322043.137606@montanaro-dyndns-org.local>
Message-ID: <ee2a432c0803281048w2a93d38al16023de3273f7d9@mail.gmail.com>

On Fri, Mar 28, 2008 at 3:31 AM,  <skip at pobox.com> wrote:
>
>     Neal> Anything that connects to a remote host is definitely flaky.
>
>  Would it maybe help to set up a dedicated host (or virtual host) to serve as
>  the sole target of all network tests?

It would help, but not fix the problem.  There will still be transient
network issues that come up.

n

From nnorwitz at gmail.com  Fri Mar 28 19:11:11 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 28 Mar 2008 11:11:11 -0700
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <1206722811.3933.10.camel@qrnik>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
	<d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
	<47EAE0B1.3010900@canterbury.ac.nz> <1206722811.3933.10.camel@qrnik>
Message-ID: <ee2a432c0803281111q2880dd54k6531885f431ca5d5@mail.gmail.com>

On Fri, Mar 28, 2008 at 9:46 AM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 27-03-2008, Cz o godzinie 11:48 +1200, Greg Ewing pisze:
>
>
>  > Tuples are created batchwise because, being immutable,
>  > that's the only way to do it. But if set literals are
>  > to produce mutable objects, there's no need for them
>  > to be created batchwise, and doing so has unfortunate
>  > stack size and memory use consequences in the worst case.
>
>  What about lists? I guess (haven't checked) that they are made like
>  tuples. If so, has it caused problems with the stack size? If not,
>  perhaps we should not worry about dicts either.

r27219 | nnorwitz | 2002-06-13 18:07:39 -0700 (Thu, 13 Jun 2002) | 5 lines

Fix SF bug # 561858 Assertion with very long lists

Write 4 bytes for co_stacksize, etc. to prevent writing out
bad .pyc files which can cause a crash when read back in.

n

From janssen at parc.com  Fri Mar 28 19:15:52 2008
From: janssen at parc.com (Bill Janssen)
Date: Fri, 28 Mar 2008 11:15:52 PDT
Subject: [Python-3000] [Python-Dev] the release gods are angry at python
In-Reply-To: <ee2a432c0803281048w2a93d38al16023de3273f7d9@mail.gmail.com> 
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<8526353492909807871@unknownmsgid>
	<ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>
	<18412.51472.322043.137606@montanaro-dyndns-org.local>
	<ee2a432c0803281048w2a93d38al16023de3273f7d9@mail.gmail.com>
Message-ID: <08Mar28.111601pdt."58696"@synergy1.parc.xerox.com>

> On Fri, Mar 28, 2008 at 3:31 AM,  <skip at pobox.com> wrote:
> >
> >     Neal> Anything that connects to a remote host is definitely flaky.
> >
> >  Would it maybe help to set up a dedicated host (or virtual host) to serve as
> >  the sole target of all network tests?
> 
> It would help, but not fix the problem.  There will still be transient
> network issues that come up.

We really need to be able to wrap a timeout around any individual
test, perhaps throwing a TimeoutException if the timeout is reached,
and have the ability to regard a TimeoutException as not being a
"failure".

Bill

From jimjjewett at gmail.com  Fri Mar 28 20:08:46 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 28 Mar 2008 15:08:46 -0400
Subject: [Python-3000] lambda
In-Reply-To: <47EBC900.5000201@cs.byu.edu>
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EA61AA.2030607@gmail.com>
	<b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
	<47EBC900.5000201@cs.byu.edu>
Message-ID: <fb6fbf560803281208u7fe65573of4e6534293a63c71@mail.gmail.com>

On 3/27/08, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> Olivier Verdier wrote:
>  > On 26/03/2008, *Nick Coghlan* <ncoghlan at gmail.com

> >     Lambda calculus is a
>  >     well established field of mathematics, so it's a perfectly valid name
>  >     for the construct.

>  > In my university in Sweden lambda calculus is never taught neither in
>  > pure nor applied math.

The relevant math courses may well be graduate-level only, and may (or
may not) be titled something like "logic" or "metamathematics".

>  > applied to linguistics. The word "lambda" however is  used all over the
>  > place as an eigenvalue, or a wave length, or parameter, or Lam?
>  > coefficient in many of our courses.

This is a (minor) problem with any reserved word.  I've seen more
trouble with "class", particularly for assignments to create a
registrar or grading program.

> How about reusing "def" to make a lambda expression?
...
>  By the time someone comes across this:

>      map(def(x): x**2, lst)

>  in code, they've already created plenty of functions using "def", ...
>  can't imagine that it would be *too* difficult to parse

As a human, it throws me off -- and so does lambda.  Much better to just write

    def _square(x):  return x**2
    map(square, lst)

There was enough argument to keep lambda, but *changing* it any way
(except possibly Terry's suggestion to make it a single unicode
character) will just add additional cost.

-jJ

From janssen at parc.com  Fri Mar 28 21:07:03 2008
From: janssen at parc.com (Bill Janssen)
Date: Fri, 28 Mar 2008 13:07:03 PDT
Subject: [Python-3000] lambda
In-Reply-To: <fb6fbf560803281208u7fe65573of4e6534293a63c71@mail.gmail.com> 
References: <b2da89060803251342t7fb947exd887358f6d539230@mail.gmail.com>
	<319e029f0803260051w4f1c0b8ela4ab55dcaa8a930a@mail.gmail.com>
	<47EA157E.5080903@gmail.com>
	<319e029f0803260233oba7e8bdr64c3ca09ea49b261@mail.gmail.com>
	<b2da89060803260332r6f03c055vc759a5e5b00afc71@mail.gmail.com>
	<47EA61AA.2030607@gmail.com>
	<b2da89060803270822m4904c02yfc0a812430c0cdff@mail.gmail.com>
	<47EBC900.5000201@cs.byu.edu>
	<fb6fbf560803281208u7fe65573of4e6534293a63c71@mail.gmail.com>
Message-ID: <08Mar28.130712pdt."58696"@synergy1.parc.xerox.com>

> As a human, it throws me off -- and so does lambda.  Much better to just wr=
> ite
> 
>     def _square(x):  return x**2
>     map(square, lst)
> 

Excellent illustration of why you want lambda: no need to keep two
more or less meaningless symbol names in sync, in a language which
doesn't provide any compile-time checking of such things.

Bill

From greg.ewing at canterbury.ac.nz  Fri Mar 28 23:27:30 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 29 Mar 2008 10:27:30 +1200
Subject: [Python-3000] Dict literal bytecode
In-Reply-To: <1206722811.3933.10.camel@qrnik>
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com>
	<aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com>
	<d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com>
	<aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com>
	<d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com>
	<aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com>
	<d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com>
	<47EAE0B1.3010900@canterbury.ac.nz> <1206722811.3933.10.camel@qrnik>
Message-ID: <47ED70D2.6030509@canterbury.ac.nz>

Marcin ?Qrczak? Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.

I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be much logic or consistency here at all.

 >>> def f():
...  x = [1,2,3]
...
 >>> from dis import dis
 >>> dis(f)
   2           0 LOAD_CONST               1 (1)
               3 LOAD_CONST               2 (2)
               6 LOAD_CONST               3 (3)
               9 BUILD_LIST               3
              12 STORE_FAST               0 (x)
              15 LOAD_CONST               0 (None)
              18 RETURN_VALUE

-- 
Greg

From jyasskin at gmail.com  Sat Mar 29 04:31:13 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Fri, 28 Mar 2008 20:31:13 -0700
Subject: [Python-3000] [Python-Dev] the release gods are angry at python
In-Reply-To: <1450237217404852410@unknownmsgid>
References: <ee2a432c0803252321g17ca6027ma7d2391d015e8bce@mail.gmail.com>
	<8526353492909807871@unknownmsgid>
	<ee2a432c0803272241q769dc4d3ide2322556fd68626@mail.gmail.com>
	<18412.51472.322043.137606@montanaro-dyndns-org.local>
	<ee2a432c0803281048w2a93d38al16023de3273f7d9@mail.gmail.com>
	<1450237217404852410@unknownmsgid>
Message-ID: <5d44f72f0803282031i5552b67bj5d61efccf62c4a@mail.gmail.com>

On Fri, Mar 28, 2008 at 11:15 AM, Bill Janssen <janssen at parc.com> wrote:
> > On Fri, Mar 28, 2008 at 3:31 AM,  <skip at pobox.com> wrote:
>  > >
>  > >     Neal> Anything that connects to a remote host is definitely flaky.
>  > >
>  > >  Would it maybe help to set up a dedicated host (or virtual host) to serve as
>  > >  the sole target of all network tests?
>  >
>  > It would help, but not fix the problem.  There will still be transient
>  > network issues that come up.
>
>  We really need to be able to wrap a timeout around any individual
>  test, perhaps throwing a TimeoutException if the timeout is reached,
>  and have the ability to regard a TimeoutException as not being a
>  "failure".

Something like:

@contextmanager
def timeout(max_time):
    def RaiseTimeout(signal, frame):
        raise TimeoutException
    # Why don't we have a context manager for the next line?
    old_alarm = signal.signal(signal.SIGALRM, RaiseTimeout)
    try:
        signal.alarm(max_time)
        try:
            yield
        finally:
            signal.alarm(0)
    finally:
        signal.signal(signal.SIGALRM, old_alarm)

with appropriate fallbacks for Windows. I may not be poking at
test_support for a bit, so anyone else is welcome to check that in, or
a fixed version of it, whenever they're fixing a timing-out test.

Someone else will have to implement the support in regrtest, although
I wouldn't mind having it treat a timeout as a failure, as long as
it's easier to diagnose than the SIGKILL it currently uses for
timeouts.

-- 
Namast?,
Jeffrey Yasskin

From tjreedy at udel.edu  Sat Mar 29 05:54:15 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 29 Mar 2008 00:54:15 -0400
Subject: [Python-3000] Dict literal bytecode
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com><aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com><d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com><aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com><d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com><aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com><d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com><47EAE0B1.3010900@canterbury.ac.nz>
	<1206722811.3933.10.camel@qrnik>
	<47ED70D2.6030509@canterbury.ac.nz>
Message-ID: <fski1n$22p$1@ger.gmane.org>


"Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message 
news:47ED70D2.6030509 at canterbury.ac.nz...
Marcin ?Qrczak? Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.

I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be much logic or consistency here at all.

 >>> def f():
...  x = [1,2,3]
...
 >>> from dis import dis
 >>> dis(f)
   2           0 LOAD_CONST               1 (1)
               3 LOAD_CONST               2 (2)
               6 LOAD_CONST               3 (3)
               9 BUILD_LIST               3
              12 STORE_FAST               0 (x)
              15 LOAD_CONST               0 (None)
              18 RETURN_VALUE

-- 
Greg 




From tjreedy at udel.edu  Sat Mar 29 06:01:31 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 29 Mar 2008 01:01:31 -0400
Subject: [Python-3000] Dict literal bytecode
References: <d38f5330803251135k5f84e9a5s237a3b3a55297e27@mail.gmail.com><aac2c7cb0803251232q7f65e84fo43012b9c2c38203a@mail.gmail.com><d38f5330803251311l4b6869cdve62e1cc0b8df2765@mail.gmail.com><aac2c7cb0803251326q78bb3de6w9f10477a78e207af@mail.gmail.com><d38f5330803251343s6c565675r91aec1bf938a8581@mail.gmail.com><aac2c7cb0803251406s2ce17412y34ab2b0d87470eda@mail.gmail.com><d38f5330803260818j48e38e24o41cc798f4b6d2633@mail.gmail.com><47EAE0B1.3010900@canterbury.ac.nz>
	<1206722811.3933.10.camel@qrnik>
	<47ED70D2.6030509@canterbury.ac.nz>
Message-ID: <fskifc$2tg$1@ger.gmane.org>


"Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message 
news:47ED70D2.6030509 at canterbury.ac.nz...
Marcin ?Qrczak? Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.

I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be much logic or consistency here at all.

 ====================
Would it be possible to consistently build all such builtin collections in 
bunches of say 256 items (or 128 pairs)?  Such a 'compromise' between the 
efficient 'all-at-once' and the safer 'one-at-a-time' methods would 
effectively  be 'all-at-once' for perhaps 99% of literals without imposing 
arbitrary limits on extreme cases.

tjr




From jyasskin at gmail.com  Sat Mar 29 06:15:19 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Fri, 28 Mar 2008 22:15:19 -0700
Subject: [Python-3000] Exception tracebacks living too long in 3.0
Message-ID: <5d44f72f0803282215q4a5424b1k1850da74c3af283c@mail.gmail.com>

If you apply the following patch to the py3k branch, you can watch
test_threading fail in test_no_refcycle_through_target:

Index: Lib/threading.py
===================================================================
--- Lib/threading.py    (revision 62033)
+++ Lib/threading.py    (working copy)
@@ -540,6 +540,7 @@
         finally:
             with _active_limbo_lock:
                 self._stop()
+                _sleep(0.01)
                 try:
                     # We don't call self.__delete() because it also
                     # grabs _active_limbo_lock.


This apparently happens because the traceback in sys.exc_info keeps
the frame for the call to RunSelfFunction._run alive even though there
are otherwise no references to the object. In 2.6, this is fixed by
calling sys.exc_clear() before allowing the thread to be joined, but
that function has gone away in 3.0. I had thought that exc_info was
automatically cleared at the end of any except block that caught an
exception, but apparently that isn't the case. Is this a bug in 3.0,
or do we need to keep sys.exc_clear() around?

-- 
Namast?,
Jeffrey Yasskin

From solipsis at pitrou.net  Sat Mar 29 13:51:28 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 29 Mar 2008 12:51:28 +0000 (UTC)
Subject: [Python-3000] Exception tracebacks living too long in 3.0
References: <5d44f72f0803282215q4a5424b1k1850da74c3af283c@mail.gmail.com>
Message-ID: <loom.20080329T112902-969@post.gmane.org>


Hi Jeffrey,

> I had thought that exc_info was
> automatically cleared at the end of any except block that caught an
> exception, but apparently that isn't the case. Is this a bug in 3.0,
> or do we need to keep sys.exc_clear() around?

The explanation seems to be that, while exc_info is cleared immediately, the
thread state exception fields are only cleaned up at the end of
PyEval_EvalFrameEx. The following patch fixes it for me:

diff -r adc2f5003ea3 Python/ceval.c
--- a/Python/ceval.c	Sat Mar 29 06:06:52 2008 +0100
+++ b/Python/ceval.c	Sat Mar 29 13:46:27 2008 +0100
@@ -1477,6 +1477,12 @@ PyEval_EvalFrameEx(PyFrameObject *f, int
 					"'finally' pops bad exception");
 				why = WHY_EXCEPTION;
 			}
+			if (tstate->frame->f_exc_type != NULL)
+				reset_exc_info(tstate);
+			else {
+				assert(tstate->frame->f_exc_value == NULL);
+				assert(tstate->frame->f_exc_traceback == NULL);
+			}
 			Py_DECREF(v);
 			break;


Regards

Antoine.



From solipsis at pitrou.net  Sat Mar 29 15:37:03 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 29 Mar 2008 14:37:03 +0000 (UTC)
Subject: [Python-3000] Exception tracebacks living too long in 3.0
References: <5d44f72f0803282215q4a5424b1k1850da74c3af283c@mail.gmail.com>
	<loom.20080329T112902-969@post.gmane.org>
Message-ID: <loom.20080329T143550-610@post.gmane.org>

> The explanation seems to be that, while exc_info is cleared immediately, the
> thread state exception fields are only cleaned up at the end of
> PyEval_EvalFrameEx.

Patch and test in http://bugs.python.org/issue2507




From lists at cheimes.de  Sat Mar 29 19:12:12 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 29 Mar 2008 19:12:12 +0100
Subject: [Python-3000] Exception tracebacks living too long in 3.0
In-Reply-To: <5d44f72f0803282215q4a5424b1k1850da74c3af283c@mail.gmail.com>
References: <5d44f72f0803282215q4a5424b1k1850da74c3af283c@mail.gmail.com>
Message-ID: <47EE867C.80905@cheimes.de>

Jeffrey Yasskin schrieb:
> This apparently happens because the traceback in sys.exc_info keeps
> the frame for the call to RunSelfFunction._run alive even though there
> are otherwise no references to the object. In 2.6, this is fixed by
> calling sys.exc_clear() before allowing the thread to be joined, but
> that function has gone away in 3.0. I had thought that exc_info was
> automatically cleared at the end of any except block that caught an
> exception, but apparently that isn't the case. Is this a bug in 3.0,
> or do we need to keep sys.exc_clear() around?

Thanks for picking up the bug for me. I noticed the issue during the
last merge but I hadn't had time to write a proper bug report.

Christian

From musiccomposition at gmail.com  Sat Mar 29 22:11:10 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 29 Mar 2008 16:11:10 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
Message-ID: <1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>

On Thu, Mar 20, 2008 at 2:42 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
>
> The current Subversion repository is still the master copy of the
> source code.  We have not made a decision to move to Bazaar
> officially, nor have we made a decision to even move off of
> Subversion.  We're making these branches available exactly so that
> you, the Python developer community, can kick the tires and see if it
> makes sense to move to a different vcs.  Nothing will happen until
> after the Python 2.6/3.0 releases anyway.
>
> All the gory details are documented here:
>
>     http://www.python.org/dev/bazaar
>
> These branches are available both for core Python developers with
> commit privileges, and the wider world of developers without commit
> privileges.  It's this latter group that I think will find the most
> compelling immediate benefit from using Bazaar, because they will no
> longer need to maintain their own changes using a mass of patch files.
>
> For more information on Bazaar in general, see:
>
>     http://bazaar-vcs.org
>
> You will probably be most interested in the Bazaar mirrors of the
> Subversion master repository.  We have a cron job that updates Bazaar
> from Subversion every 15 minutes.  It is also possible to push changes
> made in your Bazaar branches into the Subversion master, so you can
> keep reasonably up-to-date and interact with the Python source code
> solely via Bazaar.

Once you've pushed the branches, is there a way to remove them?

>
>
> Please let me know if you have any questions or anything in the docs
> referenced above aren't clear.  I know I need to document the Bazaar-
>  >Subversion workflow in more detail.
>
> Huge thanks go out especially to Thomas Wouters who sprinted with me
> yesterday on getting the whole infrastructure up and running.  Thanks
> also to Martin v. Loewis, Sean Reifschneider, and the folks here at
> Pycon from the Bazaar project, Ian, Andrew, John, and Edwin.
>
> Enjoy,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR+K+H3EjvBPtnXfVAQL6bwP/d0XKx0mRPgzdOD6zCPwwRl8y2kxWV9Vl
> zVwN07cK8IlwMa9M470MsERuXuD8hmeXnPgnrUcrX9HciwldmY8C33t0f8GaOk1J
> iD4Od1midlIaJJiMd+JcFk9NbX3Rwc4HMj3s8jKjjdlGrFe77ei9DCZ/HMl/iG5K
> fyyjXo4HLEE=
> =Gcjq
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080329/bdf93056/attachment.htm 

From barry at python.org  Sat Mar 29 22:59:04 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 29 Mar 2008 17:59:04 -0400
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
Message-ID: <EE213CA6-2724-42F5-8E4B-9A724EAE3054@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 29, 2008, at 5:11 PM, Benjamin Peterson wrote:

> Once you've pushed the branches, is there a way to remove them?

Do you mean the local branches?  If yes, then 'rm -rf mymergedbranch'  
does exactly what you want. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+67qXEjvBPtnXfVAQJ94AP8CA6OmnIlOluIfUuW1TolCpZQJTZS3TbL
4ZZS32CYvgF4gB366wAuaFGuCsaQlAV9punP5l0T9Ei6i4cHD1nIKheNY49JfLxX
83I5fXV9n+Mwe0uJEjgfP5GKTykawwTypG6zfy2lkvJm4wwhfHUH26ctafOlVXo1
z4bLDFZsMMs=
=KQay
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Sat Mar 29 23:00:47 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 29 Mar 2008 17:00:47 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <EE213CA6-2724-42F5-8E4B-9A724EAE3054@python.org>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
	<EE213CA6-2724-42F5-8E4B-9A724EAE3054@python.org>
Message-ID: <1afaf6160803291500j3099e1cfl654dcd637c3cc189@mail.gmail.com>

On Sat, Mar 29, 2008 at 4:59 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mar 29, 2008, at 5:11 PM, Benjamin Peterson wrote:
>
> > Once you've pushed the branches, is there a way to remove them?
>
> Do you mean the local branches?  If yes, then 'rm -rf mymergedbranch'
> does exactly what you want. :)

No, I mean the pushed version on code.python.org.

>
>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR+67qXEjvBPtnXfVAQJ94AP8CA6OmnIlOluIfUuW1TolCpZQJTZS3TbL
> 4ZZS32CYvgF4gB366wAuaFGuCsaQlAV9punP5l0T9Ei6i4cHD1nIKheNY49JfLxX
> 83I5fXV9n+Mwe0uJEjgfP5GKTykawwTypG6zfy2lkvJm4wwhfHUH26ctafOlVXo1
> z4bLDFZsMMs=
> =KQay
> -----END PGP SIGNATURE-----
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080329/81a2a601/attachment.htm 

From barry at python.org  Sat Mar 29 23:10:46 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 29 Mar 2008 18:10:46 -0400
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803291500j3099e1cfl654dcd637c3cc189@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
	<EE213CA6-2724-42F5-8E4B-9A724EAE3054@python.org>
	<1afaf6160803291500j3099e1cfl654dcd637c3cc189@mail.gmail.com>
Message-ID: <05CF1392-B11E-4FA1-AB0C-DAD88E3980CE@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 29, 2008, at 6:00 PM, Benjamin Peterson wrote:
>
> No, I mean the pushed version on code.python.org.

Not unless you have shell or sftp access, which you probably don't.   
It's not a big deal though except for a mild feeling of  
uncleanliness.  If you ever want to push a completely unrelated branch  
overtop that one, just use --overwrite.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+6+ZnEjvBPtnXfVAQIbdgP+KRv3Uhq9OQrhc6iRI1eEVR+1bbYbFSQs
bwvwSf9SXNaf/YfO5Bm61YlJkHHkJd0237cf0Dn/MU8IFacRawJijhVbBYec2QmY
4CWeMiiPop+LL1z2MlXkErfbeVt9AZeiNQ/oDLYda9Bg7Tw20XKE3VYqJGAVGt0b
XrucWkxI964=
=ahtL
-----END PGP SIGNATURE-----

From skip at pobox.com  Sun Mar 30 00:15:18 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 29 Mar 2008 18:15:18 -0500
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>
	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
Message-ID: <18414.52614.618794.737997@montanaro-dyndns-org.local>


    Benjamin> Once you've pushed the branches, is there a way to remove them?

Related question: is there a way to view the various branches in a non-local
repository?

Skip


From martin at v.loewis.de  Sun Mar 30 09:35:42 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 30 Mar 2008 09:35:42 +0200
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <18414.52614.618794.737997@montanaro-dyndns-org.local>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
	<18414.52614.618794.737997@montanaro-dyndns-org.local>
Message-ID: <47EF42CE.1040101@v.loewis.de>

skip at pobox.com wrote:
>     Benjamin> Once you've pushed the branches, is there a way to remove them?
> 
> Related question: is there a way to view the various branches in a non-local
> repository?

IIUC, conceptually, no. A branch is not *in* a repository; a branch *is*
a repository (*). So your question is almost equivalent to "is there a
way to find out all clones of a repository that have ever been made?",
to which the answer is "no".

Now, if you have a convention of where you put the branches, you should
be able to find them later. E.g. if they are all in a directory tree
that is exposed through http, you can use a web browser to see them,
e.g. by going to

http://code.python.org/python/users/skip/

Likewise, if you are accessing the repository over bzr+ssh, in general,
you can just ssh to the machine, and do a regular ls. In the specific
setup, regular ssh is restricted to running "bzr serve", which
(apparently) has no support for directory browsing.

Regards,
Martin

From martin at v.loewis.de  Sun Mar 30 09:37:37 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 30 Mar 2008 09:37:37 +0200
Subject: [Python-3000] Help on builtin keywords
In-Reply-To: <8548c5f30803270049v19971a18ic520d16e558366cb@mail.gmail.com>
References: <8548c5f30803270049v19971a18ic520d16e558366cb@mail.gmail.com>
Message-ID: <47EF4341.2070100@v.loewis.de>

> I did not check if there is a bug on this, but if the situation can be fixed
> in Py3k, it would be great. I suggest that "help()" either gives a single-line
> help for keywords also, or gracefully die down with a proper error string,
> telling "<keyword> is a Python keyword" instead of the ugly SyntaxError.

It's very hard to fix. help is a regular function, so it has to conform
with the function call syntax.

Regards,
Martin

From talin at acm.org  Mon Mar 31 04:24:40 2008
From: talin at acm.org (Talin)
Date: Sun, 30 Mar 2008 19:24:40 -0700
Subject: [Python-3000] A small suggestion
Message-ID: <47F04B68.8050707@acm.org>

I notice that whenever someone cross-posts a message to both python-dev 
and python-3000, I get two copies of every reply to the thread, which 
makes the thread somewhat hard to read. Perhaps most people on this list 
have smarter mail readers than I do (Thunderbird in my case) which can 
merge the duplicate messages, but if you find this as much of an 
annoyance as I do, then I have a couple of small suggestions:

1) If your message is important enough to post to multiple mailing 
lists, then it might make sense to post a separate message to each list; 
That way, when someone replies to the message, they will only be 
replying to one list, not all of them.

(Another option might be to just BCC the lists. I'm sure that there are 
other options as well.)

2) If you are responding to a cross-posted message, I'd suggest taking 
the time to edit the "To:" field so that you're only replying to the 
lists you really want to.

Of course, if you really do want to start one single thread in both 
lists, I have no objection - but I suspect that most of the time this 
isn't the intent, and is just generating unnecessary traffic.

The good news is that it only takes one person being careful with their 
reply headers to cut out whole sub-trees of duplicate traffic, and 
thereby save python.org some valuable bandwidth :)

-- Talin

From barry at python.org  Mon Mar 31 14:32:20 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 31 Mar 2008 08:32:20 -0400
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <47EF42CE.1040101@v.loewis.de>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com>
	<18414.52614.618794.737997@montanaro-dyndns-org.local>
	<47EF42CE.1040101@v.loewis.de>
Message-ID: <1F046B4C-05C5-42C7-B0A9-731B9A4A5AB4@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 30, 2008, at 3:35 AM, Martin v. L?wis wrote:

> Likewise, if you are accessing the repository over bzr+ssh, in  
> general,
> you can just ssh to the machine, and do a regular ls. In the specific
> setup, regular ssh is restricted to running "bzr serve", which
> (apparently) has no support for directory browsing.

I suppose we could enable sftp access to user branches on  
code.python.org.  You wouldn't want to use sftp:// protocol to do bzr,  
even though you could, because bzr+ssh is more efficient.

- - -Barry

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+/04HEjvBPtnXfVAQI6gAQApMnG/h4qCoSx5rxd6US03DN01hh2ef2N
l7tNnQCJMAd2+By5z/cn/BY2vehZmVZEFhgNsGzhAOHZNbsbFG2kBdJkT5PLCOQN
ZGqdYCgbMbHhDLsPG0XfWorOgpeER/7WlesF/VXGbbGiZqbWYFZVbprM6M7n4O/y
V5RzsxpHO/s=
=Po3X
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR/DZ1XEjvBPtnXfVAQJm6gQAjnNOy8HjE90WjbzPgJtSS+S6W9Z2lBGm
IFxSFElDv6D59G67qikdHHlJfn/eCSrl1QB158AucGMCIWDRFM/d5UOTfv6a7vcQ
pLpJvWD1DqvvbvKZi7CkRIpcTn80YATAhJ4mOTaJ7zlC6m9OHJwkLZnxDRJdmrkJ
xv5hZzqVTS0=
=fcSk
-----END PGP SIGNATURE-----

From barry at python.org  Mon Mar 31 15:06:24 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 31 Mar 2008 09:06:24 -0400
Subject: [Python-3000] Next alphas, this Wednesday
Message-ID: <FBFF08F1-E4AD-47E9-846A-945ECA0358CB@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just another heartbeat reminder that I intend to release the next  
alphas for Python 2.6 and 3.0 this Wednesday April 2nd, at  
approximately 6pm Eastern time (UTC 2200).

Current status: the buildbots for both the trunk and 3.0 look  
relatively good, though a few are purple or red:

http://www.python.org/dev/buildbot/stable/

There is currently one release blocker bug for 3.0:

http://bugs.python.org/issue2507

I'll be looking at these in more detail later today.  If you have  
time, feel free to comment on the bug or send a follow up about the  
stable buildbots.  Please try to be very conservative in your commits  
to the trunk and 3.0 over the next few days.   Concentrate on fixing  
existing code rather than committing new features.  Your release  
manager thanks you for your diligence! :)

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR/Dh0HEjvBPtnXfVAQL3HgQAnk/eoRyfrF0RQcCKCfhNyfpfc7KGbPMW
Y46xZy/yzySPbUDLP4YhTs3hhjt4hfZEHYagWV50Yy0Wtak0vDMj1Fr+8jxIptR0
Qh0zQhop2OQPZVT5S5TOgOVlXAj9nYITDpfnFfogoNo4PaEG8wNvlBZKcxN+8cfv
KkSrM6Sm4Rw=
=rOZw
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Mon Mar 31 19:08:49 2008
From: martin at v.loewis.de (=?iso-8859-1?Q?=22Martin_v._L=F6wis=22?=)
Date: Mon, 31 Mar 2008 10:08:49 -0700
Subject: [Python-3000] [Python-Dev] Python source code on Bazaar vcs
In-Reply-To: <18414.52614.618794.737997@montanaro-dyndns-org.local>
References: <20C0AC37-D748-450E-B690-FBCA2ACFFC4E@python.org>	<1afaf6160803291411h39251770xd32846e7342ec8b6@mail.gmail.com><18414.52614.618794.737997@montanaro-dyndns-org.local>
Message-ID: <973B8501CEBE40C28AF234E4E352CFCD@hostedexchange.local>

skip at pobox.com wrote:
>     Benjamin> Once you've pushed the branches, is there a way to remove them?
> 
> Related question: is there a way to view the various branches in a non-local
> repository?

IIUC, conceptually, no. A branch is not *in* a repository; a branch *is*
a repository (*). So your question is almost equivalent to "is there a
way to find out all clones of a repository that have ever been made?",
to which the answer is "no".

Now, if you have a convention of where you put the branches, you should
be able to find them later. E.g. if they are all in a directory tree
that is exposed through http, you can use a web browser to see them,
e.g. by going to

http://code.python.org/python/users/skip/

Likewise, if you are accessing the repository over bzr+ssh, in general,
you can just ssh to the machine, and do a regular ls. In the specific
setup, regular ssh is restricted to running "bzr serve", which
(apparently) has no support for directory browsing.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/fumanchu%40aminus.org

From alexander.belopolsky at gmail.com  Mon Mar 31 21:12:16 2008
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 31 Mar 2008 15:12:16 -0400
Subject: [Python-3000] PEP 3102 question
Message-ID: <d38f5330803311212q5af64549s3c3c60887f665275@mail.gmail.com>

Do I understand correctly that with PEP 3102 implemented, keyword
arguments can follow vararg in function definitions, but doing the
same when calling the function is still a syntax error?

With the latest py3k,

>>> def f(a, *args, v=None):
...    pass
...
>>> f(a, *args, v=None)
  File "<stdin>", line 1
    f(a, *args, v=None)
                ^
SyntaxError: invalid syntax

Is this intentional?

From mwm at mired.org  Mon Mar 24 01:18:32 2008
From: mwm at mired.org (Mike Meyer)
Date: Sun, 23 Mar 2008 20:18:32 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<47E23C60.6030306@gmail.com>
	<319e029f0803200345k128b0613x20694792a9de283f@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
Message-ID: <20080323201832.60203a0b@bhuda.mired.org>

On Sun, 23 Mar 2008 21:20:11 +0100
"Lennart Regebro" <regebro at gmail.com> wrote:
> On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <mwm at mired.org> wrote:
> >  Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
> >  you can't start using 2.6 features until everyone is using it, right?
> No, but you can start using 2.6 before everyone is using it, since 2.6
> is backwards compatible with 2.5. So you write 2.5 code, and run it
> under 2.5 or 2.6. This is not possible with 3.0. You can't write 2.5
> code and run it under 3.0.

I don't think anyone proposed writing 2.5 code to run on 3.0. However,
you can write 2.6 code and run it (after processing by 2to3) on
3.0. Yes, you have to be more careful about things. Yes, you can't use
all of 3.0. But the goal is that is is possible.

It really does appear that, for such a project (and I think two of
mine - python-xlib & plwm - qualify) 2.5->2.6 and 2.6->3.0 aren't that
far apart. You can write code for the old version, and run it (with
suitable preprocessing) on the new version. You can't use features
available in the new version until everyone is off the old version.

The transition will cause projects to do some thinking about what they
support, because doing both 3.0 and versions before 2.6 isn't really
supported (at least, I don't think it is), whereas how far back you
want to go if you're on 2.4 is really a matter of how much you want to
limit yourself.

> >  Given that a simultaneous conversion is unrealistic, you clearly
> >  expect to have some people running on 2.6 while others are running on
> >  2.5.
> Yes I can.

I believe we're in violent agreement here.

> >  Why? Once you've got your web site working on 3.0, what's the point of
> >  keeping the 2.6 web site around? Yes, you need to keep the 2.6 *code*
> >  around, but that's a different issue, dealt with below.
> Yeah, you are right about that point, except for the compilation and
> the fact that you are debugging a different version of the code than
> the one you are writing, which of course is highly confusing,

Um, I hate to tell you this, but the vast majority of programmers
debug a different version of the code than they write, because they
are using a compiled language. They write in a nice character based
language like C, but then debug a binary machine code. Yeah, smart
compilers and debuggers help, by building a mapping from the machine
code back to the character code, and then using it so it looks like
you're debugging the character code.

Which brings up a feature request for 2to3/3.0: the ability to leave
cookies in the 3.0 file that "smart" debuggers can use to help with
debugging code from 2to3? At the very least, each time a line is
changed, the ability to add a comment with the original line and the
file and line number it came from.

> it is
> similar to having 2.5/2.6. The difference is that with 2.5/2.6 you
> develop for one, and then when that works, you make sure it works on
> the other.

Wait a minute here! If you develop for 2.6, how do you make sure it
works for 2.5 unless you've got copies of your web site running on
both 2.5 and 2.6? I thought the prospect of having to maintain two
copies of your web site was a major problem with going to 3.0?

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From mwm at mired.org  Mon Mar 24 01:49:06 2008
From: mwm at mired.org (Mike Meyer)
Date: Sun, 23 Mar 2008 20:49:06 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<47E6D111.1030607@v.loewis.de>
	<319e029f0803231512s16e9f56bo9a19d4eb8d03a98e@mail.gmail.com>
Message-ID: <20080323204906.0d540bc1@bhuda.mired.org>

On Sun, 23 Mar 2008 23:12:55 +0100
"Lennart Regebro" <regebro at gmail.com> wrote:
> > You develop for 2.6, and then make sure it runs on 3.0 -
> > *exactly* the same as for 2.5/2.6.
> Uh... no. You develop for 2.5, and then you don't do anything else. It
> *will* run under 2.6. No need to check. Because it's backwards
> compatible.

This is, to be blunt, wishful thinking. I'm not sure that that's even
the intent. How many programs that used set.Set in 2.3 broke in 2.4
when the set module vanished? I don't know that there are any such
changes in 2.6. However, I don't believe the feature set for 2.6 has
been frozen yet, and until that happens, you can't know whether or not
your statement is true.

> And 3.0 is not. So it's definitely not the same. However,
> if 2.6 were forwards compatible, this would be true for the 2.6 to 3.0
> port.

Um, I'm used to "forward compatible" meaning "ignores features we
recognize as being for future versions of ourselves, but don't
otherwise understand" (or similar). Doing that in a programming
language is liable to be an even worse disaster than it is for data
language.

2.6 can add features to help make converting code to 3.0 easier. 3.0
can't add features to help make converting code from 2.6 easier. The
issue of adding features to 2.x to make converting code from 2.y
easier has never come up, because we've never removed features before
(though we've moved them, and added restrictions, and probably other
things that caused code to break).

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From mwm at mired.org  Mon Mar 24 15:51:29 2008
From: mwm at mired.org (Mike Meyer)
Date: Mon, 24 Mar 2008 10:51:29 -0400
Subject: [Python-3000] u'text' as an alias for 'text'?
In-Reply-To: <319e029f0803240106j2ccf8290oc99e0eb8a4480d99@mail.gmail.com>
References: <319e029f0803200048s768262d1g3805873e4e646e0c@mail.gmail.com>
	<b8c6f6c40803200840w33062b4cv3c3f371bcdc88500@mail.gmail.com>
	<319e029f0803200928sd9b5d03ud4966c70d6acd080@mail.gmail.com>
	<9e804ac0803200950p3d0a190cj1d9463581106b00b@mail.gmail.com>
	<319e029f0803200955l747b7e8ey11ba828adcc4ea2c@mail.gmail.com>
	<47E2A69B.9080509@v.loewis.de>
	<319e029f0803201251h2ec05b1fk50f9629627a6b07d@mail.gmail.com>
	<20080320180239.79ee5b64@bhuda.mired.org>
	<319e029f0803231320t3f01d99fp4cf9d6890774603@mail.gmail.com>
	<20080323201832.60203a0b@bhuda.mired.org>
	<319e029f0803240106j2ccf8290oc99e0eb8a4480d99@mail.gmail.com>
Message-ID: <20080324105129.1d8fc41c@bhuda.mired.org>

On Mon, 24 Mar 2008 09:06:29 +0100
> >  It really does appear that, for such a project (and I think two of
> >  mine - python-xlib & plwm - qualify) 2.5->2.6 and 2.6->3.0 aren't that
> >  far apart. You can write code for the old version, and run it (with
> >  suitable preprocessing) on the new version. You can't use features
> >  available in the new version until everyone is off the old version.
> 
> Note how this is libraries with a small set of developers and a well
> defined API that gets released on (ir)regular intervals and whos users
> use the release. Just the type of project I many times agreed 2to3
> will work well on.

That description fits python-xlib, but not plwm, which is a framework
for building window managers. And people are a lot more sensitive
about window managers (at least the kind of people who build their
own) than web sites.

> >  Um, I hate to tell you this, but the vast majority of programmers
> >  debug a different version of the code than they write, because they
> >  are using a compiled language. They write in a nice character based
> >  language like C, but then debug a binary machine code. Yeah, smart
> >  compilers and debuggers help, by building a mapping from the machine
> >  code back to the character code, and then using it so it looks like
> >  you're debugging the character code.
> >
> >  Which brings up a feature request for 2to3/3.0: the ability to leave
> >  cookies in the 3.0 file that "smart" debuggers can use to help with
> >  debugging code from 2to3? At the very least, each time a line is
> >  changed, the ability to add a comment with the original line and the
> >  file and line number it came from.
> 
> A complicated solution for a problem that isn't necessary, and only
> solves it if you are using a smart debugger...

Complicated? Really? On extra option, and an optional print when you
emit a line? And if you don't read the 2to3 code when debugging, or
don't consider yourself smart, I'd say that's your problem. Seriously,
the pdb 'l' command will shows you the source file when you're
debugging with it. Having a comment there that the code you're looking
at was generated by 2to3 should help avoid confusion if you decide
that's what needs to change.

      <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From vizcaynot at gmail.com  Sat Mar 29 21:19:00 2008
From: vizcaynot at gmail.com (Vizcayno)
Date: Sat, 29 Mar 2008 13:19:00 -0700 (PDT)
Subject: [Python-3000] TypeError: expected bytes, str found
Message-ID: <eef38ebe-9db6-4493-b9c8-18ad3e973271@b1g2000hsg.googlegroups.com>

I am doing some testing using Python r30a3:61161 under command prompt
of WinXp SP2.
Is this possible to find an explanation about next error? I tried to
find the error message in the web but no info exists and, can not
isolate or reproduce it.
Many, many thanks for your attention.

Traceback (most recent call last):
  File "testconn.py", line 112, in <module>
    main(sys.argv)
  File "testconn.py", line 100, in main
    sap.sapinfo()
  File "C:\os\sapconn\saprfc_py30\saprfc.py", line 142, in sapinfo
    print("Aqui estoy")
  File "C:\python30\lib\io.py", line 1248, in write
    self.buffer.write(b)
  File "C:\python30\lib\io.py", line 852, in write
    if len(self._write_buf) > self.buffer_size:
TypeError: expected bytes, str found