From greg.ewing at canterbury.ac.nz  Sat Dec  1 01:06:36 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 01 Dec 2007 13:06:36 +1300
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <finmfi$e50$1@ger.gmane.org>
References: <fimpkk$405$1@ger.gmane.org> <finmfi$e50$1@ger.gmane.org>
Message-ID: <4750A58C.1070205@canterbury.ac.nz>

Terry Reedy wrote:
> "Christian Heimes" <lists at cheimes.de> wrote in message 
> news:fimpkk$405$1 at ger.gmane.org...
>
> | I've started to work on a pyvm module patch today.

Is there a clear rationale for the dividing line between
sys and pyvm?

Maybe the distinction should be that pyvm is for things that
could change from one Python implementation to another,
whereas sys is for language-defined things that should
be present in every implementation.

--
Greg

From guido at python.org  Sat Dec  1 01:24:06 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Nov 2007 16:24:06 -0800
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <4750A58C.1070205@canterbury.ac.nz>
References: <fimpkk$405$1@ger.gmane.org> <finmfi$e50$1@ger.gmane.org>
	<4750A58C.1070205@canterbury.ac.nz>
Message-ID: <ca471dc20711301624t228bcf88i30e4c9cbce2c469f@mail.gmail.com>

Then I see pyvm dwindling to near-zero size, since nearly all the
types considered here are seen as official APIs by Jython, IronPython
and PyPy.

Also, if it's VM-specific perhaps it ought to have a VM-specific name.

Personally, I think they should all move into existing modules -- many
will fit in collections (dict_proxy etc.), others in sys (module,
function, frame etc.).

--Guido

On Nov 30, 2007 4:06 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Terry Reedy wrote:
> > "Christian Heimes" <lists at cheimes.de> wrote in message
> > news:fimpkk$405$1 at ger.gmane.org...
> >
> > | I've started to work on a pyvm module patch today.
>
> Is there a clear rationale for the dividing line between
> sys and pyvm?
>
> Maybe the distinction should be that pyvm is for things that
> could change from one Python implementation to another,
> whereas sys is for language-defined things that should
> be present in every implementation.
>
> --
> 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/guido%40python.org
>



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

From ronaldoussoren at mac.com  Sat Dec  1 16:24:45 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat, 1 Dec 2007 16:24:45 +0100
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <fipf27$db7$1@ger.gmane.org>
References: <200711301120.12630.mark@qtrac.eu>
	<e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>
	<475031CB.6090109@trueblade.com> <fipf27$db7$1@ger.gmane.org>
Message-ID: <D4C69877-EE80-49AE-A5D0-2B03AA4402AF@mac.com>


On 30 Nov, 2007, at 17:51, Christian Heimes wrote:

> Eric Smith wrote:
>> And backporting __format__ and friends back to trunk is on my pending
>> list.  The fact that upgrading to Leopard broke my compilation
>> environment isn't helping me out, unfortunately.
>
> I've seen several bugs related to Mac OS X 10.5 in the bug tracker.
> Could you test some patches for us when you get your build env working
> again?

Which bugs are that? The only ones I found when looking for 10.5 or  
Leopard are a feature request for 4-way universal builds (which is on  
my todo list) and a configure issue in 2.5.1 (which was fixed before  
Leopard was actually released).

BTW. feel free to ping me about 10.5 issues, I'm terrible at regularly  
checking the bugtracker.

Ronald
>
>
> 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/ronaldoussoren%40mac.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071201/a0c50878/attachment.bin 

From guido at python.org  Sun Dec  2 18:24:41 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 2 Dec 2007 09:24:41 -0800
Subject: [Python-3000] PyObject_AsString()
In-Reply-To: <47455A2C.70403@cheimes.de>
References: <fi38q6$1ka$1@ger.gmane.org>
	<e27efe130711220203yf71d215rc3b1fa450eb4b36f@mail.gmail.com>
	<47455A2C.70403@cheimes.de>
Message-ID: <ca471dc20712020924r26b4afc2pda39f424a84fdc4c@mail.gmail.com>

On Nov 22, 2007 2:30 AM, Christian Heimes <lists at cheimes.de> wrote:
> Amaury Forgeot d'Arc wrote:
> > Could this code replace the current PyString_AsStringAndSize, instead
> > of creating a new function?
>
> I guess it could. But it's a naming question. The method is more general
> and takes more than just instances of PyString and its subclasses.
> Therefor I think it should be part of the abstract protocol. Guido? :)

(Did I reply to this before? Can't remember. Getting old. :-)

Personally I think we should get rid of all this attempts at
micro-optimizations (most of which don't buy enough time to matter but
bloat the code), and just use the buffer API exclusively. The buffer
API can't replace PyString_AsStringAndSize since it requires a cleanup
call when you're done. Ideally that API disappears completely -- in
practice there are too many occurrences and the refactoring is a bit
complex to do automatically.

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

From lists at cheimes.de  Sun Dec  2 19:26:36 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 02 Dec 2007 19:26:36 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
Message-ID: <4752F8DC.6040103@cheimes.de>

A few hours ago I've renamed the remaining occurrences of PyInt_ to
PyLong_. Most PyInt_ were aliases for PyLong_ functions. I've also
removed the inclusion of intobject.h from Python.h but kept the file
with the aliases for porters from 2.x to 3.0. The remaining functions
are now in longobject.h.

longobject.h has still two PyInt_ functions: PyInt_GetMax and
PyInt_CheckExact.

long
PyInt_GetMax(void)
{
        return LONG_MAX;        /* To initialize sys.maxint */
}
It's only used for sys.maxint. Do we still need sys.maxint and
PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
better names.

The name for PyInt_CheckExact is confusing, too. It's defines as
PyInt_CheckExact(op) (PyLong_CheckExact(op) && _PyLong_FitsInLong(op)).
PyLong_CheckFitsInLong() or PyLong_CheckNativeLong() (Georg's idea) do
explain the meaning better.

The cleanup should make it much easier to rename PyLong to PyInt if
Guido decides to rename the type and functions after Alpa 2. A simple
find and xargs sed -i should be sufficient.

Christian

From martin at v.loewis.de  Sun Dec  2 21:56:20 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 02 Dec 2007 21:56:20 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <4752F8DC.6040103@cheimes.de>
References: <4752F8DC.6040103@cheimes.de>
Message-ID: <47531BF4.9090907@v.loewis.de>

> longobject.h has still two PyInt_ functions: PyInt_GetMax and
> PyInt_CheckExact.
> 
> long
> PyInt_GetMax(void)
> {
>         return LONG_MAX;        /* To initialize sys.maxint */
> }
> It's only used for sys.maxint. Do we still need sys.maxint and
> PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> better names.

I think they should go entirely. They don't give any interesting
information about the Python implementation.

> The name for PyInt_CheckExact is confusing, too. It's defines as
> PyInt_CheckExact(op) (PyLong_CheckExact(op) && _PyLong_FitsInLong(op)).
> PyLong_CheckFitsInLong() or PyLong_CheckNativeLong() (Georg's idea) do
> explain the meaning better.

No. It's not that the name is confusing - the implementation is.
PyInt_CheckExact tests whether the object is exactly the builtin
'int' type. Now that the original 'int' type is gone, it does not
make sense anymore to test for it - except that code does test for
it (which it should stop doing).

In most cases, PyInt_CheckExact was only used to determine whether
it is safe to invoke PyInt_AsLong; and the new definition of
PyInt_CheckExact has a good approximation for that case.

Regards,
Martin


From janssen at parc.com  Sun Dec  2 23:34:23 2007
From: janssen at parc.com (Bill Janssen)
Date: Sun, 2 Dec 2007 14:34:23 PST
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <4752F8DC.6040103@cheimes.de> 
References: <4752F8DC.6040103@cheimes.de>
Message-ID: <07Dec2.143429pst."58696"@synergy1.parc.xerox.com>

> A few hours ago I've renamed the remaining occurrences of PyInt_ to
> PyLong_. Most PyInt_ were aliases for PyLong_ functions. I've also
> removed the inclusion of intobject.h from Python.h but kept the file
> with the aliases for porters from 2.x to 3.0. The remaining functions
> are now in longobject.h.

So, now I can't build the 3K branch.

This is on OS X 10.5.0, gcc 4.0.1, "make clean; make":

/local/python/3k/src 75 % make
gcc   -o python.exe \
			Modules/python.o \
			libpython3.0.a -ldl      
Undefined symbols:
  "_PyInt_FromLong", referenced from:
      _ast2obj_int in libpython3.0.a(Python-ast.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1
/local/python/3k/src 76 % svn update
At revision 59281.
/local/python/3k/src 77 %

Bill

From lists at cheimes.de  Sun Dec  2 23:47:14 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 02 Dec 2007 23:47:14 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <07Dec2.143429pst."58696"@synergy1.parc.xerox.com>
References: <4752F8DC.6040103@cheimes.de>
	<07Dec2.143429pst."58696"@synergy1.parc.xerox.com>
Message-ID: <475335F2.5070905@cheimes.de>

Bill Janssen wrote:
> So, now I can't build the 3K branch.
> 
> This is on OS X 10.5.0, gcc 4.0.1, "make clean; make":
> 
> /local/python/3k/src 75 % make
> gcc   -o python.exe \
> 			Modules/python.o \
> 			libpython3.0.a -ldl      
> Undefined symbols:
>   "_PyInt_FromLong", referenced from:
>       _ast2obj_int in libpython3.0.a(Python-ast.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [python.exe] Error 1
> /local/python/3k/src 76 % svn update
> At revision 59281.
> /local/python/3k/src 77 %

I've fixed the bug. The asdl_c.py script is auto-generating some C code
for the parser. I didn't run into the problem because my file was up to
date.

Thanks!

Christian

From ncoghlan at gmail.com  Mon Dec  3 13:18:33 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 03 Dec 2007 22:18:33 +1000
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <20071130173806.9D12E3A408C@sparrow.telecommunity.com>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
	<20071130173806.9D12E3A408C@sparrow.telecommunity.com>
Message-ID: <4753F419.2010902@gmail.com>

Phillip J. Eby wrote:
> Well, for what class-level frame hacking is typically used for, it 
> would suffice to have a convenient way to refer to the local 
> namespace, e.g. if you could do something like:
> 
>      implements(@, IExample)
> 
> where @ was a shortcut for locals().  The most-used frame hacks (in 
> zope.interface and most PEAK tools) just want to access the namespace 
> of the current class definition, and maybe decorate the class in some way.

Aren't the metaclass changes in PEP 3115 partially aimed at eliminating 
the need for stack frame hackery to implement these kinds of things? 
(e.g. the metaclass could stuff a closure into the class namespace under 
the name 'implements' to avoid any need for frame hackery).

Cheers,
Nick.

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

From pje at telecommunity.com  Mon Dec  3 15:19:02 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 03 Dec 2007 09:19:02 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <4753F419.2010902@gmail.com>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
	<20071130173806.9D12E3A408C@sparrow.telecommunity.com>
	<4753F419.2010902@gmail.com>
Message-ID: <20071203141901.F1E153A40A5@sparrow.telecommunity.com>

At 10:18 PM 12/3/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > Well, for what class-level frame hacking is typically used for, it
> > would suffice to have a convenient way to refer to the local
> > namespace, e.g. if you could do something like:
> >
> >      implements(@, IExample)
> >
> > where @ was a shortcut for locals().  The most-used frame hacks (in
> > zope.interface and most PEAK tools) just want to access the namespace
> > of the current class definition, and maybe decorate the class in some way.
>
>Aren't the metaclass changes in PEP 3115 partially aimed at eliminating
>the need for stack frame hackery to implement these kinds of things?
>(e.g. the metaclass could stuff a closure into the class namespace under
>the name 'implements' to avoid any need for frame hackery).

Doesn't help.  You're assuming a *single* metaclass, which means you 
can't use things from more than one library in the same class.  It 
defeats any possibility of modularity.

I want method decorators and class-body decorators to be able to 
work, and to be able to use ones from different libraries in the same 
class, without needing to do manual metaclass mixing.  If Python 
automagically generated mixed metaclasses (as described in the book 
that Python's metaclass rules largely come from), it would be a lot 
less of a problem.


From lists at cheimes.de  Mon Dec  3 15:48:58 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 03 Dec 2007 15:48:58 +0100
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <4753F419.2010902@gmail.com>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>	<20071130173806.9D12E3A408C@sparrow.telecommunity.com>
	<4753F419.2010902@gmail.com>
Message-ID: <fj150q$jhe$1@ger.gmane.org>

Nick Coghlan wrote:
> Aren't the metaclass changes in PEP 3115 partially aimed at eliminating 
> the need for stack frame hackery to implement these kinds of things? 
> (e.g. the metaclass could stuff a closure into the class namespace under 
> the name 'implements' to avoid any need for frame hackery).

Couldn't we use a similar approach like the new super() magic? As far as
I remember super() can access its class through a new cell '__class__'.
Maybe we could introduce a similar way to access the namespace of a
class during its construction time?

class Example:
    implements(IExample)

def implements(*args):
    # The non local variable __class_ns__ is the namespace of the
    # class aka the dict returned by the __prepare__ function of
    # the meta class.
    nonlocal __class_ns__
    ...
    __class_ns__['spam'] = ...

Christian


From pje at telecommunity.com  Mon Dec  3 16:36:45 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 03 Dec 2007 10:36:45 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <fj150q$jhe$1@ger.gmane.org>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
	<20071130173806.9D12E3A408C@sparrow.telecommunity.com>
	<4753F419.2010902@gmail.com> <fj150q$jhe$1@ger.gmane.org>
Message-ID: <20071203153643.BB7033A40A5@sparrow.telecommunity.com>

At 03:48 PM 12/3/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > Aren't the metaclass changes in PEP 3115 partially aimed at eliminating
> > the need for stack frame hackery to implement these kinds of things?
> > (e.g. the metaclass could stuff a closure into the class namespace under
> > the name 'implements' to avoid any need for frame hackery).
>
>Couldn't we use a similar approach like the new super() magic? As far as
>I remember super() can access its class through a new cell '__class__'.
>Maybe we could introduce a similar way to access the namespace of a
>class during its construction time?

You can already access it with locals().  It's just that without 
_getframe, you have to do something like 'implements(locals(), IExample)'.


From jimjjewett at gmail.com  Mon Dec  3 17:42:29 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 3 Dec 2007 11:42:29 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <20071203153643.BB7033A40A5@sparrow.telecommunity.com>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
	<20071130173806.9D12E3A408C@sparrow.telecommunity.com>
	<4753F419.2010902@gmail.com> <fj150q$jhe$1@ger.gmane.org>
	<20071203153643.BB7033A40A5@sparrow.telecommunity.com>
Message-ID: <fb6fbf560712030842q7cd9695av697e1717fd7ba074@mail.gmail.com>

On 12/3/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:48 PM 12/3/2007 +0100, Christian Heimes wrote:
> >Nick Coghlan wrote:
> > > Aren't the metaclass changes in PEP 3115 partially aimed at
> > > eliminating the need for stack frame hackery to implement
> > > these kinds of things?

Yes.

> >Couldn't we use a similar approach like the new super() magic?

In theory, yes.  As it stands, the __class__ object doesn't exist
unless there is a super call.  This was for efficiency, and more
availablility was explicitly rejected.  That said, the rejection was
for insufficient motivation, so it could change if it needs to.

> > Maybe we could introduce a similar way to access the namespace
> > of a class during its construction time?

> You can already access it with locals().  It's just that without
> _getframe, you have to do something like 'implements(locals(),
> IExample)'.

Not according to http://docs.python.org/lib/built-in-funcs.html

"""
Warning: The contents of this dictionary should not be modified;
changes may not affect the values of local variables used by the
interpreter.
"""

Given that the "correct" mapping can now be passed in as part of
construction, I *think* that restriction could be removed for class
definition.

-jJ

From guido at python.org  Mon Dec  3 19:57:48 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 3 Dec 2007 10:57:48 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <47531BF4.9090907@v.loewis.de>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
Message-ID: <ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>

On Dec 2, 2007 12:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > It's only used for sys.maxint. Do we still need sys.maxint and
> > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > better names.
>
> I think they should go entirely. They don't give any interesting
> information about the Python implementation.

Actually it's still somewhat interesting to be able to tell whether a
particular Python build uses 64-bit pointer or 32-bit pointers. (I
realize sys.maxint doesn't quite tell us this, but on Linux at least
it does.) I also suspecet that sys.maxint is used frequently for "some
large integer" used as an approximation of infinity in some context.

> > The name for PyInt_CheckExact is confusing, too. It's defines as
> > PyInt_CheckExact(op) (PyLong_CheckExact(op) && _PyLong_FitsInLong(op)).
> > PyLong_CheckFitsInLong() or PyLong_CheckNativeLong() (Georg's idea) do
> > explain the meaning better.
>
> No. It's not that the name is confusing - the implementation is.
> PyInt_CheckExact tests whether the object is exactly the builtin
> 'int' type. Now that the original 'int' type is gone, it does not
> make sense anymore to test for it - except that code does test for
> it (which it should stop doing).
>
> In most cases, PyInt_CheckExact was only used to determine whether
> it is safe to invoke PyInt_AsLong; and the new definition of
> PyInt_CheckExact has a good approximation for that case.

IMO we should devise an API specifically for that. Or we should get
rid of it and force everyone to just call PyInt_AsLong and test for an
error return. But I suspect that would cause the code to be slightly
clumsier. (And slower if an error is detected, but that presumably
doesn't matter.)

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

From guido at python.org  Mon Dec  3 20:21:32 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 3 Dec 2007 11:21:32 -0800
Subject: [Python-3000] Heading towards 3.0a2 release this week
Message-ID: <ca471dc20712031121g462a7d4cw133f0a9770aea781@mail.gmail.com>

Hi folks,

I think we've made tremendous progress on Py3k recently, and I'd like
to do an official release of version 3.0a2 by the end of this week.

There's really only one issue that I'd like to address (personally)
before claiming it's ready: issue 1400, having to do with incomplete
implementation of line-buffering.

I don't recall exactly how we did the release last time; I'm thinking
of freezing the py3k branch Wednesday, working on getting the release
tarball built and tested on Thursday, and releasing early Friday
(early my time, that is -- 9am here is 6pm in most of Europe :-).

After 3.0a2 is released, I'd like to focus for a while on getting 2.6
in better shape -- a lot of stuff needs to be backported. At the same
time, in 3.0 we should focus on library reform.

Please mark any bugs that you think should be addressed before 3.0a2
as "high" (and assign them to me if they could benefit from my
attention).

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

From martin at v.loewis.de  Mon Dec  3 20:34:32 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 03 Dec 2007 20:34:32 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
Message-ID: <47545A48.20501@v.loewis.de>

> Actually it's still somewhat interesting to be able to tell whether a
> particular Python build uses 64-bit pointer or 32-bit pointers. (I
> realize sys.maxint doesn't quite tell us this, but on Linux at least
> it does.) 

Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
ctypes.sizeof(ctypes.py_object).

> I also suspecet that sys.maxint is used frequently for "some
> large integer" used as an approximation of infinity in some context.

Sure. However, 1<<1000 might do as well.

> IMO we should devise an API specifically for that. Or we should get
> rid of it and force everyone to just call PyInt_AsLong and test for an
> error return.

I'd be in favor of the latter. I never meant the PyInt_CheckExact hack
to persist into the release.

Regards,
Martin

From guido at python.org  Mon Dec  3 20:46:53 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 3 Dec 2007 11:46:53 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <47545A48.20501@v.loewis.de>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<47545A48.20501@v.loewis.de>
Message-ID: <ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>

On Dec 3, 2007 11:34 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Actually it's still somewhat interesting to be able to tell whether a
> > particular Python build uses 64-bit pointer or 32-bit pointers. (I
> > realize sys.maxint doesn't quite tell us this, but on Linux at least
> > it does.)
>
> Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
> ctypes.sizeof(ctypes.py_object).

Much less intuitive though.

> > I also suspecet that sys.maxint is used frequently for "some
> > large integer" used as an approximation of infinity in some context.
>
> Sure. However, 1<<1000 might do as well.

Fair enough. (or 2**64 :-)

> > IMO we should devise an API specifically for that. Or we should get
> > rid of it and force everyone to just call PyInt_AsLong and test for an
> > error return.
>
> I'd be in favor of the latter. I never meant the PyInt_CheckExact hack
> to persist into the release.

OK. What's needed?

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

From martin at v.loewis.de  Mon Dec  3 21:12:00 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 03 Dec 2007 21:12:00 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>	
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>	
	<47545A48.20501@v.loewis.de>
	<ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>
Message-ID: <47546310.6030806@v.loewis.de>

>> Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
>> ctypes.sizeof(ctypes.py_object).
> 
> Much less intuitive though.

Actually, I find the ctypes version a more direct answer to the
question "what is the address space?".

>> I'd be in favor of the latter. I never meant the PyInt_CheckExact hack
>> to persist into the release.
> 
> OK. What's needed?

The remaining occurrences of PyInt_CheckExact must be replaced with
PyLong_Check, and the subsequent PyLong_AsLong calls must check for
overflow. There are 22 uses still left. The ones in ceval.c are
quite tricky: it's not clear that the speed-up they originally meant
to provide is still present. The options would be to either continue
special-casing small integers, or to remove the check altogether,
trusting that the binary operator is fast enough (which may actually
involve fewer function calls than the "inline" version).

Regards,
Martin


From guido at python.org  Mon Dec  3 21:20:14 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 3 Dec 2007 12:20:14 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <47546310.6030806@v.loewis.de>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<47545A48.20501@v.loewis.de>
	<ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>
	<47546310.6030806@v.loewis.de>
Message-ID: <ca471dc20712031220x59d1f6a1r600f4bd704495a6c@mail.gmail.com>

On Dec 3, 2007 12:12 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> >> Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
> >> ctypes.sizeof(ctypes.py_object).
> >
> > Much less intuitive though.
>
> Actually, I find the ctypes version a more direct answer to the
> question "what is the address space?".

Also the more correct answer. :-)

It's just that I didn't even know about it -- and I suspect most users
would never think of it. OTOH most users will expect sys.maxint to be
2**63-1 on a 64-bit machine (never mind that they are wrong for Win64
:-).

> >> I'd be in favor of the latter. I never meant the PyInt_CheckExact hack
> >> to persist into the release.
> >
> > OK. What's needed?
>
> The remaining occurrences of PyInt_CheckExact must be replaced with
> PyLong_Check, and the subsequent PyLong_AsLong calls must check for
> overflow. There are 22 uses still left. The ones in ceval.c are
> quite tricky: it's not clear that the speed-up they originally meant
> to provide is still present. The options would be to either continue
> special-casing small integers, or to remove the check altogether,
> trusting that the binary operator is fast enough (which may actually
> involve fewer function calls than the "inline" version).

I would remove the optimizations for now; we should benchmark again
later in the 3.0 beta release cycle. In general I'm all for removing
clutter that was once added in the hope of speeding things up; for 3.0
my main priority is correctness.

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

From jimjjewett at gmail.com  Tue Dec  4 16:55:23 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 4 Dec 2007 10:55:23 -0500
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712031220x59d1f6a1r600f4bd704495a6c@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<47545A48.20501@v.loewis.de>
	<ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>
	<47546310.6030806@v.loewis.de>
	<ca471dc20712031220x59d1f6a1r600f4bd704495a6c@mail.gmail.com>
Message-ID: <fb6fbf560712040755j6a61a267te814bd5e80b7d16e@mail.gmail.com>

On 12/3/07, Guido van Rossum <guido at python.org> wrote:
> On Dec 3, 2007 12:12 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > >> Sure. However, you could also use
> > >> _testcapi.PY_SSIZE_T_MAX, or
> > >> ctypes.sizeof(ctypes.py_object).

> > > Much less intuitive though.

> > Actually, I find the ctypes version a more direct answer to the
> > question "what is the address space?".

(1)  Is there a valid use case for this that needs to be supported
with the "same code" across distributions before ctypes?

(2)  Is "without ctypes" still a supported build configuration,
because of the crash-risks?  More narrowly, is can we assume that they
don't need the exact size/address unless they're doing extensions that
have at least as much risk as ctypes?

> It's just that I didn't even know about it -- and I suspect most users
> would never think of it. OTOH most users will expect sys.maxint to
> be 2**63-1 on a 64-bit machine (never mind that they are wrong for
> Win64 :-).

I think anyone expecting a particular number would also expect that
integers larger are in some way special.  Whether they need to use
doubles (as in C) or they fail entirely, or they just slow down
(python 2.x) ... they should be special.

Maybe sys.maxint should just be removed entirely.

Reasons to keep it:
   It is useful information, even it isn't quite what the naive expect.
   It serves as a "really big integer".

Reasons to drop it:
   Attractive nuisance that isn't quite correct.

> I would remove the optimizations for now; we should benchmark
> again later in the 3.0 beta release cycle. In general I'm all for
> removing clutter that was once added in the hope of speeding
> things up; for 3.0 my main priority is correctness.

When this happens, what should be left behind?

(a)  Nothing -- just go to subversion
(b)  A comment that this was optimized in the past
(c)  A note in some sort of "optimiation ideas" readme

-jJ

From guido at python.org  Tue Dec  4 17:50:30 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 4 Dec 2007 08:50:30 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <fb6fbf560712040755j6a61a267te814bd5e80b7d16e@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<47545A48.20501@v.loewis.de>
	<ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>
	<47546310.6030806@v.loewis.de>
	<ca471dc20712031220x59d1f6a1r600f4bd704495a6c@mail.gmail.com>
	<fb6fbf560712040755j6a61a267te814bd5e80b7d16e@mail.gmail.com>
Message-ID: <ca471dc20712040850h5d4bab06uec29c889f95f98c4@mail.gmail.com>

On Dec 4, 2007 7:55 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 12/3/07, Guido van Rossum <guido at python.org> wrote:
> > On Dec 3, 2007 12:12 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > >> Sure. However, you could also use
> > > >> _testcapi.PY_SSIZE_T_MAX, or
> > > >> ctypes.sizeof(ctypes.py_object).
>
> > > > Much less intuitive though.
>
> > > Actually, I find the ctypes version a more direct answer to the
> > > question "what is the address space?".
>
> (1)  Is there a valid use case for this that needs to be supported
> with the "same code" across distributions before ctypes?
>
> (2)  Is "without ctypes" still a supported build configuration,
> because of the crash-risks?  More narrowly, is can we assume that they
> don't need the exact size/address unless they're doing extensions that
> have at least as much risk as ctypes?
>
> > It's just that I didn't even know about it -- and I suspect most users
> > would never think of it. OTOH most users will expect sys.maxint to
> > be 2**63-1 on a 64-bit machine (never mind that they are wrong for
> > Win64 :-).
>
> I think anyone expecting a particular number would also expect that
> integers larger are in some way special.  Whether they need to use
> doubles (as in C) or they fail entirely, or they just slow down
> (python 2.x) ... they should be special.
>
> Maybe sys.maxint should just be removed entirely.
>
> Reasons to keep it:
>    It is useful information, even it isn't quite what the naive expect.
>    It serves as a "really big integer".
>
> Reasons to drop it:
>    Attractive nuisance that isn't quite correct.
>
> > I would remove the optimizations for now; we should benchmark
> > again later in the 3.0 beta release cycle. In general I'm all for
> > removing clutter that was once added in the hope of speeding
> > things up; for 3.0 my main priority is correctness.
>
> When this happens, what should be left behind?
>
> (a)  Nothing -- just go to subversion
> (b)  A comment that this was optimized in the past
> (c)  A note in some sort of "optimiation ideas" readme
>
> -jJ
>

definitely (a)

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

From thomas at python.org  Tue Dec  4 17:55:58 2007
From: thomas at python.org (Thomas Wouters)
Date: Tue, 4 Dec 2007 17:55:58 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
Message-ID: <9e804ac0712040855w10b95e40u73864be2c9be7bab@mail.gmail.com>

On Dec 3, 2007 7:57 PM, Guido van Rossum <guido at python.org> wrote:

> On Dec 2, 2007 12:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > It's only used for sys.maxint. Do we still need sys.maxint and
> > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > > better names.
> >
> > I think they should go entirely. They don't give any interesting
> > information about the Python implementation.
>
> Actually it's still somewhat interesting to be able to tell whether a
> particular Python build uses 64-bit pointer or 32-bit pointers. (I
> realize sys.maxint doesn't quite tell us this, but on Linux at least
> it does.)


The removal of classic slices already added sys.maxsize, which is the max of
Py_ssize_t.

-- 
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/20071204/c400e8ec/attachment.htm 

From lists at cheimes.de  Tue Dec  4 20:21:25 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 04 Dec 2007 20:21:25 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <9e804ac0712040855w10b95e40u73864be2c9be7bab@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de>
	<47531BF4.9090907@v.loewis.de>	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<9e804ac0712040855w10b95e40u73864be2c9be7bab@mail.gmail.com>
Message-ID: <4755A8B5.7070007@cheimes.de>

Thomas Wouters wrote:
> The removal of classic slices already added sys.maxsize, which is the max of
> Py_ssize_t.

Great. If I'm not mistaken the max of Py_ssize_t should be 2**31-1 on a
32bit system and 2**63-1 on a 64bit system, even on Win x64 and IA-64.

Guido, it's your call. Should sys.maxint go?

Christian

From theller at ctypes.org  Tue Dec  4 21:53:56 2007
From: theller at ctypes.org (Thomas Heller)
Date: Tue, 04 Dec 2007 21:53:56 +0100
Subject: [Python-3000] win64 buildbot hangs in test
Message-ID: <fj4ep4$m4k$1@ger.gmane.org>

The win64 buildbot testing stage hangs.  The only thing that I can see
is (I have no time to investigate further) in processexplorer:

'python -E -tt ../lib/test/regrtest.py -uall -rw' has started this process which hangs:

'cmd /c ""C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcvarsall.bat" x64 & set"


Thomas


From guido at python.org  Tue Dec  4 22:21:40 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 4 Dec 2007 13:21:40 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <4755A8B5.7070007@cheimes.de>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<9e804ac0712040855w10b95e40u73864be2c9be7bab@mail.gmail.com>
	<4755A8B5.7070007@cheimes.de>
Message-ID: <ca471dc20712041321p12aba513u69abdaf7a9f30df8@mail.gmail.com>

On Dec 4, 2007 11:21 AM, Christian Heimes <lists at cheimes.de> wrote:
> Thomas Wouters wrote:
> > The removal of classic slices already added sys.maxsize, which is the max of
> > Py_ssize_t.
>
> Great. If I'm not mistaken the max of Py_ssize_t should be 2**31-1 on a
> 32bit system and 2**63-1 on a 64bit system, even on Win x64 and IA-64.
>
> Guido, it's your call. Should sys.maxint go?

OK, with sys.maxsize as the logical replacement, it can go. Make sure
to fix everything that breaks before submitting though!

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

From lists at cheimes.de  Wed Dec  5 00:13:19 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 05 Dec 2007 00:13:19 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712041321p12aba513u69abdaf7a9f30df8@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de>
	<47531BF4.9090907@v.loewis.de>	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>	<9e804ac0712040855w10b95e40u73864be2c9be7bab@mail.gmail.com>	<4755A8B5.7070007@cheimes.de>
	<ca471dc20712041321p12aba513u69abdaf7a9f30df8@mail.gmail.com>
Message-ID: <4755DF0F.8010101@cheimes.de>

Guido van Rossum wrote:
> OK, with sys.maxsize as the logical replacement, it can go. Make sure
> to fix everything that breaks before submitting though!

I've removed sys.maxint and replaced sys.maxint with sys.maxsize. Does
anybody see a problem with the Windows 64bit platform? AFAIK it's the
only platform where sys.maxint != sys.maxsize.

Christian


From theller at ctypes.org  Wed Dec  5 13:20:55 2007
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 05 Dec 2007 13:20:55 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <fb6fbf560712040755j6a61a267te814bd5e80b7d16e@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de>
	<47531BF4.9090907@v.loewis.de>	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>	<47545A48.20501@v.loewis.de>	<ca471dc20712031146k7cc25cc6o7d675df5cad0b549@mail.gmail.com>	<47546310.6030806@v.loewis.de>	<ca471dc20712031220x59d1f6a1r600f4bd704495a6c@mail.gmail.com>
	<fb6fbf560712040755j6a61a267te814bd5e80b7d16e@mail.gmail.com>
Message-ID: <fj6537$e9i$1@ger.gmane.org>

Jim Jewett schrieb:
> On 12/3/07, Guido van Rossum <guido at python.org> wrote:
>> On Dec 3, 2007 12:12 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> > >> Sure. However, you could also use
>> > >> _testcapi.PY_SSIZE_T_MAX, or
>> > >> ctypes.sizeof(ctypes.py_object).
> 
>> > > Much less intuitive though.
> 
>> > Actually, I find the ctypes version a more direct answer to the
>> > question "what is the address space?".
> 
> (1)  Is there a valid use case for this that needs to be supported
> with the "same code" across distributions before ctypes?

> (2)  Is "without ctypes" still a supported build configuration,
> because of the crash-risks?  More narrowly, is can we assume that they
> don't need the exact size/address unless they're doing extensions that
> have at least as much risk as ctypes?

Not sure about these.  However, there is still struct.calcsize("P") and variants thereof.

Thomas


From lists at cheimes.de  Wed Dec  5 18:54:05 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 05 Dec 2007 18:54:05 +0100
Subject: [Python-3000] Include 2to3 tool with svn:external
Message-ID: <fj6oju$m6t$1@ger.gmane.org>

For the upcoming release I like to add the 2to3 tools to the
branches/py3k/Tools/ directory with an svn:external property. Or do you
plan to release the 2to3 as standalone tool?

Christian


From guido at python.org  Wed Dec  5 20:34:24 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Dec 2007 11:34:24 -0800
Subject: [Python-3000] Include 2to3 tool with svn:external
In-Reply-To: <fj6oju$m6t$1@ger.gmane.org>
References: <fj6oju$m6t$1@ger.gmane.org>
Message-ID: <ca471dc20712051134p78e16b70k7f3f187d91053d98@mail.gmail.com>

I believe Collin is planning on doing a stand-alone release. But
having it in the 3.0a2 tarball makes sense so go ahead!

On Dec 5, 2007 9:54 AM, Christian Heimes <lists at cheimes.de> wrote:
> For the upcoming release I like to add the 2to3 tools to the
> branches/py3k/Tools/ directory with an svn:external property. Or do you
> plan to release the 2to3 as standalone tool?

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

From guido at python.org  Thu Dec  6 02:46:40 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Dec 2007 17:46:40 -0800
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
Message-ID: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>

I'm planning to freeze the py3k branch in 2-3 hours, some time
after/around 8pm PST (midnight UTC).

If someone wants to do another svnmerge from the trunk please do it
before then -- though we're nearly current so I don't mind not having
the last few changes merged into this release (it's only Raymond's
refactoring of __length_hint__ implementations).

If there's anything you think really should be in this release, please
speak up ASAP. Filing a high priority bug and assigning it to me would
be a great way to get my attention.

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

From brett at python.org  Thu Dec  6 05:14:38 2007
From: brett at python.org (Brett Cannon)
Date: Wed, 5 Dec 2007 20:14:38 -0800
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
Message-ID: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>

As Guido stated in a recent email, the stdlib reorg is going to be the
next big thing in Py3K-Land after a2 goes out the door.  And since I
stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
several times before, I am the de-facto junior dictator in charge of
the reorganization of the stdlib.

The plan is to get this done by summer.  While that might seem like a
long ways off, this is open source, so everyone's time is restricted.
Plus, as I know from personal experience, people love to argue over
how to organize stuff, and so the resulting flame wars always take up
time and energy.

Plus I am only a single person and I know that my opinion does not
always mesh with everyone else out there (there is a reason why most
of my PEPs end up being heavily cut back  =) .  So I am asking anyone
who is interested in helping me out with this to reply to this thread.
 That way most of the work can be done off-list in a more sane manner
first where I can keep the flames down to a minimum to actually get
this done without my getting blood pressure problems too early in
life.

And remember that the reorg is not to make the stdlib some deeply
nested package (nor add a root package name!).  It is to fix module
naming issues, remove obsolete stuff (both of which are pretty well
covered by PEP 3108), and to create some shallow packages (i.e., take
some top-level modules and put them into a single package with no
nesting).  There might even be a module merger or two.

So if this sounds interesting to you and you want to help me, let me know.

-Brett

From guido at python.org  Thu Dec  6 05:43:10 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Dec 2007 20:43:10 -0800
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
Message-ID: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>

I've built and tested the latest py3k from scratch on Ubuntu, Fedora
7, OSX 10.4 and OSX 10.5, and found no issues.

So the code freeze is a fact. Don't check anything into the py3k
branch unless I tell you to. Please file high-priority bugs and assign
them to me if you think you've found a showstopper.

The buildbot is green for Solaris also, so I think we're in good
shape. I don't see any green buildbots for Windows though, but Windows
is always a flakey situation; Christian, what's your assessment?

I see a few tests leaking; in particular test_ssl (1522 refs leaned
per run!) and test_urllib2_localnet (3 per run). Anyone interested in
researching these feel free to do so; just upload a patch and file a
bug if you've squashed the leaks (or some).

We're on for a 3.0a2 release Friday!

--Guido

On Dec 5, 2007 5:46 PM, Guido van Rossum <guido at python.org> wrote:
> I'm planning to freeze the py3k branch in 2-3 hours, some time
> after/around 8pm PST (midnight UTC).
>
> If someone wants to do another svnmerge from the trunk please do it
> before then -- though we're nearly current so I don't mind not having
> the last few changes merged into this release (it's only Raymond's
> refactoring of __length_hint__ implementations).
>
> If there's anything you think really should be in this release, please
> speak up ASAP. Filing a high priority bug and assigning it to me would
> be a great way to get my attention.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



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

From alexandre at peadrop.com  Thu Dec  6 05:57:59 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 5 Dec 2007 23:57:59 -0500
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <acd65fa20712052057o373853e2mcbf6654890b227ee@mail.gmail.com>

On Dec 5, 2007 11:14 PM, Brett Cannon <brett at python.org> wrote:
> So if this sounds interesting to you and you want to help me, let me know.
>

I am interested -- mainly in writing the import fixers and renaming
the modules.

-- Alexandre

From lists at cheimes.de  Thu Dec  6 09:46:47 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 06 Dec 2007 09:46:47 +0100
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
Message-ID: <4757B6F7.8040501@cheimes.de>

Guido van Rossum wrote:
> The buildbot is green for Solaris also, so I think we're in good
> shape. I don't see any green buildbots for Windows though, but Windows
> is always a flakey situation; Christian, what's your assessment?

test_mailbox is still failing with lots of errors. The module needs
extra embracement and love on Windows. Most to all of the problems are
related to the newline separator \r\n.

Some modules are also failing when I run a refleak regression test, see
http://bugs.python.org/issue1540

I've ironed out the last cosmetic problems in the PCbuild9 directory and
profile guided optimization builds. A PGO version can be build with
"build_pgo -2" (runs the complete unit test suite) or "build_pgo" (runs
PyBench) in a VS 2008 command shell. The x64 builds are looking fine
except of tkinter (it doesn't build) but I'm not able to test the x64
version on my computer.

Could you please add two comments to the release notes for Windows users?

* On Windows Python can't be run from a directory with non ASCII chars
in its path name. #1342

* The current releases of MinGW and Cygwin can't build Python extensions
since they don't support msvcr90.dll. The necessary bits and pieces are
already in Python and cygwin cvs.

> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!) and test_urllib2_localnet (3 per run). Anyone interested in
> researching these feel free to do so; just upload a patch and file a
> bug if you've squashed the leaks (or some).

The test_ssl tests are only leaking with the -unetwork option. On my
Ubuntu box they are leaking 1536 references per turn. For heaven's sake
I can't remember how I found the leaking code lines the last time.
Py_DUMP_REFS dumps too many information.

Christian

From qgallet at gmail.com  Thu Dec  6 10:46:09 2007
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Thu, 6 Dec 2007 10:46:09 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <8b943f2b0712060146s130f489ai7f9dec03cdd4d919@mail.gmail.com>

I've been following the lists and the bug tracker for some months and am
beginning to contribute fairly trivial patches. I haven't done much yet, but
I'm interested in the stdlib reorg. If rookies are welcomed, please count me
in :-)

Quentin

On Dec 6, 2007 5:14 AM, Brett Cannon <brett at python.org> wrote:

> As Guido stated in a recent email, the stdlib reorg is going to be the
> next big thing in Py3K-Land after a2 goes out the door.  And since I
> stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
> several times before, I am the de-facto junior dictator in charge of
> the reorganization of the stdlib.
>
> The plan is to get this done by summer.  While that might seem like a
> long ways off, this is open source, so everyone's time is restricted.
> Plus, as I know from personal experience, people love to argue over
> how to organize stuff, and so the resulting flame wars always take up
> time and energy.
>
> Plus I am only a single person and I know that my opinion does not
> always mesh with everyone else out there (there is a reason why most
> of my PEPs end up being heavily cut back  =) .  So I am asking anyone
> who is interested in helping me out with this to reply to this thread.
>  That way most of the work can be done off-list in a more sane manner
> first where I can keep the flames down to a minimum to actually get
> this done without my getting blood pressure problems too early in
> life.
>
> And remember that the reorg is not to make the stdlib some deeply
> nested package (nor add a root package name!).  It is to fix module
> naming issues, remove obsolete stuff (both of which are pretty well
> covered by PEP 3108), and to create some shallow packages (i.e., take
> some top-level modules and put them into a single package with no
> nesting).  There might even be a module merger or two.
>
> So if this sounds interesting to you and you want to help me, let me know.
>
> -Brett
> _______________________________________________
> 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/qgallet%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071206/1d466f02/attachment-0001.htm 

From ronaldoussoren at mac.com  Thu Dec  6 11:23:59 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 6 Dec 2007 11:23:59 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <AEC529DD-5043-46AB-9BAB-6C0647006922@mac.com>


On 6 Dec, 2007, at 5:14, Brett Cannon wrote:

> As Guido stated in a recent email, the stdlib reorg is going to be the
> next big thing in Py3K-Land after a2 goes out the door.  And since I
> stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
> several times before, I am the de-facto junior dictator in charge of
> the reorganization of the stdlib.
>
[...]

>
> So if this sounds interesting to you and you want to help me, let me  
> know.

I'm interested to help out with the plat-mac stuff.

Ronald
>
>
> -Brett
> _______________________________________________
> 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/ronaldoussoren%40mac.com


From amauryfa at gmail.com  Thu Dec  6 11:42:10 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 6 Dec 2007 11:42:10 +0100
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <4757B6F7.8040501@cheimes.de>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
	<4757B6F7.8040501@cheimes.de>
Message-ID: <e27efe130712060242t2440b6a3gab59eb489ae0c85b@mail.gmail.com>

Christian Heimes wrote:
> Guido van Rossum wrote:
> > The buildbot is green for Solaris also, so I think we're in good
> > shape. I don't see any green buildbots for Windows though, but Windows
> > is always a flakey situation; Christian, what's your assessment?
>
> test_mailbox is still failing with lots of errors. The module needs
> extra embracement and love on Windows. Most to all of the problems are
> related to the newline separator \r\n.

I submitted http://bugs.python.org/issue1561 for discussion and
resolution of this problem. Meanwhile, I propose to skip this test,
and tell about this in the release notes for Windows.

-- 
Amaury Forgeot d'Arc

From skip at pobox.com  Thu Dec  6 14:37:30 2007
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 6 Dec 2007 07:37:30 -0600
Subject: [Python-3000] PEP 3108 - recommendations for PyPI transition
Message-ID: <18263.64282.69977.190401@montanaro.dyndns.org>


I won't argue that getopt should be left in for Python 3, however it is
still widely used.  I generally use it for simple tasks.  (My brain must
have a getopt usage template in there somewhere.  I still find it much
easier to whip out getopt usage.  I always have to consult the optparse
docs.)  It should probably at least go on PyPI.

Likewise, I suspect bsddb185 will still have some occasional uses, at least
on BSD Unix variants.  On my Mac /etc/pwd.db and /etc/mail/*.db are 1.85
hash files.  Maybe also a candidate for PyPI.

Should the PEP acknowledge this route to module sainthood for certain
modules?

Skip

From facundobatista at gmail.com  Thu Dec  6 14:56:49 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 6 Dec 2007 10:56:49 -0300
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <e04bdf310712060556x4ea27862ya4bd51fb4599bdc1@mail.gmail.com>

2007/12/6, Brett Cannon <brett at python.org>:

> The plan is to get this done by summer.  While that might seem like a
> long ways off, this is open source, so everyone's time is restricted.

Note that you could propose an sprint in PyCon 2008 for this...


> of my PEPs end up being heavily cut back  =) .  So I am asking anyone
> who is interested in helping me out with this to reply to this thread.
>  That way most of the work can be done off-list in a more sane manner

Will you create another mail list for this specific issue?


> So if this sounds interesting to you and you want to help me, let me know.

I'm in.

Regards,

-- 
.    Facundo

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

From g.brandl at gmx.net  Thu Dec  6 15:12:02 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 06 Dec 2007 15:12:02 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <fj8vrv$a1g$1@ger.gmane.org>

Brett Cannon schrieb:
> As Guido stated in a recent email, the stdlib reorg is going to be the
> next big thing in Py3K-Land after a2 goes out the door.  And since I
> stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
> several times before, I am the de-facto junior dictator in charge of
> the reorganization of the stdlib.

> So if this sounds interesting to you and you want to help me, let me know.

Count me in - I'll try to handle the documentation side of the project.

cheers,
Georg


From lists at cheimes.de  Thu Dec  6 15:58:35 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 06 Dec 2007 15:58:35 +0100
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
Message-ID: <47580E1B.10103@cheimes.de>

Guido van Rossum wrote:
> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!) and test_urllib2_localnet (3 per run). Anyone interested in
> researching these feel free to do so; just upload a patch and file a
> bug if you've squashed the leaks (or some).

I see the reference leaks, too. I didn't notice the ssl leaks before
because I usually don't run the refleak test with -unetwork or -uall.

./python Lib/test/regrtest.py -R1:2 -unetwork test_ssl

I've started to work on a patch that adds GC support to Modules/_ssl.c
PySSLObject but I don't have time to finish it until tonight.
http://bugs.python.org/issue1469

Christian

From lists at cheimes.de  Thu Dec  6 15:58:35 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 06 Dec 2007 15:58:35 +0100
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
Message-ID: <47580E1B.10103@cheimes.de>

Guido van Rossum wrote:
> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!) and test_urllib2_localnet (3 per run). Anyone interested in
> researching these feel free to do so; just upload a patch and file a
> bug if you've squashed the leaks (or some).

I see the reference leaks, too. I didn't notice the ssl leaks before
because I usually don't run the refleak test with -unetwork or -uall.

./python Lib/test/regrtest.py -R1:2 -unetwork test_ssl

I've started to work on a patch that adds GC support to Modules/_ssl.c
PySSLObject but I don't have time to finish it until tonight.
http://bugs.python.org/issue1469

Christian


From guido at python.org  Thu Dec  6 16:37:17 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 6 Dec 2007 07:37:17 -0800
Subject: [Python-3000] PEP 3108 - recommendations for PyPI transition
In-Reply-To: <18263.64282.69977.190401@montanaro.dyndns.org>
References: <18263.64282.69977.190401@montanaro.dyndns.org>
Message-ID: <ca471dc20712060737u37eaebe7yab5fbe9cfd81f903@mail.gmail.com>

I don't know who proposed to rip out getopt. I definitely want to keep
it. It has plenty of uses where optparse would be overkill.

--Guido

On Dec 6, 2007 5:37 AM,  <skip at pobox.com> wrote:
>
> I won't argue that getopt should be left in for Python 3, however it is
> still widely used.  I generally use it for simple tasks.  (My brain must
> have a getopt usage template in there somewhere.  I still find it much
> easier to whip out getopt usage.  I always have to consult the optparse
> docs.)  It should probably at least go on PyPI.
>
> Likewise, I suspect bsddb185 will still have some occasional uses, at least
> on BSD Unix variants.  On my Mac /etc/pwd.db and /etc/mail/*.db are 1.85
> hash files.  Maybe also a candidate for PyPI.
>
> Should the PEP acknowledge this route to module sainthood for certain
> modules?
>
> Skip
> _______________________________________________
> 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 janssen at parc.com  Thu Dec  6 18:46:52 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 6 Dec 2007 09:46:52 PST
Subject: [Python-3000] [Python-Dev] Py3k code freeze imminent;
	3.0a2 release Friday
In-Reply-To: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com> 
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
Message-ID: <07Dec6.094654pst."58696"@synergy1.parc.xerox.com>

> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!)

I'm looking at this, but I haven't found anything in the last week...

Bill

From janssen at parc.com  Thu Dec  6 18:48:45 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 6 Dec 2007 09:48:45 PST
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <4757B6F7.8040501@cheimes.de> 
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
	<4757B6F7.8040501@cheimes.de>
Message-ID: <07Dec6.094849pst."58696"@synergy1.parc.xerox.com>

> The test_ssl tests are only leaking with the -unetwork option. On my
> Ubuntu box they are leaking 1536 references per turn. For heaven's sake
> I can't remember how I found the leaking code lines the last time.
> Py_DUMP_REFS dumps too many information.

I found the leak the last time by narrowing down the tests, test by
test.

It was leaking sockets because they got dropped on the floor when a
connect failed.  I'll look at this some more this weekend.

Bill

From dirkjan at ochtman.nl  Thu Dec  6 19:32:40 2007
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Thu, 06 Dec 2007 19:32:40 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <fj9f88$dal$2@ger.gmane.org>

Brett Cannon wrote:
> So if this sounds interesting to you and you want to help me, let me know.

This sounds interesting to me and I want to help you. ;)

Cheers,

Dirkjan


From brett at python.org  Thu Dec  6 20:01:24 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 6 Dec 2007 11:01:24 -0800
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <e04bdf310712060556x4ea27862ya4bd51fb4599bdc1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
	<e04bdf310712060556x4ea27862ya4bd51fb4599bdc1@mail.gmail.com>
Message-ID: <bbaeab100712061101u4225c295n6d12413ff8088630@mail.gmail.com>

On Dec 6, 2007 5:56 AM, Facundo Batista <facundobatista at gmail.com> wrote:
> 2007/12/6, Brett Cannon <brett at python.org>:
>
> > The plan is to get this done by summer.  While that might seem like a
> > long ways off, this is open source, so everyone's time is restricted.
>
> Note that you could propose an sprint in PyCon 2008 for this...
>

I know, but I have other things I would rather be working on at PyCon.  =)

>
> > of my PEPs end up being heavily cut back  =) .  So I am asking anyone
> > who is interested in helping me out with this to reply to this thread.
> >  That way most of the work can be done off-list in a more sane manner
>
> Will you create another mail list for this specific issue?
>

Quite possibly considering how many people have stepped forward.
Maybe a stdlib-sig mailing list or something.  I just don't want the
list to be unwieldy; the whole point of doing this off of python-3000
is to keep it focused and prevent people from flipping out over a
disagreement of where a module goes.

>
> > So if this sounds interesting to you and you want to help me, let me know.
>
> I'm in.

Great!  Thanks, Facundo (and everyone else who is stepping forward).

-Brett

From hasan.diwan at gmail.com  Thu Dec  6 20:02:35 2007
From: hasan.diwan at gmail.com (Hasan Diwan)
Date: Thu, 6 Dec 2007 14:02:35 -0500
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <fj9f88$dal$2@ger.gmane.org>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
	<fj9f88$dal$2@ger.gmane.org>
Message-ID: <2cda2fc90712061102x243008c2yad2a3a14b6e70e3c@mail.gmail.com>

> Brett Cannon wrote:
> > let me know.

Let me know what needs to be done.
-- 
Cheers,
Hasan Diwan <hasan.diwan at gmail.com>

From alexandre at peadrop.com  Thu Dec  6 20:05:14 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 6 Dec 2007 14:05:14 -0500
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <2cda2fc90712061102x243008c2yad2a3a14b6e70e3c@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
	<fj9f88$dal$2@ger.gmane.org>
	<2cda2fc90712061102x243008c2yad2a3a14b6e70e3c@mail.gmail.com>
Message-ID: <acd65fa20712061105j63917adcvf1ae9187379ee5a8@mail.gmail.com>

On Dec 6, 2007 2:02 PM, Hasan Diwan <hasan.diwan at gmail.com> wrote:
> > Brett Cannon wrote:
> > > let me know.
>
> Let me know what needs to be done.

See PEP-3108: http://www.python.org/dev/peps/pep-3108/

-- Alexandre

From brett at python.org  Thu Dec  6 20:16:38 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 6 Dec 2007 11:16:38 -0800
Subject: [Python-3000] PEP 3108 - recommendations for PyPI transition
In-Reply-To: <18263.64282.69977.190401@montanaro.dyndns.org>
References: <18263.64282.69977.190401@montanaro.dyndns.org>
Message-ID: <bbaeab100712061116x4486f037wde2287c13ec8a34e@mail.gmail.com>

On Dec 6, 2007 5:37 AM,  <skip at pobox.com> wrote:
>
> I won't argue that getopt should be left in for Python 3, however it is
> still widely used.  I generally use it for simple tasks.  (My brain must
> have a getopt usage template in there somewhere.  I still find it much
> easier to whip out getopt usage.  I always have to consult the optparse
> docs.)  It should probably at least go on PyPI.

Just updated the PEP for it to stay.

>
> Likewise, I suspect bsddb185 will still have some occasional uses, at least
> on BSD Unix variants.  On my Mac /etc/pwd.db and /etc/mail/*.db are 1.85
> hash files.  Maybe also a candidate for PyPI.
>

The module has already been removed so someone will have to step
forward to resurrect it.  Considering it has not been part of the
default build I really don't see why it should be saved.  But if
someone wants to toss it up on the Cheeseshop I know I won't stop
them.

> Should the PEP acknowledge this route to module sainthood for certain
> modules?

Only if specific people step forward to handle taking the modules and
putting them up on the Cheeseshop will I bother with adding the
section.

-Brett

From brett at python.org  Thu Dec  6 20:19:24 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 6 Dec 2007 11:19:24 -0800
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <acd65fa20712061105j63917adcvf1ae9187379ee5a8@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
	<fj9f88$dal$2@ger.gmane.org>
	<2cda2fc90712061102x243008c2yad2a3a14b6e70e3c@mail.gmail.com>
	<acd65fa20712061105j63917adcvf1ae9187379ee5a8@mail.gmail.com>
Message-ID: <bbaeab100712061119o16cb7e97m9303204b10fd6bfc@mail.gmail.com>

On Dec 6, 2007 11:05 AM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On Dec 6, 2007 2:02 PM, Hasan Diwan <hasan.diwan at gmail.com> wrote:
> > > Brett Cannon wrote:
> > > > let me know.
> >
> > Let me know what needs to be done.
>
> See PEP-3108: http://www.python.org/dev/peps/pep-3108/

That is actually not totally true.  If you notice the PEP is still a
draft.  Guido has not accepted or rejected the PEP yet.  As of this
moment it just holds all of the ideas that people have not screamed
bloody murder over.  In the end it will hold the list of what is
planned to happen at which point Guido can put his seal of approval on
it.

-Brett

From p.f.moore at gmail.com  Thu Dec  6 20:35:19 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 6 Dec 2007 19:35:19 +0000
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <79990c6b0712061135u7b9c3aa6p5751125dad67d684@mail.gmail.com>

On 06/12/2007, Brett Cannon <brett at python.org> wrote:
> So if this sounds interesting to you and you want to help me, let me know.

I'm willing to help, but short of free time (you've seen the effects
of this from me before, Brett :-)). I'd be happy to look at Windows
compatibility issues (Python or C, now that I can easily build Python
again!)

Paul.

From lists at cheimes.de  Thu Dec  6 21:51:26 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 06 Dec 2007 21:51:26 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
In-Reply-To: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
References: <bbaeab100712052014s20605beeh20fde8095c7c4bd1@mail.gmail.com>
Message-ID: <475860CE.3030507@cheimes.de>

Brett Cannon wrote:
> So if this sounds interesting to you and you want to help me, let me know.

Count me in!
I can assist with C coding, 2t3 fixers and some find/grep/sed/awk magic.
I can also help you with reviewing and applying patches.

Christian

From solipsis at pitrou.net  Thu Dec  6 21:53:56 2007
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 06 Dec 2007 21:53:56 +0100
Subject: [Python-3000] Who wants to help me reorganize the stdlib?
Message-ID: <1196974436.7435.6.camel@fsol>


Hi,

> Plus I am only a single person and I know that my opinion does not
> always mesh with everyone else out there (there is a reason why most
> of my PEPs end up being heavily cut back  =) .  So I am asking anyone
> who is interested in helping me out with this to reply to this thread.

I might have time to give some help, and the subject does not seem too
frightening for someone not expert in Python internals (please correct
me if it is :-)), so don't hesitate to add me to your list.

Regards

Antoine.




From lists at cheimes.de  Thu Dec  6 23:26:42 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 06 Dec 2007 23:26:42 +0100
Subject: [Python-3000] Two problems in r30a2
Message-ID: <fj9sv2$34f$1@ger.gmane.org>

I found two problems with r30a2 on Windows:

1) The module doc server is crashing on Windows. I can't reproduce the
problem on Linux.

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

c:\Python30>python Tools\Scripts\pydocgui.pyw
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 1575)
Traceback (most recent call last):
  File "C:\Python30\lib\SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "C:\Python30\lib\SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "C:\Python30\lib\SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python30\lib\SocketServer.py", line 522, in __init__
    self.handle()
  File "c:\Python30\lib\BaseHTTPServer.py", line 330, in handle
    self.handle_one_request()
  File "c:\Python30\lib\BaseHTTPServer.py", line 324, in handle_one_request
    method()
  File "C:\Python30\lib\pydoc.py", line 1980, in do_GET
    contents = html.multicolumn(names, bltinlink)
  File "C:\Python30\lib\pydoc.py", line 471, in multicolumn
    rows = (len(list)+cols-1)//cols
TypeError: object of type 'itertools.ifilter' has no len()
----------------------------------------

2) The menus in IDLE are broken (Windows only).

Christian


From guido at python.org  Fri Dec  7 00:10:07 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 6 Dec 2007 15:10:07 -0800
Subject: [Python-3000] Two problems in r30a2
In-Reply-To: <fj9sv2$34f$1@ger.gmane.org>
References: <fj9sv2$34f$1@ger.gmane.org>
Message-ID: <ca471dc20712061510u53e4e0d9r69be3c075711510f@mail.gmail.com>

I'll add these to the online release notes; I prefer not to change the
tag just for that.

On Dec 6, 2007 2:26 PM, Christian Heimes <lists at cheimes.de> wrote:
> I found two problems with r30a2 on Windows:
>
> 1) The module doc server is crashing on Windows. I can't reproduce the
> problem on Linux.
>
> ----------------------------------------
>
> c:\Python30>python Tools\Scripts\pydocgui.pyw
> ----------------------------------------
> Exception happened during processing of request from ('127.0.0.1', 1575)
> Traceback (most recent call last):
>   File "C:\Python30\lib\SocketServer.py", line 222, in handle_request
>     self.process_request(request, client_address)
>   File "C:\Python30\lib\SocketServer.py", line 241, in process_request
>     self.finish_request(request, client_address)
>   File "C:\Python30\lib\SocketServer.py", line 254, in finish_request
>     self.RequestHandlerClass(request, client_address, self)
>   File "C:\Python30\lib\SocketServer.py", line 522, in __init__
>     self.handle()
>   File "c:\Python30\lib\BaseHTTPServer.py", line 330, in handle
>     self.handle_one_request()
>   File "c:\Python30\lib\BaseHTTPServer.py", line 324, in handle_one_request
>     method()
>   File "C:\Python30\lib\pydoc.py", line 1980, in do_GET
>     contents = html.multicolumn(names, bltinlink)
>   File "C:\Python30\lib\pydoc.py", line 471, in multicolumn
>     rows = (len(list)+cols-1)//cols
> TypeError: object of type 'itertools.ifilter' has no len()
> ----------------------------------------
>
> 2) The menus in IDLE are broken (Windows only).
>
> 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/guido%40python.org
>



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

From fdrake at acm.org  Fri Dec  7 05:52:16 2007
From: fdrake at acm.org (Fred Drake)
Date: Thu, 6 Dec 2007 23:52:16 -0500
Subject: [Python-3000] markupbase
Message-ID: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>

I'm at fault for this one.

This module was never intended to provide public API, so I'm +1 on  
changing the name to _markupbase, as suggested in PEP 3108:

   http://www.python.org/dev/peps/pep-3108/#no-public-documented-interface

Is there any reason not to change this name?  If not, I'll go ahead  
and do this in the next day or so (to give folks a chance to respond  
to this email).


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From brett at python.org  Fri Dec  7 07:54:35 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 6 Dec 2007 22:54:35 -0800
Subject: [Python-3000] markupbase
In-Reply-To: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>
References: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>
Message-ID: <bbaeab100712062254i3b9b1e98p4c59bf588d90c34b@mail.gmail.com>

On Dec 6, 2007 8:52 PM, Fred Drake <fdrake at acm.org> wrote:
> I'm at fault for this one.
>
> This module was never intended to provide public API, so I'm +1 on
> changing the name to _markupbase, as suggested in PEP 3108:
>
>    http://www.python.org/dev/peps/pep-3108/#no-public-documented-interface
>
> Is there any reason not to change this name?  If not, I'll go ahead
> and do this in the next day or so (to give folks a chance to respond
> to this email).

I say just go ahead and rename it.  Other modules are going to need to
be renamed as well so it isn't like this is going to be a special
case.

-Brett

From ncoghlan at gmail.com  Fri Dec  7 10:19:09 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 07 Dec 2007 19:19:09 +1000
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <20071206174533.9C8171E4005@bag.python.org>
References: <20071206174533.9C8171E4005@bag.python.org>
Message-ID: <4759100D.5030408@gmail.com>

guido.van.rossum wrote:
> Modified: python/branches/py3k/Lib/numbers.py
> ==============================================================================
> --- python/branches/py3k/Lib/numbers.py	(original)
> +++ python/branches/py3k/Lib/numbers.py	Thu Dec  6 18:45:33 2007
> @@ -43,6 +43,7 @@
>  
>  Inexact.register(complex)
>  Inexact.register(float)
> +# Inexact.register(decimal.Decimal)

With the new abstract base classes in Py3k, I can see it being 
worthwhile to have a standard mechanism to allow callbacks to be 
registered for execution when particular modules are first imported.

For example, to handle the commented out case above:

   @imp.imported('decimal')
   def register(decimal):
       Inexact.register(decimal.Decimal)


I think a PEP would be needed to decide whether to handle this in a 
fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy 
imports where the actual loading of the module code is deferred until 
the first access to an attribute of the module), or else to add a new 
mechanism directly to the interpreter code, where the registered 
callbacks would be called as soon as the specified module was loaded.

Does anyone else think this is an issue worth pursuing? We've already 
had a couple of instances come up in relation to the registration of 
array.array and decimal.Decimal with the appropriate abstract base 
classes. I expect there are other areas of the standard library (e.g. 
ctypes, mmap) where being able to register container types when the 
collections module is imported would be beneficial.

Cheers,
Nick.

[1] http://peak.telecommunity.com/DevCenter/Importing

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

From fdrake at acm.org  Fri Dec  7 12:19:06 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 7 Dec 2007 06:19:06 -0500
Subject: [Python-3000] markupbase
In-Reply-To: <bbaeab100712062254i3b9b1e98p4c59bf588d90c34b@mail.gmail.com>
References: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>
	<bbaeab100712062254i3b9b1e98p4c59bf588d90c34b@mail.gmail.com>
Message-ID: <93078C0B-D525-4068-A4A5-2799F38A1654@acm.org>

On Dec 7, 2007, at 1:54 AM, Brett Cannon wrote:
> I say just go ahead and rename it.  Other modules are going to need to
> be renamed as well so it isn't like this is going to be a special
> case.

And done.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From lists at cheimes.de  Fri Dec  7 12:33:10 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 07 Dec 2007 12:33:10 +0100
Subject: [Python-3000] markupbase
In-Reply-To: <93078C0B-D525-4068-A4A5-2799F38A1654@acm.org>
References: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>	<bbaeab100712062254i3b9b1e98p4c59bf588d90c34b@mail.gmail.com>
	<93078C0B-D525-4068-A4A5-2799F38A1654@acm.org>
Message-ID: <47592F76.8020809@cheimes.de>

Fred Drake wrote:
> And done.

Is the py3k branch open for development again?

Christian

From lists at cheimes.de  Fri Dec  7 12:33:50 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 07 Dec 2007 12:33:50 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <4759100D.5030408@gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com>
Message-ID: <47592F9E.7090107@cheimes.de>

Nick Coghlan wrote:
> For example, to handle the commented out case above:
> 
>    @imp.imported('decimal')
>    def register(decimal):
>        Inexact.register(decimal.Decimal)

I like the syntax assuming that imp.imported(name) expects a method that
accepts the module object as argument.

> I think a PEP would be needed to decide whether to handle this in a 
> fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy 
> imports where the actual loading of the module code is deferred until 
> the first access to an attribute of the module), or else to add a new 
> mechanism directly to the interpreter code, where the registered 
> callbacks would be called as soon as the specified module was loaded.

I find a new mechanism easier to implement. Lazy or deferred imports
require frame hacks and you know how Guido thinks about sys._getframe(). :)

An implementation based on your suggestion is simple. Add a registry to
imp which is a simple dict that maps dotted module names to a list of
callables. Upon import the IMP module calls the callables after the
module is inserted into sys.modules. That's it. :]

Zope's deferredimport [1] package has a nice idea. It supports
deprecation warnings when a deprecated attribute is accessed the first time.

>>> import somemodule

No warning is raised

>>> somemodule.deprecated_feature

DeprecationWarning ...

The package makes use of stack inspection and a proxy package.

> Does anyone else think this is an issue worth pursuing? 

Yes, count me in. I like to help with the PEP and implementation. :)

Christian

[1] http://svn.zope.org/zope.deferredimport/trunk/src/zope/deferredimport/

From fdrake at acm.org  Fri Dec  7 15:10:36 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 7 Dec 2007 09:10:36 -0500
Subject: [Python-3000] markupbase
In-Reply-To: <47592F76.8020809@cheimes.de>
References: <10A5C947-2372-4B51-872D-B195EA952104@acm.org>	<bbaeab100712062254i3b9b1e98p4c59bf588d90c34b@mail.gmail.com>
	<93078C0B-D525-4068-A4A5-2799F38A1654@acm.org>
	<47592F76.8020809@cheimes.de>
Message-ID: <3604D4D6-9E76-4BA5-9DE0-A8FB19F97374@acm.org>

On Dec 7, 2007, at 6:33 AM, Christian Heimes wrote:
> Is the py3k branch open for development again?


Oops, good question.  Wish I'd wondered about that.

/me feels out of sync with the Python development cycle...


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From fdrake at acm.org  Fri Dec  7 15:20:10 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 7 Dec 2007 09:20:10 -0500
Subject: [Python-3000] PEP 3108 - recommendations for PyPI transition
In-Reply-To: <18263.64282.69977.190401@montanaro.dyndns.org>
References: <18263.64282.69977.190401@montanaro.dyndns.org>
Message-ID: <EF272E6E-CD93-48F2-817C-7E7631B42C3E@acm.org>

On Dec 6, 2007, at 8:37 AM, skip at pobox.com wrote:
> Should the PEP acknowledge this route to module sainthood for certain
> modules?


I think this is out of scope for the PEP.  It's fine if the PEP points  
to new distributions for the modules as they become available.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From pje at telecommunity.com  Fri Dec  7 15:35:17 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 07 Dec 2007 09:35:17 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module  import
In-Reply-To: <47592F9E.7090107@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
Message-ID: <20071207143515.69EDC3A40AF@sparrow.telecommunity.com>

At 12:33 PM 12/7/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > For example, to handle the commented out case above:
> >
> >    @imp.imported('decimal')
> >    def register(decimal):
> >        Inexact.register(decimal.Decimal)
>
>I like the syntax assuming that imp.imported(name) expects a method that
>accepts the module object as argument.

I prefer something like 'when_imported' or 'upon_import' or something 
else that more specifically refers to the idea that this is 
registering a handler to be called.  imported() by itself sounds like 
a query as to whether the module is currently imported.


> > I think a PEP would be needed to decide whether to handle this in a
> > fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy
> > imports where the actual loading of the module code is deferred until
> > the first access to an attribute of the module), or else to add a new
> > mechanism directly to the interpreter code, where the registered
> > callbacks would be called as soon as the specified module was loaded.
>
>I find a new mechanism easier to implement. Lazy or deferred imports
>require frame hacks

No, they don't.  See:

http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup

The mechanism I used is to create a subclass of ModuleType and put it 
in sys.modules as a placeholder for the "real" module.  When the 
module is touched, I effectively change the type back to a regular 
module, and call reload() to actually import the module.

Of course, since Python 2.3 (this code was originally written for 
2.2), you can't change a subclass of ModuleType back to ModuleType 
itself, so I actually change the custom subclass on the fly.  This is 
easy enough to do in Python, but I'd hate to do it in C.

If I were doing it in C, I'd just add a laziness flag and callback 
list to the base ModuleType.  The tp_getattro could then check the 
laziness flag and do the rest.



> > Does anyone else think this is an issue worth pursuing?

A qualified yes: the Importing package took a long time to get 
correct under all the crazy little twists and turns of importing, 
including correctly handling things like the link between packages 
and their child packages/modules, the import order of same, race 
conditions, import locks, clearing out callbacks, etc.  I'm somewhat 
hesitant as to whether a from-scratch reimplementation is wise.

I'm also concerned about interoperability.  If you add the equivalent 
of Importing's whenImported, but not lazyModule, then I'll still need 
Importing itself -- and the builtin implementation of whenImported 
might conflict with lazyModule.  In particular, the builtin 
when_imported might confuse a lazyModule with something that's 
already imported, and fire off callbacks when it shouldn't.

So, I vote for making module laziness part of the implementation, if 
there is one.

There also should be APIs provided by imp to inspect (or change) the 
laziness of a module without causing it to become un-lazy.  This is 
needed so that other ModuleType subclasses can play too.  For 
example, some tools use ModuleType subclasses to implement 
attribute-level laziness instead of whole-module laziness.

There may be other interop issues with libraries that use ModuleType 
subclasses or do lazy import, deprecation, and similar module content 
manipulation, so a publicized PEP would be a good idea to get their 
developers' input.


From ndbecker2 at gmail.com  Fri Dec  7 16:37:58 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 07 Dec 2007 10:37:58 -0500
Subject: [Python-3000] Combined configparse + optparse (interest?)
Message-ID: <fjbpcm$c7r$1@ger.gmane.org>

Right now we have 2 rather different stdlib modules for parsing options from
ini-style files and from command line.  I believe it would be desirable to
have one module that can handle both.  Is there interest in pursuing this
idea?


From eric+python-dev at trueblade.com  Fri Dec  7 16:46:46 2007
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 07 Dec 2007 10:46:46 -0500
Subject: [Python-3000] Combined configparse + optparse (interest?)
In-Reply-To: <fjbpcm$c7r$1@ger.gmane.org>
References: <fjbpcm$c7r$1@ger.gmane.org>
Message-ID: <47596AE6.8050102@trueblade.com>

Neal Becker wrote:
> Right now we have 2 rather different stdlib modules for parsing options from
> ini-style files and from command line.  I believe it would be desirable to
> have one module that can handle both.  Is there interest in pursuing this
> idea?

I'd be interested.  I think rolling in the functionality of argparse to 
handle non-option arguments would also be good: 
http://argparse.python-hosting.com/

From fdrake at acm.org  Fri Dec  7 16:54:32 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 7 Dec 2007 10:54:32 -0500
Subject: [Python-3000] Combined configparse + optparse (interest?)
In-Reply-To: <fjbpcm$c7r$1@ger.gmane.org>
References: <fjbpcm$c7r$1@ger.gmane.org>
Message-ID: <4598AC72-F42D-4C12-97FC-8D8E6B06F07C@acm.org>

On Dec 7, 2007, at 10:37 AM, Neal Becker wrote:
> Right now we have 2 rather different stdlib modules for parsing  
> options from
> ini-style files and from command line.  I believe it would be  
> desirable to
> have one module that can handle both.  Is there interest in pursuing  
> this
> idea?


Definitely!  I'm interested, and suspect others at ZC would appreciate  
such a module as well.

Of course, we'd be most interested if it worked with Python 2.4  
forward.  ;-)  I'm certainly willing to help out.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From guido at python.org  Fri Dec  7 19:03:31 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 7 Dec 2007 10:03:31 -0800
Subject: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
In-Reply-To: <ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
References: <ca471dc20712051746gc8666eft1ecba706ab400465@mail.gmail.com>
	<ca471dc20712052043o2eaf29b8m40a58e49345ddce1@mail.gmail.com>
Message-ID: <ca471dc20712071003g1c26ebb1vb938c7e4e372be0e@mail.gmail.com>

As people have been disregarding the freeze anyway, I declare the py3k
branch back open. I tagged it with r30a2 yesterday morning and that's
the version that I'll be releasing shortly (waiting for Crys & me to
sort out some things around the Windows MSI installer).

--Guido

On Dec 5, 2007 8:43 PM, Guido van Rossum <guido at python.org> wrote:
> I've built and tested the latest py3k from scratch on Ubuntu, Fedora
> 7, OSX 10.4 and OSX 10.5, and found no issues.
>
> So the code freeze is a fact. Don't check anything into the py3k
> branch unless I tell you to. Please file high-priority bugs and assign
> them to me if you think you've found a showstopper.
>
> The buildbot is green for Solaris also, so I think we're in good
> shape. I don't see any green buildbots for Windows though, but Windows
> is always a flakey situation; Christian, what's your assessment?
>
> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!) and test_urllib2_localnet (3 per run). Anyone interested in
> researching these feel free to do so; just upload a patch and file a
> bug if you've squashed the leaks (or some).
>
> We're on for a 3.0a2 release Friday!
>
> --Guido
>
>
> On Dec 5, 2007 5:46 PM, Guido van Rossum <guido at python.org> wrote:
> > I'm planning to freeze the py3k branch in 2-3 hours, some time
> > after/around 8pm PST (midnight UTC).
> >
> > If someone wants to do another svnmerge from the trunk please do it
> > before then -- though we're nearly current so I don't mind not having
> > the last few changes merged into this release (it's only Raymond's
> > refactoring of __length_hint__ implementations).
> >
> > If there's anything you think really should be in this release, please
> > speak up ASAP. Filing a high priority bug and assigning it to me would
> > be a great way to get my attention.
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



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

From lists at cheimes.de  Fri Dec  7 19:43:13 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 07 Dec 2007 19:43:13 +0100
Subject: [Python-3000] Python 3.0a2 is out
Message-ID: <47599441.5000804@cheimes.de>

A new alpha of Python 3000 was released a few minutes ago!

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

Have fun and don't forget to report bugs at http://bugs.python.org/

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/python-3000/attachments/20071207/cb62754f/attachment.pgp 

From greg at krypto.org  Fri Dec  7 20:06:59 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 7 Dec 2007 11:06:59 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
Message-ID: <52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>

On 12/3/07, Guido van Rossum <guido at python.org> wrote:
>
> On Dec 2, 2007 12:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > It's only used for sys.maxint. Do we still need sys.maxint and
> > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > > better names.
> >
> > I think they should go entirely. They don't give any interesting
> > information about the Python implementation.
>
> Actually it's still somewhat interesting to be able to tell whether a
> particular Python build uses 64-bit pointer or 32-bit pointers. (I
> realize sys.maxint doesn't quite tell us this, but on Linux at least
> it does.) I also suspecet that sys.maxint is used frequently for "some
> large integer" used as an approximation of infinity in some context.


It is, but it doesn't appear to common:

 http://www.google.com/codesearch?q=+sys.maxint

Only turns up ~10 unique non-Python-itself projects using within the first 5
pages of results.  Much of the time it is used as a large number.  Anyone
porting that code forward to 2.6 or later can fix that.

Please don't encourage its misuse for determining if the host has 32 or
64bit longs or pointers.  It does not do that.  Use platform.architecture()
for the long size and look at the length of a hex pointer in the repr of a
class for C pointer size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071207/40b7d714/attachment.htm 

From guido at python.org  Fri Dec  7 20:16:09 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 7 Dec 2007 11:16:09 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
Message-ID: <ca471dc20712071116r16dfdbf8s3e2d57d56ecac494@mail.gmail.com>

On Dec 7, 2007 11:06 AM, Gregory P. Smith <greg at krypto.org> wrote:
> On 12/3/07, Guido van Rossum <guido at python.org> wrote:
> > On Dec 2, 2007 12:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > > It's only used for sys.maxint. Do we still need sys.maxint and
> > > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > > > better names.
> > >
> > > I think they should go entirely. They don't give any interesting
> > > information about the Python implementation.
> >
> > Actually it's still somewhat interesting to be able to tell whether a
> > particular Python build uses 64-bit pointer or 32-bit pointers. (I
> > realize sys.maxint doesn't quite tell us this, but on Linux at least
> > it does.) I also suspecet that sys.maxint is used frequently for "some
> > large integer" used as an approximation of infinity in some context.
>
> It is, but it doesn't appear to common:
>
>  http://www.google.com/codesearch?q=+sys.maxint
>
> Only turns up ~10 unique non-Python-itself projects using within the first 5
> pages of results.  Much of the time it is used as a large number.  Anyone
> porting that code forward to 2.6 or later can fix that.
>
> Please don't encourage its misuse for determining if the host has 32 or
> 64bit longs or pointers.  It does not do that.  Use platform.architecture()
> for the long size and look at the length of a hex pointer in the repr of a
> class for C pointer size.

sys.maxsize should be backported to 2.6.

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

From lists at cheimes.de  Fri Dec  7 20:23:33 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 07 Dec 2007 20:23:33 +0100
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <ca471dc20712071116r16dfdbf8s3e2d57d56ecac494@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de>
	<47531BF4.9090907@v.loewis.de>	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>	<52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
	<ca471dc20712071116r16dfdbf8s3e2d57d56ecac494@mail.gmail.com>
Message-ID: <47599DB5.8060604@cheimes.de>

Guido van Rossum wrote:
> sys.maxsize should be backported to 2.6.

It's on my todo list. But at first I'm going to celebrate Python 3.0a2
with a beer and meet some friends.

Christian



From guido at python.org  Fri Dec  7 20:24:38 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 7 Dec 2007 11:24:38 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <47599DB5.8060604@cheimes.de>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
	<ca471dc20712071116r16dfdbf8s3e2d57d56ecac494@mail.gmail.com>
	<47599DB5.8060604@cheimes.de>
Message-ID: <ca471dc20712071124y7d27a2dakfb96f1a32130bab6@mail.gmail.com>

On Dec 7, 2007 11:23 AM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > sys.maxsize should be backported to 2.6.
>
> It's on my todo list. But at first I'm going to celebrate Python 3.0a2
> with a beer and meet some friends.

Enjoy! Me, I'm going on a conference bike with the xkcd author. ;-)

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

From ntoronto at cs.byu.edu  Fri Dec  7 20:14:32 2007
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Fri, 07 Dec 2007 12:14:32 -0700
Subject: [Python-3000] Armin's attribute lookup caching for 3.0
Message-ID: <47599B98.7090008@cs.byu.edu>

I couldn't help myself. Such a beautiful thing had to be spread, and it 
was *easy* to put it in 3.0 because types are simpler. A patch is here:

     http://bugs.python.org/issue1568

If users are going to be encouraged to subclass from the ABC hierarchy 
for new container and numeric types, they'll likely want something like 
this. Both pybench and pystones are faster (pystones because its classes 
are now instances of type), and those exercise attribute lookups on 
classes with MROs no larger than 2. The pybench scores are good in 
general (with all lookups very good), except SpecialClassAttribute, 
which spends half its time doing class attribute assignments. Another 
surprise is TryRaiseExcept - why should that be faster?

I found updating caches from setattr to be faster than invalidating 
entries. (It could easily go back to invalidating all entries for a type 
if that's preferred.) Adding extra TPFLAGS was unnecessary. It still 
assumes attribute names are interned (it doesn't have to but it's a 
little faster this way), but AFAIK this could only affect computed names.

Neil


From pje at telecommunity.com  Fri Dec  7 21:14:25 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 07 Dec 2007 15:14:25 -0500
Subject: [Python-3000] Armin's attribute lookup caching for 3.0
In-Reply-To: <47599B98.7090008@cs.byu.edu>
References: <47599B98.7090008@cs.byu.edu>
Message-ID: <20071207201421.E45813A405E@sparrow.telecommunity.com>

At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote:
>I couldn't help myself. Such a beautiful thing had to be spread, and it
>was *easy* to put it in 3.0 because types are simpler. A patch is here:
>
>      http://bugs.python.org/issue1568
>
>If users are going to be encouraged to subclass from the ABC hierarchy
>for new container and numeric types, they'll likely want something like
>this. Both pybench and pystones are faster (pystones because its classes
>are now instances of type), and those exercise attribute lookups on
>classes with MROs no larger than 2. The pybench scores are good in
>general (with all lookups very good), except SpecialClassAttribute,
>which spends half its time doing class attribute assignments. Another
>surprise is TryRaiseExcept - why should that be faster?
>
>I found updating caches from setattr to be faster than invalidating
>entries.

Really?  Even on the SpecialClassAttribute test?  I'd have assumed 
that Armin's invalidation flag mechanism would make repeated sets 
faster.  Of course, in cases where you read the attribute every time 
it's set, your approach might come out ahead somewhat.  Armin's 
approach has to walk the entire subclass tree to mark the versions 
invalid, whereas yours can skip shadowed attributes.

I suspect that in real programs, though, it's rare to be setting 
attributes on a base class that are shadowed by subclass 
attributes.  Most likely, you'll either be changing something that's 
global and inherited everywhere, or something that's on a leaf class 
to begin with.  Your approach should definitely be a win on the 
*read* side of things, though, since it doesn't have to check version 
validity during lookup.

That having been said, the idea that the statement 'SomeBaseClass.foo 
= 23' is actually going to walk through cache entries and invoke a 
callback for *every* subclass of SomeBaseClass in the program makes 
me a tiny bit nervous.

On the other hand, I suppose it's also a good argument for not using 
class attributes when you really want a global.  :)


From ntoronto at cs.byu.edu  Fri Dec  7 22:48:19 2007
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Fri, 07 Dec 2007 14:48:19 -0700
Subject: [Python-3000] Armin's attribute lookup caching for 3.0
In-Reply-To: <20071207201421.E45813A405E@sparrow.telecommunity.com>
References: <47599B98.7090008@cs.byu.edu>
	<20071207201421.E45813A405E@sparrow.telecommunity.com>
Message-ID: <4759BFA3.4060707@cs.byu.edu>

Phillip J. Eby wrote:
> At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote:
>> I found updating caches from setattr to be faster than invalidating
>> entries.
> 
> Really?  Even on the SpecialClassAttribute test?  I'd have assumed that 
> Armin's invalidation flag mechanism would make repeated sets faster.  Of 
> course, in cases where you read the attribute every time it's set, your 
> approach might come out ahead somewhat.  Armin's approach has to walk 
> the entire subclass tree to mark the versions invalid, whereas yours can 
> skip shadowed attributes.

In Python 3.0, since everything is so much more unified, Armin's 
invalidate everything approach can skip shadowed attributes as well. If 
a subclass shadows an attribute, its cache entry either 1) doesn't 
exist, or 2) caches the shadowing value.

The invalidating callback looks like:

     1. Set type's cache ID to current, increment current

The updating callback looks like:

     1. Get Unicode hash (almost always pointer dereference)
     2. Calculate cache index
     3. If entry cache ID and name match, assign new value

It's not a whole lot more, especially compared to the update_subclasses 
machinery. Where I think the updating approach wins is when only one 
attribute is set at a time, rather than a lot of them in a row, which I 
believe is more likely.

> I suspect that in real programs, though, it's rare to be setting 
> attributes on a base class that are shadowed by subclass attributes.  
> Most likely, you'll either be changing something that's global and 
> inherited everywhere, or something that's on a leaf class to begin 
> with.  Your approach should definitely be a win on the *read* side of 
> things, though, since it doesn't have to check version validity during 
> lookup.
> 
> That having been said, the idea that the statement 'SomeBaseClass.foo = 
> 23' is actually going to walk through cache entries and invoke a 
> callback for *every* subclass of SomeBaseClass in the program makes me a 
> tiny bit nervous.
> 
> On the other hand, I suppose it's also a good argument for not using 
> class attributes when you really want a global.  :)

Heh. You never know what those crazy users will need to do. You of all 
people should know that. :p

If it's too slow, an obvious way to speed it up is to not use 
update_subclasses and avoid the overhead. Besides avoiding calling a 
function by pointer, not doing the shadowing check may also be faster 
generally, since, as you say, assigned attributes are most likely 1) not 
shadowed (they'll almost never be methods), or 2) in a leaf class. It 
may be that Armin's invalidate everything approach would be generally 
faster that way because it *can* skip shadowed attributes. To update you 
have to check for shadowing.

I may try it. I couldn't say whether it's worth duplicating the code.

FWIW and slightly topic-veering, this patch keeps hit/miss counts if you 
want it to. Pybench has a hit rate of 81%. It's hard to say whether a 
benchmark gives a good measure of hit rate, though, since most code 
doesn't repeat the same operations to quite the extent that a benchmark 
does. OTOH, build and build_ext get 99%, so it may be a bad measure in 
the other direction.

Neil


From ntoronto at cs.byu.edu  Fri Dec  7 23:17:36 2007
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Fri, 07 Dec 2007 15:17:36 -0700
Subject: [Python-3000] Armin's attribute lookup caching for 3.0
In-Reply-To: <4759BFA3.4060707@cs.byu.edu>
References: <47599B98.7090008@cs.byu.edu>	<20071207201421.E45813A405E@sparrow.telecommunity.com>
	<4759BFA3.4060707@cs.byu.edu>
Message-ID: <4759C680.8070905@cs.byu.edu>

Neil Toronto wrote:
> Phillip J. Eby wrote:
>> That having been said, the idea that the statement 'SomeBaseClass.foo = 
>> 23' is actually going to walk through cache entries and invoke a 
>> callback for *every* subclass of SomeBaseClass in the program makes me a 
>> tiny bit nervous.
>>
>> On the other hand, I suppose it's also a good argument for not using 
>> class attributes when you really want a global.  :)
> 
> Heh. You never know what those crazy users will need to do. You of all 
> people should know that. :p
> 
> If it's too slow, an obvious way to speed it up is to not use 
> update_subclasses and avoid the overhead. Besides avoiding calling a 
> function by pointer, not doing the shadowing check may also be faster 
> generally, since, as you say, assigned attributes are most likely 1) not 
> shadowed (they'll almost never be methods), or 2) in a leaf class. It 
> may be that Armin's invalidate everything approach would be generally 
> faster that way because it *can* skip shadowed attributes. To update you 
> have to check for shadowing.
> 
> I may try it. I couldn't say whether it's worth duplicating the code.

Okay, I tried it. SpecialClassAttribute sees a 3% speedup but 
NormalClassAttribute sees a 9% slowdown. I haven't got a clue what that 
asymmetry is all about.

At any rate, I'll #ifdef it and post a new patch. It's yet another thing 
to play with.

Neil

From greg.ewing at canterbury.ac.nz  Sat Dec  8 01:14:59 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 08 Dec 2007 13:14:59 +1300
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
Message-ID: <4759E203.9040703@canterbury.ac.nz>

Gregory P. Smith wrote:
> look at the length of a 
> hex pointer in the repr of a class for C pointer size.

I don't think that will work, because the repr only uses
as many hex digits as it needs to represent the value:

 >>> o = object()
 >>> o
<object object at 0x533b8>

I'm pretty sure my G4 PPC is using pointers longer than
20 bits. :-)

--
Greg

From ncoghlan at gmail.com  Sat Dec  8 06:56:19 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 08 Dec 2007 15:56:19 +1000
Subject: [Python-3000] Interest in PEP for callbacks on module  import
In-Reply-To: <20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
Message-ID: <475A3203.6060405@gmail.com>

Phillip J. Eby wrote:
>> > Does anyone else think this is an issue worth pursuing?
> 
> A qualified yes: the Importing package took a long time to get correct 
> under all the crazy little twists and turns of importing, including 
> correctly handling things like the link between packages and their child 
> packages/modules, the import order of same, race conditions, import 
> locks, clearing out callbacks, etc.  I'm somewhat hesitant as to whether 
> a from-scratch reimplementation is wise.

I'm far from convinced that a from-scratch rewrite (particularly in C) 
is a great idea myself - that's why I suggested a PEP to look at some of 
the issues.

Some curly questions I thought of myself:

- What do we do if something is inserted in sys.modules directly, and 
then imported later? Do registered callbacks for that module trigger at 
all? If so, when?

- Does the lazy importing code need to reacquire the import lock before 
loading the module on attribute access?

> There may be other interop issues with libraries that use ModuleType 
> subclasses or do lazy import, deprecation, and similar module content 
> manipulation, so a publicized PEP would be a good idea to get their 
> developers' input.

Yeah, the more I think about it, the more I think a new PEP for lazy and 
weak importing is the right way to go (although it would be nice if 
using the latter didn't automatically cause the former). I'll put an 
initial draft together (unless someone else beats me to it - I almost 
certainly won't find time to do it until after Christmas)

Cheers,
Nick.

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

From pje at telecommunity.com  Sat Dec  8 16:25:36 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 08 Dec 2007 10:25:36 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <475A3203.6060405@gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com>
Message-ID: <20071208152532.7321B3A4068@sparrow.telecommunity.com>

At 03:56 PM 12/8/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> >> > Does anyone else think this is an issue worth pursuing?
> >
> > A qualified yes: the Importing package took a long time to get correct
> > under all the crazy little twists and turns of importing, including
> > correctly handling things like the link between packages and their child
> > packages/modules, the import order of same, race conditions, import
> > locks, clearing out callbacks, etc.  I'm somewhat hesitant as to whether
> > a from-scratch reimplementation is wise.
>
>I'm far from convinced that a from-scratch rewrite (particularly in C)
>is a great idea myself - that's why I suggested a PEP to look at some of
>the issues.
>
>Some curly questions I thought of myself:
>
>- What do we do if something is inserted in sys.modules directly, and
>then imported later? Do registered callbacks for that module trigger at
>all? If so, when?

The Importing package doesn't have this problem, because it inserts 
the module itself the first time you call whenImported for that 
module.  In other words, any time you call whenImported, either the 
module is not there (in which case it's added, and the callback 
registered), or it is (in which case the callback is invoked immediately).

Of course, if somebody *replaces* the lazy module, all bets are off, 
but that seems like a consenting adults thing to me.


>- Does the lazy importing code need to reacquire the import lock before
>loading the module on attribute access?

If it's written in Python, yes, in order to avoid race conditions 
around the manipulation of the custom type.  In C, however, you 
wouldn't need to because the GIL can prevent that portion of the race 
condition, and then the reload() operation will hold the import lock 
around the Python code execution.

The callbacks should probably be invoked under import lock protection, though.


> > There may be other interop issues with libraries that use ModuleType
> > subclasses or do lazy import, deprecation, and similar module content
> > manipulation, so a publicized PEP would be a good idea to get their
> > developers' input.
>
>Yeah, the more I think about it, the more I think a new PEP for lazy and
>weak importing is the right way to go (although it would be nice if
>using the latter didn't automatically cause the former).

If it doesn't, then you'll need more complex mechanisms to support 
both.  If you want a C implementation, the simplest way I can think 
of to make it work is to give module objects a lazy flag and a 
callback list.  If you don't, then you have to deal with more corner 
cases and interop trickiness.

Misc. notes for the PEP: there should be a way to determine the 
laziness of a module object without causing it to load.  I also think 
you should be able to set a module's __loader__, __path__, and 
__file__, without causing it to load.  That way, you can create a 
lazy module that is loaded by a custom loader.  (Does reload() honor 
__loader__, or does it start the import process over?)


From lists at cheimes.de  Sat Dec  8 16:32:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 08 Dec 2007 16:32:06 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <20071208152532.7321B3A4068@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com>
	<20071208152532.7321B3A4068@sparrow.telecommunity.com>
Message-ID: <475AB8F6.9020101@cheimes.de>

Phillip J. Eby wrote:
> Misc. notes for the PEP: there should be a way to determine the laziness
> of a module object without causing it to load.  I also think you should
> be able to set a module's __loader__, __path__, and __file__, without
> causing it to load.  That way, you can create a lazy module that is
> loaded by a custom loader.  (Does reload() honor __loader__, or does it
> start the import process over?)

reload() is gone. Python 3.0 doesn't have a reload() function anymore.

I don't know if Guido is planing to replace it with xreload().

Christian

From qrczak at knm.org.pl  Sat Dec  8 18:45:30 2007
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Sat, 08 Dec 2007 18:45:30 +0100
Subject: [Python-3000] Method descriptors
Message-ID: <1197135930.24311.26.camel@qrnik>

I'm confused about storing methods in class dictionaries from the point
of view of the C API.

1. Let's say that I have a callable PyObject called f, of my type
   defined in C. I want to store something derived from f as A.m
   for some class A, such that for an object a of class A, calling
   a.m(*args) ends up calling f(a, *args).

   In Python2 PyMethod_New(f, NULL, a) seems to be the right to store
   in the class. How to do the equivalent thing in Python3?

   BTW, applying PyMethod_Type to 3 arguments crashes Python3. I think
   this line is the culprit (classobject.c):

        if (!PyArg_UnpackTuple(args, "method", 2, 3,
                              &func, &self))

   Should be 2 instead of 3. There used to be an extra parameter.

2. As above, but f is to be implemented as a C function. I found the
   following working for a new-style class:

   - make PyMethodDef struct for the method
   - use PyDescr_NewMethod
   - store the resulting object in the class

   but it does not work for a classic class (such that an exception
   class in Python 2.4 and below) to which I want to add a method.
   Here it seems to be doable differently:

   - make PyMethodDef struct for the method, but with an unused first
     parameter
   - use PyCFunction_New, with NULL as 'self'
   - use PyMethod_New on the resulting function, NULL, and the class
   - store the resulting object in the class

   Can this be done simpler? Having separate variants for different
   Python versions is OK.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From lists at cheimes.de  Sat Dec  8 19:28:10 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 08 Dec 2007 19:28:10 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <1197135930.24311.26.camel@qrnik>
References: <1197135930.24311.26.camel@qrnik>
Message-ID: <475AE23A.7040404@cheimes.de>

Marcin ?Qrczak? Kowalczyk wrote:
>    BTW, applying PyMethod_Type to 3 arguments crashes Python3. I think
>    this line is the culprit (classobject.c):
> 
>         if (!PyArg_UnpackTuple(args, "method", 2, 3,
>                               &func, &self))
> 
>    Should be 2 instead of 3. There used to be an extra parameter.

Thanks for the hint. I've fixed the bug in r59428.

Christian

From greg at krypto.org  Sat Dec  8 20:03:54 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 8 Dec 2007 11:03:54 -0800
Subject: [Python-3000] PyInt_ to PyLong_ rename
In-Reply-To: <4759E203.9040703@canterbury.ac.nz>
References: <4752F8DC.6040103@cheimes.de> <47531BF4.9090907@v.loewis.de>
	<ca471dc20712031057q427d3cb9x18b5b84b990bb02e@mail.gmail.com>
	<52dc1c820712071106p5ded927cy66a9df804ebc53c2@mail.gmail.com>
	<4759E203.9040703@canterbury.ac.nz>
Message-ID: <52dc1c820712081103y60832a0atdcffe1a889f1cec3@mail.gmail.com>

heh ag

On 12/7/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> Gregory P. Smith wrote:
> > look at the length of a
> > hex pointer in the repr of a class for C pointer size.
>
> I don't think that will work, because the repr only uses
> as many hex digits as it needs to represent the value:
>
> >>> o = object()
> >>> o
> <object object at 0x533b8>
>
> I'm pretty sure my G4 PPC is using pointers longer than
> 20 bits. :-)


heh agreed, it clearly doesn't work everywhere.  I was hoping that all oses
had a high bit set in the virtual addresses they typically use for
processes.  I guess not. ;)

Anyways the struct module is the right answer as Thomas Heller already
pointed out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071208/69024315/attachment.htm 

From brett at python.org  Sat Dec  8 20:32:22 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 8 Dec 2007 11:32:22 -0800
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475AB8F6.9020101@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com>
	<20071208152532.7321B3A4068@sparrow.telecommunity.com>
	<475AB8F6.9020101@cheimes.de>
Message-ID: <bbaeab100712081132s553ea73bk72de266eb3fc8505@mail.gmail.com>

On Dec 8, 2007 7:32 AM, Christian Heimes <lists at cheimes.de> wrote:
> Phillip J. Eby wrote:
> > Misc. notes for the PEP: there should be a way to determine the laziness
> > of a module object without causing it to load.  I also think you should
> > be able to set a module's __loader__, __path__, and __file__, without
> > causing it to load.  That way, you can create a lazy module that is
> > loaded by a custom loader.  (Does reload() honor __loader__, or does it
> > start the import process over?)
>
> reload() is gone. Python 3.0 doesn't have a reload() function anymore.
>
> I don't know if Guido is planing to replace it with xreload().

There have been discussions of putting some form of reload function
into the imp module.

-Brett

From lists at cheimes.de  Sat Dec  8 21:55:54 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 08 Dec 2007 21:55:54 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module  import
In-Reply-To: <475A3203.6060405@gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>	<4759100D.5030408@gmail.com>
	<47592F9E.7090107@cheimes.de>	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com>
Message-ID: <475B04DA.7050201@cheimes.de>

Nick Coghlan wrote:
> I'm far from convinced that a from-scratch rewrite (particularly in C) 
> is a great idea myself - that's why I suggested a PEP to look at some of 
> the issues.

Yesterday I wrote down a quick survey of codes with some use cases. Then
I compared my ideas with PJE's import tool. His working implementation
is almost identical to my idea. In my opinion we can copy his import
callback API and re-implement it in C.

> Some curly questions I thought of myself:
> 
> - What do we do if something is inserted in sys.modules directly, and 
> then imported later? Do registered callbacks for that module trigger at 
> all? If so, when?

I'll answer the question with a list of use cases

* a new callback is registered and module is not loaded
  o callback is added to a registry: module name -> list of callbacks

* module is inserted into sys.modules[] manually
  o nothing happens

* module is loaded with __import__() but callbacks weren't fired yet
  o the existing import mechanism is called
  o after the module is loaded and inserted into sys.modules
    the callbacks are fired in reverse order (FILO). The
    callbacks are also called when the module is already in
    sys.modules but the value of the registry isn't None.
  o registry[module name] value is set to None

* module is loaded and registry.get(modulename) returns None
  o nothing happens. Either the callbacks are already fired or
    no callback was registered.

* new callback is registered, module is already loaded
(registry.get(modulename) is None)
  o callback is fired immediately with sys.modules[modulename] as argument

> - Does the lazy importing code need to reacquire the import lock before 
> loading the module on attribute access?

I'm not sure but I'd guess that the lock should be acquired before the
real module is loaded. Does the code need to acquire the lock before the
facade module for lazy importing is created and added to sys.modules?

> Yeah, the more I think about it, the more I think a new PEP for lazy and 
> weak importing is the right way to go (although it would be nice if 
> using the latter didn't automatically cause the former). I'll put an 
> initial draft together (unless someone else beats me to it - I almost 
> certainly won't find time to do it until after Christmas)

What's the difference between lazy and weak importing?

Christian

From pje at telecommunity.com  Sat Dec  8 22:04:55 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 08 Dec 2007 16:04:55 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <475B04DA.7050201@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
Message-ID: <20071208210451.470963A405E@sparrow.telecommunity.com>

At 09:55 PM 12/8/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > I'm far from convinced that a from-scratch rewrite (particularly in C)
> > is a great idea myself - that's why I suggested a PEP to look at some of
> > the issues.
>
>Yesterday I wrote down a quick survey of codes with some use cases. Then
>I compared my ideas with PJE's import tool. His working implementation
>is almost identical to my idea. In my opinion we can copy his import
>callback API and re-implement it in C.
>
> > Some curly questions I thought of myself:
> >
> > - What do we do if something is inserted in sys.modules directly, and
> > then imported later? Do registered callbacks for that module trigger at
> > all? If so, when?
>
>I'll answer the question with a list of use cases
>
>* a new callback is registered and module is not loaded
>   o callback is added to a registry: module name -> list of callbacks
>
>* module is inserted into sys.modules[] manually
>   o nothing happens

Note that in my implementation, an entry is added to sys.modules 
immediately, so this scenario can't happen without *replacing* the 
sys.modules entry.


>* module is loaded with __import__() but callbacks weren't fired yet
>   o the existing import mechanism is called
>   o after the module is loaded and inserted into sys.modules
>     the callbacks are fired in reverse order (FILO).

Why not FIFO?


>What's the difference between lazy and weak importing?

"Weak importing" is my name for having a run-this-on-import callback, 
implemented in terms of lazy importing.

Lazy importing is putting a module object into sys.modules, but not 
loading its contents until you attempt to get or set a module attribute.


From lists at cheimes.de  Sat Dec  8 22:32:32 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 08 Dec 2007 22:32:32 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <4759100D.5030408@gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com>
Message-ID: <475B0D70.4090602@cheimes.de>

Nick Coghlan wrote:
> With the new abstract base classes in Py3k, I can see it being 
> worthwhile to have a standard mechanism to allow callbacks to be 
> registered for execution when particular modules are first imported.
> 
> For example, to handle the commented out case above:
> 
>    @imp.imported('decimal')
>    def register(decimal):
>        Inexact.register(decimal.Decimal)

Your proposed hook is a post import hook. Could we use a pre import hook
that is called before the module is loaded? I can think of several use
cases:

* modify the search path sys.path dynamically
* issue deprecation warnings
* modify the name of the module which is going to be imported
* return a different module

def preImportHook(name: str) -> (None, str, ModuleType instance):
    """The pre import hook is run before the module is loaded
    and inserted into sys modules

    Return values::
     * None
       No special treatment
     * string: new_name
       The module "new_name" is loaded instead of the module "name"
     * module object
       The module object is inserted into sys.modules and returned by
       the import statement.
     * raise Exception
       The import is stopped and a chained ImportError is raised
    """

The pre import hook could be useful for
http://www.python.org/dev/peps/pep-0364/.

The pre import hook can probably be implemented in pure Python with a
meta path hook as described in http://www.python.org/dev/peps/pep-0302/.
I see the pre import hook as a lightweight meta path hook with an easy
to use interface.

Christian

From lists at cheimes.de  Sat Dec  8 22:49:21 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 08 Dec 2007 22:49:21 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <20071208210451.470963A405E@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>	<4759100D.5030408@gmail.com>
	<47592F9E.7090107@cheimes.de>	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>	<475A3203.6060405@gmail.com>
	<475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
Message-ID: <475B1161.7050704@cheimes.de>

Phillip J. Eby wrote:
> Note that in my implementation, an entry is added to sys.modules 
> immediately, so this scenario can't happen without *replacing* the 
> sys.modules entry.

I like to separate the implementation of the post import hook from lazy
modules. I think that the hook and lazy modules can be implemented
independently.

>> * module is loaded with __import__() but callbacks weren't fired yet
>>   o the existing import mechanism is called
>>   o after the module is loaded and inserted into sys.modules
>>     the callbacks are fired in reverse order (FILO).
> 
> Why not FIFO?

I don't have a strong opinion on the order. I can life with FIFO, too.
What should happen if a post import hook fails? Should the error be
catch and reported or should the chain stop?

Christian

From pje at telecommunity.com  Sun Dec  9 00:28:15 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 08 Dec 2007 18:28:15 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module  import
In-Reply-To: <475B0D70.4090602@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <475B0D70.4090602@cheimes.de>
Message-ID: <20071208232810.BF4ED3A405E@sparrow.telecommunity.com>

At 10:32 PM 12/8/2007 +0100, Christian Heimes wrote:
>The pre import hook can probably be implemented in pure Python with a
>meta path hook as described in http://www.python.org/dev/peps/pep-0302/.
>I see the pre import hook as a lightweight meta path hook with an easy
>to use interface.

Which means it doesn't need a PEP and can be implemented as a library 
today for any version of Python 2.3+.

The PEP is needed for a post-import (and laziness) hook due to 
interop issues, not to mention the difficulty of getting it right.


From pje at telecommunity.com  Sun Dec  9 00:35:08 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 08 Dec 2007 18:35:08 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <475B1161.7050704@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
Message-ID: <20071208233504.9D8EC3A4068@sparrow.telecommunity.com>

At 10:49 PM 12/8/2007 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > Note that in my implementation, an entry is added to sys.modules
> > immediately, so this scenario can't happen without *replacing* the
> > sys.modules entry.
>
>I like to separate the implementation of the post import hook from lazy
>modules. I think that the hook and lazy modules can be implemented
>independently.

Thinking that they can, and actually producing a tested 
implementation of one that does not, in fact, conflict with the 
implementation of the other, are two different things.

My concern is that I doubt that you can implement the post-import 
hook without in the process making it difficult for anyone else to 
implement a lazy module system that works with it.

To put it another way, the only way a post-import callback can know 
that a lazy module has been loaded, is if in some respect the lazy 
module system *lets* it know.

Conversely, if a lazy module system puts a module into sys.modules, a 
callback system that isn't based on module *objects* (as opposed to 
module names), will incorrectly believe that the module is already 
imported and fire the callback...  causing the lazy module to be 
imported, thereby breaking the laziness.

And this is only the problem that I'm aware of for *my* concept of 
lazy modules.  There are, I believe, at least two other lazy module 
libraries out there.

So, if you propose to separate the mechanism, I think the burden is 
on the proposer to show *how* this separation can be achieved.


>What should happen if a post import hook fails? Should the error be
>catch and reported or should the chain stop?

The "Importing" package just lets the chain stop, and the remaining 
callbacks are never called.  My thought is that hooks should be 
responsible for their own error logging or whatnot.  Letting the 
failure pass through ensures that the programmers who wrote the hooks 
clean up their code.  :)


From greg.ewing at canterbury.ac.nz  Sun Dec  9 00:37:30 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Dec 2007 12:37:30 +1300
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <20071208210451.470963A405E@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
Message-ID: <475B2ABA.8080906@canterbury.ac.nz>

Phillip J. Eby wrote:

> Lazy importing is putting a module object into sys.modules, but not 
> loading its contents until you attempt to get or set a module attribute.

How is that expected to be useful? If you're not going
to access any attributes of a module, why can you simply
not import it in the first place?

It wouldn't be sufficient for my intended uses of lazy
importing, where I need the import to be triggered by
accessing a specific attribute of a *different* module
(namely a package which imports classes from submodules
and puts their names in its own namespace).

--
Greg

From pje at telecommunity.com  Sun Dec  9 01:05:26 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 08 Dec 2007 19:05:26 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475B2ABA.8080906@canterbury.ac.nz>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B2ABA.8080906@canterbury.ac.nz>
Message-ID: <20071209000522.31CE43A405E@sparrow.telecommunity.com>

At 12:37 PM 12/9/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Lazy importing is putting a module object into sys.modules, but not
> > loading its contents until you attempt to get or set a module attribute.
>
>How is that expected to be useful? If you're not going
>to access any attributes of a module, why can you simply
>not import it in the first place?

It speeds application startup by deferring imports until first use, 
and *without* requiring *every* function using the imported module(s) 
to include an import statement.

Once the module is actually loaded, attribute access is as fast as it 
normally is (because the custom module type then uses the normal 
object.__getattribute__ and object.__setattr__ methods once again.


>It wouldn't be sufficient for my intended uses of lazy
>importing, where I need the import to be triggered by
>accessing a specific attribute of a *different* module
>(namely a package which imports classes from submodules
>and puts their names in its own namespace).

Yes, that's a different use case - as I said, other people have 
different use cases for lazy importing and wrote libraries with 
different approaches.  That's why a PEP should be done, to draw those 
folks out of the woodwork.


From skip at pobox.com  Sun Dec  9 02:15:17 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 8 Dec 2007 19:15:17 -0600
Subject: [Python-3000] bsddb185 v1.0 for Python 2.6 and 3.0
Message-ID: <18267.16805.948614.915298@montanaro.dyndns.org>


Python 3.0 will dispense with the rarely used, but occasionally
indispensible, bsddb185 module.  I extracted the source code and unit tests
from the current Python trunk, wrote a setup.py, made a couple slight mods
so it would build and pass tests under both Python 2.6 and 3.0.  It's
available from the Python Package Index:

    http://pypi.python.org/pypi/bsddb185

Cheers,

-- 
Skip Montanaro - skip at pobox.com - http://www.webfast.com/~skip/

From noamraph at gmail.com  Sun Dec  9 09:33:18 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Sun, 9 Dec 2007 10:33:18 +0200
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
Message-ID: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>

Hello,

I would like to re-raise the issue of float repr() -- making repr(1.1)
== '1.1' instead of '1.1000000000000001'.

My use case is data manipulation in the interactive shell - an
extremely powerful tool which, it seems, not so many people use. Many
times I have float data. I think that you'll agree with me that, for
example:

>>> height['Alice']
1.67

Is much easier to understand than

>>> height['Alice']
1.6699999999999999

Not to mention

>>> height
{'David': 1.81, 'Alice': 1.67, 'Bob': 1.76, 'Barbara': 1.65}

Versus:

>>> height
{'Bob': 1.76, 'Barbara': 1.6499999999999999, 'Alice':
1.6699999999999999, 'David': 1.8100000000000001}


I think that the reason for the long representation is that it uses a
simple algorithm that makes "eval(repr(f)) == f" always true. However,
why not use another, a bit more complex, algorithm, which will still
preserve "eval(repr(f)) == f", but which will shorten the result when
it can?

You see, it's not even that the current algorithm is exact - for
example, the actual, stored, representation of 1.67 is, on my
computer, 1.1010101110000101000111101011100001010001111010111. The
exact decimal representation of that number is
1.6699999999999999289457264239899814128875732421875. I agree that
"1.6699999999999999" is better, but isn't "1.67" the best?

Have a good day,
Noam

From martin at v.loewis.de  Sun Dec  9 11:23:11 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 09 Dec 2007 11:23:11 +0100
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
Message-ID: <475BC20F.1090106@v.loewis.de>

> I would like to re-raise the issue of float repr() -- making repr(1.1)
> == '1.1' instead of '1.1000000000000001'.

Can you propose an algorithm that meets your needs, and still has the
property of unambiguously identifying the true floating point number?

It's (perhaps) easy to request this, but much more difficult to
implement it.

Regards,
Martin

From tjreedy at udel.edu  Sun Dec  9 12:05:41 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 9 Dec 2007 06:05:41 -0500
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
Message-ID: <fjgi65$l9r$1@ger.gmane.org>


"Noam Raphael" <noamraph at gmail.com> wrote in message 
news:b348a0850712090033r61577b83hc8d8a324705ef0f7 at mail.gmail.com...
| My use case is data manipulation in the interactive shell -

When doing things other than add and subtract, one soon gets floats that 
are no longer such 'even' decimals, even if the input is.

| Many times I have float data.

| >>> height['Alice']
| 1.67

For parroting back low precision input, I sort of see your point, but you 
already knew your input values,

| Is much easier to understand than
|
| >>> height['Alice']
| 1.6699999999999999

so I do not see how there is a problem with understanding them.

Of course, in this case, you can get what you want with
>>> print height['Alice']
1.67

It seems your real problem is that repr() rather than str() is applied 
within collections.  (I am not sure exactly why but suspect there is a 
reason.)

| I think that the reason for the long representation is that it uses a
| simple algorithm that makes "eval(repr(f)) == f" always true.

A necessary condition for this is that every float have its own 
representation, so that f != g ==> repr(f) != repr(g).  I think this is a 
nice property.  You seem to agree.

|  However,
| why not use another, a bit more complex, algorithm, which will still
| preserve "eval(repr(f)) == f", but which will shorten the result when it 
can?

Do you have such an algorithm?  I have the impression that Tim Peters (or 
whoever) tried and gave up.  Note that 1.6700000000000001 converts to a 
different binary than 1.67 or 1.6699999999999999, and so cannot be rounded 
to 1.67 (and preserve the condition), no matter how much more 
'understandable' the latter is.  In other words, some numbers wiill round 
the way you expect but other will not.  This might end up being at least as 
confusing at the current situation.

| You see, it's not even that the current algorithm is exact

No, that would require even longer decimals.  I think it intends to gives 
the closest 17 digit number (plus exponent). 17 being enough to give unique 
representations.  (I do not know if this includes subnormalized floats.)

Terry Jan Reedy






From qrczak at knm.org.pl  Sun Dec  9 12:09:23 2007
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Sun, 09 Dec 2007 12:09:23 +0100
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
Message-ID: <1197198563.650.6.camel@qrnik>

Dnia 09-12-2007, N o godzinie 10:33 +0200, Noam Raphael pisze:

> I think that the reason for the long representation is that it uses a
> simple algorithm that makes "eval(repr(f)) == f" always true. However,
> why not use another, a bit more complex, algorithm, which will still
> preserve "eval(repr(f)) == f", but which will shorten the result when
> it can?

"Printing Floating-Point Numbers Quickly and Accurately"
Robert G. Burger, R. Kent Dybvig

http://www.cs.indiana.edu/~burger/FP-Printing-PLDI96.pdf
http://www.cs.indiana.edu/~burger/

I used this algorithm for my language Kogut.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From g.brandl at gmx.net  Sun Dec  9 12:53:40 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 09 Dec 2007 12:53:40 +0100
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <fjgi65$l9r$1@ger.gmane.org>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
	<fjgi65$l9r$1@ger.gmane.org>
Message-ID: <fjgkvu$s7j$1@ger.gmane.org>

Terry Reedy schrieb:
> "Noam Raphael" <noamraph at gmail.com> wrote in message 
> news:b348a0850712090033r61577b83hc8d8a324705ef0f7 at mail.gmail.com...
> | My use case is data manipulation in the interactive shell -

You could always override sys.displayhook in order to handle floats
differently.

> It seems your real problem is that repr() rather than str() is applied 
> within collections.  (I am not sure exactly why but suspect there is a 
> reason.)

Consider ["1, 2, 3"].

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 lists at cheimes.de  Sun Dec  9 17:22:25 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 09 Dec 2007 17:22:25 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module   import
In-Reply-To: <20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>	<4759100D.5030408@gmail.com>
	<47592F9E.7090107@cheimes.de>	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>	<475A3203.6060405@gmail.com>
	<475B04DA.7050201@cheimes.de>	<20071208210451.470963A405E@sparrow.telecommunity.com>	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
Message-ID: <475C1641.10702@cheimes.de>

Phillip J. Eby wrote:
 > Thinking that they can, and actually producing a tested
> implementation of one that does not, in fact, conflict with the 
> implementation of the other, are two different things.
> 
> My concern is that I doubt that you can implement the post-import 
> hook without in the process making it difficult for anyone else to 
> implement a lazy module system that works with it.
> 
> To put it another way, the only way a post-import callback can know 
> that a lazy module has been loaded, is if in some respect the lazy 
> module system *lets* it know.
> 
> Conversely, if a lazy module system puts a module into sys.modules, a 
> callback system that isn't based on module *objects* (as opposed to 
> module names), will incorrectly believe that the module is already 
> imported and fire the callback...  causing the lazy module to be 
> imported, thereby breaking the laziness.
> 
> And this is only the problem that I'm aware of for *my* concept of 
> lazy modules.  There are, I believe, at least two other lazy module 
> libraries out there.
> 
> So, if you propose to separate the mechanism, I think the burden is 
> on the proposer to show *how* this separation can be achieved.

I see your point. The post import hook would indeed conflict with the
laziness of lazy imports if a hook is defined on a module which is
loaded lazy. I wasn't that far in my proposal and I haven't thought
about the implications yet. Thanks for pointing to the problem!

The touch points between post import hooks and lazy imports are minimal.
The lazy module implemenation needs a way to notify the post import hook
that a module was loaded. On the other hand the post import hook just
needs way to detect if a module was loaded for real. Unless I'm totally
mistaken the problem is reduced to two steps in the load mechanism and
to two API methods:

* The notification mechanism of the post import hook must check if a
module was loaded for real before it fires the callbacks.

* The lazy module implementation must notify the post import hook that a
module was loaded.

In Python/C pseudo code:

PyModule_PostImportHooks = {}

def PyModule_IsLoaded(module):
    return getattr(Module, '__lazy__', False)

def PyModule_NotifyPostLoaded(module):
    if not PyModule_IsLoaded(module):
        return
    hooks = PyModule_PostImportHooks.get(module.__name__, None)
    if hooks is None:
        return
    for hook in hooks:
        hook(module)

Lazy modules and post import hooks can still be developed independently
if we agree on names and signature of the two functions. Lazy modules
can implement the PyModule_NotifyPostLoaded() function as NOOP and vice
versa.

Or do you see other connection points?

> The "Importing" package just lets the chain stop, and the remaining 
> callbacks are never called.  My thought is that hooks should be 
> responsible for their own error logging or whatnot.  Letting the 
> failure pass through ensures that the programmers who wrote the hooks 
> clean up their code.  :)

Sounds good to me! :)

Christian

From noamraph at gmail.com  Sun Dec  9 18:38:17 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Sun, 9 Dec 2007 19:38:17 +0200
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <1197198563.650.6.camel@qrnik>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
	<1197198563.650.6.camel@qrnik>
Message-ID: <b348a0850712090938h7d78fa7cyd975bc56f02e8548@mail.gmail.com>

Great! He also provides C code, in
http://www.cs.indiana.edu/~burger/fp/index.html

The license says: "All software (c) 1996 Robert G. Burger. Permission
is hereby granted, free of charge, to any person obtaining a copy of
this software, to deal in the software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the software." I guess
it means that it can be used.

Does anyone have any objections in principle for a patch based on his
code that will shorten the repr() of floats while preserving
"eval(repr(f)) == f"? If not, I'll try to write it in the next few
days.

(I checked - indeed, the current implementation just uses the OS's
conversion method with 17 precision digits.)

Noam

2007/12/9, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl>:
> Dnia 09-12-2007, N o godzinie 10:33 +0200, Noam Raphael pisze:
>
> > I think that the reason for the long representation is that it uses a
> > simple algorithm that makes "eval(repr(f)) == f" always true. However,
> > why not use another, a bit more complex, algorithm, which will still
> > preserve "eval(repr(f)) == f", but which will shorten the result when
> > it can?
>
> "Printing Floating-Point Numbers Quickly and Accurately"
> Robert G. Burger, R. Kent Dybvig
>
> http://www.cs.indiana.edu/~burger/FP-Printing-PLDI96.pdf
> http://www.cs.indiana.edu/~burger/
>
> I used this algorithm for my language Kogut.
>
> --
>    __("<         Marcin Kowalczyk
>    \__/       qrczak at knm.org.pl
>     ^^     http://qrnik.knm.org.pl/~qrczak/
>
> _______________________________________________
> 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/noamraph%40gmail.com
>

From gustavo at niemeyer.net  Sun Dec  9 18:54:06 2007
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Sun, 09 Dec 2007 15:54:06 -0200
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <b348a0850712090938h7d78fa7cyd975bc56f02e8548@mail.gmail.com>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>	<1197198563.650.6.camel@qrnik>
	<b348a0850712090938h7d78fa7cyd975bc56f02e8548@mail.gmail.com>
Message-ID: <475C2BBE.50209@niemeyer.net>


> Great! He also provides C code, in
> http://www.cs.indiana.edu/~burger/fp/index.html

FWIW: http://labix.org/python-nicefloat

-- 
Gustavo Niemeyer
http://niemeyer.net

From skip at pobox.com  Sun Dec  9 21:31:34 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 9 Dec 2007 14:31:34 -0600
Subject: [Python-3000] Is py3k branch still frozen?
Message-ID: <18268.20646.700558.127033@montanaro.dyndns.org>

Is the freeze for 3.0a2 still in place?  I have a trivial docstring fix for
bytesobject.c.

Skip

From lists at cheimes.de  Sun Dec  9 22:05:55 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 09 Dec 2007 22:05:55 +0100
Subject: [Python-3000] Is py3k branch still frozen?
In-Reply-To: <18268.20646.700558.127033@montanaro.dyndns.org>
References: <18268.20646.700558.127033@montanaro.dyndns.org>
Message-ID: <475C58B3.4050804@cheimes.de>

skip at pobox.com wrote:
> Is the freeze for 3.0a2 still in place?  I have a trivial docstring fix for
> bytesobject.c.

The 3.0a2 release is out and the branch is open again.

Christian

From hashcollision at gmail.com  Sun Dec  9 22:21:25 2007
From: hashcollision at gmail.com (hashcollision)
Date: Sun, 9 Dec 2007 16:21:25 -0500
Subject: [Python-3000] Possible Duck Typing Problem in Python 2.5?
Message-ID: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>

>From http://ivory.idyll.org/blog/dec-07/conversions.html:

class X:
    internal = [5,6,7,8]
    def __getitem__(self, i):
        return self.internal[i]

x = X()

l = [1,2,3]
print l + x

fails with

TypeError: can only concatenate list (not "instance") to list

I tried:

class X(list):
 internal = [5, 6, 7, 8]
 def __getitem__(self, i):
  return self.internal[i]
 def __len__(self):
  return internal
 def __iter__(self):
  return internal.__iter__()

but this fails also.

IMHO, this is a problem. Is it? If so, I suggest that it be fixed in
python 3000.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071209/96e9a9b0/attachment.htm 

From mark.russell at zen.co.uk  Sun Dec  9 22:42:34 2007
From: mark.russell at zen.co.uk (Mark Russell)
Date: Sun, 9 Dec 2007 21:42:34 +0000
Subject: [Python-3000] Reverse file iteration patch updated
Message-ID: <AB2FFCD2-62C4-48D4-BC62-C66461A99906@zen.co.uk>

I posted a patch (http://bugs.python.org/issue1677872) a while ago to  
add support for reverse iteration through text files - i.e. making  
this work:

      for line in reversed(open(path)):
          print line

It steps through the file backwards a line at a time, without reading  
the entire file contents first - useful for scanning backwards though  
big log files for example.

Christian Heimes commented that there's a reasonable chance of it  
being accepted, so I've updated the patch to work against the current  
source, as well as adding unit tests and documentation.

Mark Russell

From ggpolo at gmail.com  Sun Dec  9 22:48:28 2007
From: ggpolo at gmail.com (Guilherme Polo)
Date: Sun, 9 Dec 2007 19:48:28 -0200
Subject: [Python-3000] Possible Duck Typing Problem in Python 2.5?
In-Reply-To: <ac2200130712091345n4cb95029sb1365dde18769b83@mail.gmail.com>
References: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>
	<ac2200130712091345n4cb95029sb1365dde18769b83@mail.gmail.com>
Message-ID: <ac2200130712091348u5c65b319v75428f949d04df4f@mail.gmail.com>

---------- Forwarded message ----------
From: Guilherme Polo <ggpolo at gmail.com>
Date: 09/12/2007 19:45
Subject: Re: [Python-3000] Possible Duck Typing Problem in Python 2.5?
To: hashcollision <hashcollision at gmail.com>, python-list at python.org

2007/12/9, hashcollision <hashcollision at gmail.com>:
> From http://ivory.idyll.org/blog/dec-07/conversions.html:
> class X:
>  internal = [5,6,7,8]
>  def __getitem__(self, i):
>  return self.internal[i]
>
> x = X()
>
> l = [1,2,3]
> print l + x
>
>
>
> fails withTypeError: can only concatenate list (not "instance") to list
> I tried:
> class X(list):
>  internal = [5, 6, 7, 8]
>
>  def __getitem__(self, i):
>   return self.internal[i]
>  def __len__(self):
>   return internal
>  def __iter__(self):
>   return internal.__iter__()
> but this fails also.

Try this:

class X(list):
  internal = [5, 6, 7, 8]
  def __init__(self):
    list.__init__(self, self.internal)

x = X()
l = [1,2,3]
print l + x

> IMHO, this is a problem. Is it? If so, I suggest that it be fixed in python
> 3000.
>
> _______________________________________________
> 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/ggpolo%40gmail.com
>
>

-- 
-- Guilherme H. Polo Goncalves

From daniel at stutzbachenterprises.com  Mon Dec 10 00:03:33 2007
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 9 Dec 2007 17:03:33 -0600
Subject: [Python-3000] Possible Duck Typing Problem in Python 2.5?
In-Reply-To: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>
References: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>
Message-ID: <eae285400712091503q1013b8b9s21c7bcec8dac0ab@mail.gmail.com>

On Dec 9, 2007 3:21 PM, hashcollision <hashcollision at gmail.com> wrote:

> From http://ivory.idyll.org/blog/dec-07/conversions.html:
>
> class X:
>     internal = [5,6,7,8]
>     def __getitem__(self, i):
>         return self.internal[i]
>
> x = X()
>
> l = [1,2,3]
> print l + x
>
> fails with
>
> TypeError: can only concatenate list (not "instance") to list
>
> If you want class X to understand "+" via duck-typing, overload __add__
and __radd__.

-- 
Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071209/5a1722bf/attachment.htm 

From greg.ewing at canterbury.ac.nz  Mon Dec 10 00:46:51 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 10 Dec 2007 12:46:51 +1300
Subject: [Python-3000] Possible Duck Typing Problem in Python 2.5?
In-Reply-To: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>
References: <37f76d50712091321x76bd0215p7c5d856c772e8ed7@mail.gmail.com>
Message-ID: <475C7E6B.4040906@canterbury.ac.nz>

hashcollision wrote:

> TypeError: can only concatenate list (not "instance") to list
> 
> IMHO, this is a problem. Is it? If so, I suggest that it be fixed in python 3000.

I seem to remember this came up before, and was considered
not to be something that needed changing.

How would you decide what type the result should be?
Who's to say it should be a list and not an X?
Better to be explicit:

   l2 = l + list(x)

or if in-place modification is acceptable,

   l.extend(x)

--
Greg


From jimjjewett at gmail.com  Mon Dec 10 02:22:38 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sun, 9 Dec 2007 20:22:38 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475C1641.10702@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<4759100D.5030408@gmail.com> <47592F9E.7090107@cheimes.de>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
Message-ID: <fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>

On 12/9/07, Christian Heimes <lists at cheimes.de> wrote:

> The touch points between post import hooks and lazy imports
> are minimal.

Could you give me a use-case for post-import hooks *without* lazy imports?

As nearly as I can tell, either

(1)  The module is already loaded (and the whole infrastructure is overhead)

(2a)  You will be importing the module.  Then you can just run your
hooks directly without any infrastructure.

(2b)  You will not be importing the module you need to hook -- in
which case I think you want laziness as well.

-jJ

From lists at cheimes.de  Mon Dec 10 02:35:42 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 10 Dec 2007 02:35:42 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>	<4759100D.5030408@gmail.com>
	<47592F9E.7090107@cheimes.de>	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>	<475A3203.6060405@gmail.com>
	<475B04DA.7050201@cheimes.de>	<20071208210451.470963A405E@sparrow.telecommunity.com>	<475B1161.7050704@cheimes.de>	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
Message-ID: <475C97EE.70005@cheimes.de>

Jim Jewett wrote:
> Could you give me a use-case for post-import hooks *without* lazy imports?

This thread was started with perfect valid and good use case. We want to
apply ABCs to classes of optional modules like decimal and array without
loading the module or modifying the module.

   @imp.imported('decimal')
   def register(decimal):
       Inexact.register(decimal.Decimal)

Lazy imports won't do the trick because the register could would load
the real module. As you can see the problem can be solved with a post
import hook but *not* with lazy imports.

> As nearly as I can tell, either
> 
> (1)  The module is already loaded (and the whole infrastructure is overhead)
> 
> (2a)  You will be importing the module.  Then you can just run your
> hooks directly without any infrastructure.
> 
> (2b)  You will not be importing the module you need to hook -- in
> which case I think you want laziness as well.

(3) You want to run your hook in order to modify or register
    the contents module when the user imports the module.

By the way I've started to work on an implementation:
http://bugs.python.org/issue1576

Christian

From jimjjewett at gmail.com  Mon Dec 10 03:19:44 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sun, 9 Dec 2007 21:19:44 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475C97EE.70005@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>
	<475A3203.6060405@gmail.com> <475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
Message-ID: <fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>

On 12/9/07, Christian Heimes <lists at cheimes.de> wrote:
> Jim Jewett wrote:
> > Could you give me a use-case for post-import hooks *without* lazy imports?

> This thread was started with perfect valid and good use case. We want to
> apply ABCs to classes of optional modules like decimal and array without
> loading the module or modifying the module.
>
>    @imp.imported('decimal')
>    def register(decimal):
>        Inexact.register(decimal.Decimal)
>
> Lazy imports won't do the trick because the register could would load
> the real module. As you can see the problem can be solved with a post
> import hook but *not* with lazy imports.

I had thought that wouldn't be run until the module was otherwise
loaded.  Are you saying that just creating the callback forces a load
under lazy loading, but not under post-load hooks?

-jJ

From tjreedy at udel.edu  Mon Dec 10 03:29:24 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 9 Dec 2007 21:29:24 -0500
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com><fjgi65$l9r$1@ger.gmane.org>
	<fjgkvu$s7j$1@ger.gmane.org>
Message-ID: <fji8a2$243$1@ger.gmane.org>


"Georg Brandl" <g.brandl at gmx.net> wrote in message 
news:fjgkvu$s7j$1 at ger.gmane.org...
| Terry Reedy schrieb:
| > It seems your real problem is that repr() rather than str() is applied
| > within collections.  (I am not sure exactly why but suspect there is a
| > reason.)
|
| Consider ["1, 2, 3"].

OK, but this is only an issue with the difference between the str and repr 
of *strings*.  The str function of collections *could* be modified to use 
str on numbers.  The number of digits is irrelevance to the string 
formatting issue.  The new Number ABC would make this switch easier, of 
course. 




From greg.ewing at canterbury.ac.nz  Mon Dec 10 07:12:54 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 10 Dec 2007 19:12:54 +1300
Subject: [Python-3000] Reverse file iteration patch updated
In-Reply-To: <AB2FFCD2-62C4-48D4-BC62-C66461A99906@zen.co.uk>
References: <AB2FFCD2-62C4-48D4-BC62-C66461A99906@zen.co.uk>
Message-ID: <475CD8E6.9060603@canterbury.ac.nz>

Mark Russell wrote:
> I posted a patch (http://bugs.python.org/issue1677872) a while ago to  
> add support for reverse iteration through text files - i.e. making  
> this work:
> 
>       for line in reversed(open(path)):
>           print line

If this involves hacking reversed() to give it special
knowledge of files, I'm not sure it's the best place
to put it.

--
Greg

From greg at krypto.org  Mon Dec 10 07:21:13 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 9 Dec 2007 22:21:13 -0800
Subject: [Python-3000] Reverse file iteration patch updated
In-Reply-To: <475CD8E6.9060603@canterbury.ac.nz>
References: <AB2FFCD2-62C4-48D4-BC62-C66461A99906@zen.co.uk>
	<475CD8E6.9060603@canterbury.ac.nz>
Message-ID: <52dc1c820712092221h791a1c8fl65110f0902a5e458@mail.gmail.com>

it doesn't.  read the patch.  it adds a __reversed__ method.

 http://bugs.python.org/file8902/reverse-file-iterator-20071209.diff

On 12/9/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> Mark Russell wrote:
> > I posted a patch (http://bugs.python.org/issue1677872) a while ago to
> > add support for reverse iteration through text files - i.e. making
> > this work:
> >
> >       for line in reversed(open(path)):
> >           print line
>
> If this involves hacking reversed() to give it special
> knowledge of files, I'm not sure it's the best place
> to put 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/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071209/4d8a8275/attachment-0001.htm 

From phd at phd.pp.ru  Mon Dec 10 07:28:01 2007
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Mon, 10 Dec 2007 09:28:01 +0300
Subject: [Python-3000] Reverse file iteration patch updated
In-Reply-To: <475CD8E6.9060603@canterbury.ac.nz>
References: <AB2FFCD2-62C4-48D4-BC62-C66461A99906@zen.co.uk>
	<475CD8E6.9060603@canterbury.ac.nz>
Message-ID: <20071210062801.GB19000@phd.pp.ru>

On Mon, Dec 10, 2007 at 07:12:54PM +1300, Greg Ewing wrote:
> Mark Russell wrote:
> > I posted a patch (http://bugs.python.org/issue1677872) a while ago to  
> > add support for reverse iteration through text files - i.e. making  
> > this work:
> > 
> >       for line in reversed(open(path)):
> >           print line
> 
> If this involves hacking reversed() to give it special
> knowledge of files, I'm not sure it's the best place
> to put it.

   It adds a method __reversed__() to class io.TextIOWrapper:

http://bugs.python.org/file8902/reverse-file-iterator-20071209.diff

   Looks good for me.

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

From mark at qtrac.eu  Mon Dec 10 15:45:23 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Mon, 10 Dec 2007 14:45:23 +0000
Subject: [Python-3000] poss bug in IDLE 30a1 in Python 30a2
Message-ID: <200712101445.24074.mark@qtrac.eu>

Hi,

When I start IDLE I get this:

Python 3.0a2 (r30a2:59382, Dec 10 2007, 14:21:37) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "copyright", "credits" or "license()" for more information.

    ****************************************************************
    Personal firewall software may warn about the connection IDLE
    makes to its subprocess using this computer's internal loopback
    interface.  This connection is not visible on any external
    interface and no data is sent to or received from the Internet.
    ****************************************************************
    
IDLE 3.0a1      
>>>

That's fine (if slightly confusing regarding the version numbers), but
if I click Options->Configure I get this error output:

: Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py", line 1402, 
in __call__
    return self.func(*args)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py", line 
385, in config_dialog
    configDialog.ConfigDialog(self.top,'Settings')
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
50, in __init__
    self.CreateWidgets()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
69, in CreateWidgets
    page_names=['Fonts/Tabs','Highlighting','Keys','General'])
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
398, in __init__
    self.add_page(name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
413, in add_page
    self._tab_set.add_tab(page_name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
76, in add_tab
    self._arrange_tabs()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
163, in _arrange_tabs
    for row_index in xrange(n_rows):
NameError: global name 'xrange' is not defined

I tried changing xrange to range, but that doesn't work:

: Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py", line 1402, 
in __call__
    return self.func(*args)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py", line 
385, in config_dialog
    configDialog.ConfigDialog(self.top,'Settings')
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
50, in __init__
    self.CreateWidgets()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
69, in CreateWidgets
    page_names=['Fonts/Tabs','Highlighting','Keys','General'])
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
398, in __init__
    self.add_page(name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
413, in add_page
    self._tab_set.add_tab(page_name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
76, in add_tab
    self._arrange_tabs()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py", line 
148, in _arrange_tabs
    for tab_name in self._tabs.keys():
RuntimeError: dictionary changed size during iteration

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From lists at cheimes.de  Mon Dec 10 17:04:22 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 10 Dec 2007 17:04:22 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>	<20071207143515.69EDC3A40AF@sparrow.telecommunity.com>	<475A3203.6060405@gmail.com>
	<475B04DA.7050201@cheimes.de>	<20071208210451.470963A405E@sparrow.telecommunity.com>	<475B1161.7050704@cheimes.de>	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>	<475C1641.10702@cheimes.de>	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
Message-ID: <475D6386.5050501@cheimes.de>

Jim Jewett wrote:
 > I had thought that wouldn't be run until the module was otherwise
> loaded.  Are you saying that just creating the callback forces a load
> under lazy loading, but not under post-load hooks?

The imp.imported (or whatever we name the method) is the register method
for the post import hook system. It's not connected to lazy imports
directly. Internally lazy imports and post import hooks work together
but that's an implementation detail.

I was saying that the problem can't be solved with lazy imports. Here is
an example in doc test style how lazy imports and post import hooks
would work together:

Register a hook
>>> def hook(mod):
...     print "Module loaded"
>>> imp.register_post_import_hook(hook, "decimal")

Load the decimal module lazy.
>>> decimal = imp.importlazy("decimal")

decimal is a lazy module. Any attribute access will load the real
decimal module.
>>> imp.islazy(decimal)
True

Registering the decimal.Decimal class with the Inexact ABC loads the
real decimal module.
>>> Inexact.register(decimal.Decimal)
Module loaded
>>> imp.islazy(decimal)
False

Christian

From jimjjewett at gmail.com  Mon Dec 10 17:41:59 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 10 Dec 2007 11:41:59 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475D6386.5050501@cheimes.de>
References: <20071206174533.9C8171E4005@bag.python.org>
	<475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
Message-ID: <fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>

On 12/10/07, Christian Heimes <lists at cheimes.de> wrote:
> Jim Jewett wrote:
>  > I had thought that wouldn't be run until the module was otherwise
> > loaded.  Are you saying that just creating the callback forces a load
> > under lazy loading, but not under post-load hooks?

> I was saying that the problem can't be solved with lazy imports.

Let me rephrase.

You seem to be treating lazy imports and post-import hooks as two
independent binary choices, so that there are four logical
possibilities.

I don't see any point to supporting post-load hooks *without* lazy
importing, so to me, only three of those possibilities make sense.
(neither, lazy only, lazy+postimport)

Is there an example where you would use post-import hooks even though
the system didn't support lazy import?  The best I can come up with is
"Don't import module X just for me, but *if* someone else imports it,
then I want to do these things to/with it."

This still sounds like a (kind of) lazy import to me.  Are you
considering that not-even-a-lazy-import because you care about even
indirect usage?

-jJ

From p.f.moore at gmail.com  Mon Dec 10 18:16:25 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 10 Dec 2007 17:16:25 +0000
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
	<fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
Message-ID: <79990c6b0712100916qb706117n2449e9af36241d10@mail.gmail.com>

On 10/12/2007, Jim Jewett <jimjjewett at gmail.com> wrote:
> Is there an example where you would use post-import hooks even though
> the system didn't support lazy import?  The best I can come up with is
> "Don't import module X just for me, but *if* someone else imports it,
> then I want to do these things to/with it."

That sounds to me exactly like the registration use case Christian mentioned:

Register decimal.Decimal as a "ABC.Number" type - but don't import
decimal just so that I can do this, rather wait and do the
registration as soon as the code executes "import decimal" explicitly.

Paul.

From guido at python.org  Mon Dec 10 20:01:50 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Dec 2007 11:01:50 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <1197135930.24311.26.camel@qrnik>
References: <1197135930.24311.26.camel@qrnik>
Message-ID: <ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>

On Dec 8, 2007 9:45 AM, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> I'm confused about storing methods in class dictionaries from the point
> of view of the C API.
>
> 1. Let's say that I have a callable PyObject called f, of my type
>    defined in C. I want to store something derived from f as A.m
>    for some class A, such that for an object a of class A, calling
>    a.m(*args) ends up calling f(a, *args).
>
>    In Python2 PyMethod_New(f, NULL, a) seems to be the right to store
>    in the class. How to do the equivalent thing in Python3?

Add a __get__ (instance) method to f's class, and store f directly in
A. Your __get__ method should return a bound object using
PyMethod_New(f, a).

>    BTW, applying PyMethod_Type to 3 arguments crashes Python3. I think
>    this line is the culprit (classobject.c):
>
>         if (!PyArg_UnpackTuple(args, "method", 2, 3,
>                               &func, &self))
>
>    Should be 2 instead of 3. There used to be an extra parameter.

Thanks for noting! Christian Heimes fixed this already.

> 2. As above, but f is to be implemented as a C function. I found the
>    following working for a new-style class:
>
>    - make PyMethodDef struct for the method
>    - use PyDescr_NewMethod
>    - store the resulting object in the class
>
>    but it does not work for a classic class (such that an exception
>    class in Python 2.4 and below) to which I want to add a method.
>    Here it seems to be doable differently:
>
>    - make PyMethodDef struct for the method, but with an unused first
>      parameter
>    - use PyCFunction_New, with NULL as 'self'
>    - use PyMethod_New on the resulting function, NULL, and the class
>    - store the resulting object in the class
>
>    Can this be done simpler? Having separate variants for different
>    Python versions is OK.

Unsure how this differs from the previous case. I'd recommend wrapping
f in another class defined in C.

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

From guido at python.org  Mon Dec 10 20:20:45 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Dec 2007 11:20:45 -0800
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <fji8a2$243$1@ger.gmane.org>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
	<fjgi65$l9r$1@ger.gmane.org> <fjgkvu$s7j$1@ger.gmane.org>
	<fji8a2$243$1@ger.gmane.org>
Message-ID: <ca471dc20712101120q4e9d4ae7l439c2323f2a928ac@mail.gmail.com>

On Dec 9, 2007 6:29 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Georg Brandl" <g.brandl at gmx.net> wrote in message
> news:fjgkvu$s7j$1 at ger.gmane.org...
> | Terry Reedy schrieb:
> | > It seems your real problem is that repr() rather than str() is applied
> | > within collections.  (I am not sure exactly why but suspect there is a
> | > reason.)
> |
> | Consider ["1, 2, 3"].
>
> OK, but this is only an issue with the difference between the str and repr
> of *strings*.  The str function of collections *could* be modified to use
> str on numbers.  The number of digits is irrelevance to the string
> formatting issue.  The new Number ABC would make this switch easier, of
> course.

I don't think this line of argument is productive.

I am looking forward to fixes to repr() that maintain the
float->binary->float roundtripping property while also make repr(0.1)
== "0.1" and repr(0.3) == "0.3".

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

From noamraph at gmail.com  Mon Dec 10 20:28:02 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Mon, 10 Dec 2007 21:28:02 +0200
Subject: [Python-3000] Reconsider repr(0.1) == '0.10000000000000001'
In-Reply-To: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
References: <b348a0850712090033r61577b83hc8d8a324705ef0f7@mail.gmail.com>
Message-ID: <b348a0850712101128y7b251d8ble816c2a441a3cf7@mail.gmail.com>

Ok, I wrote a patch! http://bugs.python.org/issue1580

Now you have:

>>> 1.1
1.1

It works! And it passes the test suite! I added a test which takes a
list of about a 1000 floating point numbers which were designed to
check binary to decimal conversion.

It turns out that Tcl implemented this algorithm for tcl8.5 (which is
currently in beta stage). See
http://www.tcl.tk/cgi-bin/tct/tip/132.html for the TIP (that's how
they call a PEP...) I took the formatting function (which is quite
simple) from them. For the main algorithm, which converts a double to
the shortest list of digits needed to recreate it, I used the code by
Robert G. Burger (the author of the article) since it is stand-alone.
The original code can be found here:
http://www.cs.indiana.edu/~burger/fp/index.html

The patch is against current py3k svn.

Have a good day,
Noam


2007/12/9, Noam Raphael <noamraph at gmail.com>:
> Hello,
>
> I would like to re-raise the issue of float repr() -- making repr(1.1)
> == '1.1' instead of '1.1000000000000001'.
>
> My use case is data manipulation in the interactive shell - an
> extremely powerful tool which, it seems, not so many people use. Many
> times I have float data. I think that you'll agree with me that, for
> example:
>
> >>> height['Alice']
> 1.67
>
> Is much easier to understand than
>
> >>> height['Alice']
> 1.6699999999999999
>
> Not to mention
>
> >>> height
> {'David': 1.81, 'Alice': 1.67, 'Bob': 1.76, 'Barbara': 1.65}
>
> Versus:
>
> >>> height
> {'Bob': 1.76, 'Barbara': 1.6499999999999999, 'Alice':
> 1.6699999999999999, 'David': 1.8100000000000001}
>
>
> I think that the reason for the long representation is that it uses a
> simple algorithm that makes "eval(repr(f)) == f" always true. However,
> why not use another, a bit more complex, algorithm, which will still
> preserve "eval(repr(f)) == f", but which will shorten the result when
> it can?
>
> You see, it's not even that the current algorithm is exact - for
> example, the actual, stored, representation of 1.67 is, on my
> computer, 1.1010101110000101000111101011100001010001111010111. The
> exact decimal representation of that number is
> 1.6699999999999999289457264239899814128875732421875. I agree that
> "1.6699999999999999" is better, but isn't "1.67" the best?
>
> Have a good day,
> Noam
>

From guido at python.org  Mon Dec 10 20:35:40 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Dec 2007 11:35:40 -0800
Subject: [Python-3000] tet_docxmlrpc.py broken in py3k branch
Message-ID: <ca471dc20712101135rae1d077g266455fe670dec7d@mail.gmail.com>

Can someone fix the test_docxmlrpc.py brokenness in py3k? It seems to
have been merged in without any editing.

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

From pje at telecommunity.com  Mon Dec 10 20:56:44 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 10 Dec 2007 14:56:44 -0500
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.co
 m>
References: <20071206174533.9C8171E4005@bag.python.org>
	<475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
	<fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
Message-ID: <20071210195641.54CFE3A40A4@sparrow.telecommunity.com>

At 11:41 AM 12/10/2007 -0500, Jim Jewett wrote:
>Is there an example where you would use post-import hooks even though
>the system didn't support lazy import?  The best I can come up with is
>"Don't import module X just for me, but *if* someone else imports it,
>then I want to do these things to/with it."

Yes - that's precisely the use case that motivated the current 
proposal, not to mention the use case that motivated me implementing 
"weak imports" (as I called them) in the Importing package four years 
ago or so.


>This still sounds like a (kind of) lazy import to me.

The "Importing" package implements callbacks as an extension of lazy 
imports, but it isn't the only way to do it.  Christian's patch 
implements callbacks without lazy importing, although I think it 
still needs a hook (such as his previously-proposed '__lazy__' 
attribute) to let it interoperate with lazy-importing systems.


From lists at cheimes.de  Mon Dec 10 21:07:45 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 10 Dec 2007 21:07:45 +0100
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <20071210195641.54CFE3A40A4@sparrow.telecommunity.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<475B04DA.7050201@cheimes.de>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
	<fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
	<20071210195641.54CFE3A40A4@sparrow.telecommunity.com>
Message-ID: <475D9C91.1070709@cheimes.de>

Phillip J. Eby wrote:
> The "Importing" package implements callbacks as an extension of lazy
> imports, but it isn't the only way to do it.  Christian's patch
> implements callbacks without lazy importing, although I think it still
> needs a hook (such as his previously-proposed '__lazy__' attribute) to
> let it interoperate with lazy-importing systems.

My local sandbox has a new function PyModule_IsLazy(). It is used by the
post import hook system and imp.is_lazy() to query the status of a
module object. If imp.is_lazy(module) returns True then the post import
hooks aren't called and the lazy import system is responsible to call
imp.post_import_notify(module).

Christian

From greg.ewing at canterbury.ac.nz  Mon Dec 10 22:38:00 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 11 Dec 2007 10:38:00 +1300
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <79990c6b0712100916qb706117n2449e9af36241d10@mail.gmail.com>
References: <20071206174533.9C8171E4005@bag.python.org>
	<20071208210451.470963A405E@sparrow.telecommunity.com>
	<475B1161.7050704@cheimes.de>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
	<fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
	<79990c6b0712100916qb706117n2449e9af36241d10@mail.gmail.com>
Message-ID: <475DB1B8.3060302@canterbury.ac.nz>

Paul Moore wrote:
> On 10/12/2007, Jim Jewett <jimjjewett at gmail.com> wrote:
> 
>>"Don't import module X just for me, but *if* someone else imports it,
>>then I want to do these things to/with it."
> 
> That sounds to me exactly like the registration use case Christian mentioned:
> 
> Register decimal.Decimal as a "ABC.Number" type - but don't import
> decimal just so that I can do this,

I think the point is that you could just as well
achieve this by lazily importing decimal with a
callback.

--
Greg

From guido at python.org  Mon Dec 10 22:47:32 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Dec 2007 13:47:32 -0800
Subject: [Python-3000] Interest in PEP for callbacks on module import
In-Reply-To: <475DB1B8.3060302@canterbury.ac.nz>
References: <20071206174533.9C8171E4005@bag.python.org>
	<20071208233504.9D8EC3A4068@sparrow.telecommunity.com>
	<475C1641.10702@cheimes.de>
	<fb6fbf560712091722o3e08552mf36d80e647a768c4@mail.gmail.com>
	<475C97EE.70005@cheimes.de>
	<fb6fbf560712091819s63f66690l712d0688053163ca@mail.gmail.com>
	<475D6386.5050501@cheimes.de>
	<fb6fbf560712100841m7367f6a0w3b61247d96bf3820@mail.gmail.com>
	<79990c6b0712100916qb706117n2449e9af36241d10@mail.gmail.com>
	<475DB1B8.3060302@canterbury.ac.nz>
Message-ID: <ca471dc20712101347n64fc6fa4vc8a8b17f6fbe3874@mail.gmail.com>

FWIW I just modified decimal to import numbers and made Decimal
inherit from Inexact and Real. No impact whatsoever.

--Guido

On Dec 10, 2007 1:38 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Paul Moore wrote:
> > On 10/12/2007, Jim Jewett <jimjjewett at gmail.com> wrote:
> >
> >>"Don't import module X just for me, but *if* someone else imports it,
> >>then I want to do these things to/with it."
> >
> > That sounds to me exactly like the registration use case Christian mentioned:
> >
> > Register decimal.Decimal as a "ABC.Number" type - but don't import
> > decimal just so that I can do this,
>
> I think the point is that you could just as well
> achieve this by lazily importing decimal with a
> callback.
>
> --
> 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/guido%40python.org
>



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

From qrczak at knm.org.pl  Mon Dec 10 23:57:26 2007
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Mon, 10 Dec 2007 23:57:26 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
Message-ID: <1197327447.9136.21.camel@qrnik>

Dnia 10-12-2007, Pn o godzinie 11:01 -0800, Guido van Rossum pisze:

> Add a __get__ (instance) method to f's class, and store f directly in
> A. Your __get__ method should return a bound object using
> PyMethod_New(f, a).

Thank you, but I can't do this, because I want a generic mechanism which
works for an arbitrary f (which will probably be a Kogut object wrapped
in Python, and not all such objects play the role of methods but they
use the same type).

I solved this by a separate Python type, which is a simple wrapper not
specific to my other types, so I'm a bit surprised that there is no
such type among various wrappers and descriptors in the Python core
(or perhaps I overlooked it somewhere). It wraps a single object f, and
its get_descr(m, obj, type) returns PyMethod_New(f, obj) (for Python3)
or PyMethod_New(f, obj, type) (for Python2), except that if obj == NULL,
it returns f itself.

It's even better than PyMethod_New(f, NULL, type) in that it does not
need to know the class when created.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From guido at python.org  Tue Dec 11 00:16:04 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Dec 2007 15:16:04 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <1197327447.9136.21.camel@qrnik>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
Message-ID: <ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>

On Dec 10, 2007 2:57 PM, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> Dnia 10-12-2007, Pn o godzinie 11:01 -0800, Guido van Rossum pisze:
>
> > Add a __get__ (instance) method to f's class, and store f directly in
> > A. Your __get__ method should return a bound object using
> > PyMethod_New(f, a).
>
> Thank you, but I can't do this, because I want a generic mechanism which
> works for an arbitrary f (which will probably be a Kogut object wrapped
> in Python, and not all such objects play the role of methods but they
> use the same type).
>
> I solved this by a separate Python type, which is a simple wrapper not
> specific to my other types, so I'm a bit surprised that there is no
> such type among various wrappers and descriptors in the Python core
> (or perhaps I overlooked it somewhere). It wraps a single object f, and
> its get_descr(m, obj, type) returns PyMethod_New(f, obj) (for Python3)
> or PyMethod_New(f, obj, type) (for Python2), except that if obj == NULL,
> it returns f itself.
>
> It's even better than PyMethod_New(f, NULL, type) in that it does not
> need to know the class when created.

I guess there's no such egneric wrapper in the core because the use
case hasn't presented itself before -- or nobody thought of creating a
generic solution.

It's also possible that in the past this was done using unbound
methods -- so perhaps their removal from the method object may have
been premature.

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

From lists at cheimes.de  Tue Dec 11 01:32:54 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 11 Dec 2007 01:32:54 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
References: <1197135930.24311.26.camel@qrnik>	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
Message-ID: <475DDAB6.5030900@cheimes.de>

Guido van Rossum wrote:
> I guess there's no such egneric wrapper in the core because the use
> case hasn't presented itself before -- or nobody thought of creating a
> generic solution.
> 
> It's also possible that in the past this was done using unbound
> methods -- so perhaps their removal from the method object may have
> been premature.

I had the use case once as I fixed ctypes' COMError for 3.0a2 but it was
easier to change the code than to come up with a generic wrapper type.

A wrapper which takes a PyCFunction is definitely helpful and would make
code porting from 2.x to 3.0 easier. I'm +1 to add one.

Marcin, can you come up with a patch?

Christian



From ndbecker2 at gmail.com  Tue Dec 11 02:09:13 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 10 Dec 2007 20:09:13 -0500
Subject: [Python-3000] Combined configparse + optparse (interest?)
References: <fjbpcm$c7r$1@ger.gmane.org>
Message-ID: <fjknvq$odc$1@ger.gmane.org>

Neal Becker wrote:

> Right now we have 2 rather different stdlib modules for parsing options
> from
> ini-style files and from command line.  I believe it would be desirable to
> have one module that can handle both.  Is there interest in pursuing this
> idea?

Can python learn from c++?  Maybe sometimes.  I think the design of
boost::program_options is a pretty example. 

http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/program_options.html

The basic design is split into 3 components:
 * Options Description
 * Parsers
 * Storage 

One of the benefits of this separation is that various parsers can be
plugged in.  The library includes 3 parsers:
 * Command line
 * ini-file
 * environment variables

IMO, this design would be a good starting point for a python library.


From qrczak at knm.org.pl  Tue Dec 11 10:50:59 2007
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Tue, 11 Dec 2007 10:50:59 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <475DDAB6.5030900@cheimes.de>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de>
Message-ID: <1197366659.22820.52.camel@qrnik>

Dnia 11-12-2007, Wt o godzinie 01:32 +0100, Christian Heimes pisze:

> Marcin, can you come up with a patch?

Below is what I have, after some cleaning and renaming. Needs more
cleaning to plug it into Python modules and conform to Python coding
standards.

I'm not convinced that Python on its own needs it. Perhaps Python
already distinguishes function-like objects from others rigorously
enough that they should care about being descriptors themselves.
CFunction does not define descr_get - why? Maybe it should?

I needed it for my language binding because Kogut objects are wrapped
in Python in a generic way, they have the same Python type no matter
whether they were functions or not on the other side. I needed separate
Python types only for exceptions being thrown, for iterators being run,
and for explicit wrapping of functions to suppress default conversions
of the arguments and the result.

Now that I am thinking about it, the generic Kogut object wrapper should
emulate the Python behavior more closely in this respect and provide a
descr_get which checks whether the wrapped object has a Kogut FUNCTION
type, like I'm emulating various other protocols (numbers, collections,
pickling, basic I/O) which also need to sometimes do different things
depending on the type of the object on the other side. In particular
the issue of iteration over dictionaries, coupled with the inability to
reliably distinguish a Python dictionary from a sequence was a headache.
Successfully solved.

Having descr_get in the basic object wrapper will make the method wrapper
unnecessary. I will remove it today.

Or maybe the language binding should generate new Python types on
the fly, to correspond 1-1 to Kogut types, and similarly in the other
direction. This would complicate things and introduce some overhead,
but perhaps this how it should really be done.

I never liked the idea that in Python an instance method is distinguished
from a class member by the fact of being a function. What if someone
wants to have a function as a class member? Now Python has staticmethod
to override this behavior (the method wrapper that we will add or not is
the overriding in the other direction), but it would be more clean if
Python distinguished functions from methods since the beginning, e.g.:

   method self.foo(args):
      ...

with regular functions not being turned into methods, i.e. being
staticmethods by default.


typedef struct {
   PyObject_HEAD
   PyObject *fun;
} PyInstanceMethod;

static void
PyInstanceMethod_dealloc(PyObject *self) {
   _PyObject_GC_UNTRACK(self);
   Py_DECREF(((PyInstanceMethod *)self)->fun);
   PyObject_GC_Del(self);
}

static int
PyInstanceMethod_traverse(PyObject *self, visitproc visit, void *arg) {
   Py_VISIT(((PyInstanceMethod *)self)->fun);
   return 0;
}

static PyObject *
PyInstanceMethod_descr_get(PyObject *descr, PyObject *obj, PyObject *type) {
   PyObject *fun = ((PyInstanceMethod *)descr)->fun;
   (void)type;
   if (obj == NULL)
      return fun;
   else
      return PyMethod_New(fun, obj);
}

PyTypeObject PyInstanceMethod_Type = {
   PyVarObject_HEAD_INIT(&PyType_Type, 0)
   \"instance-method\",        /* tp_name */
   sizeof(PyInstanceMethod),   /* tp_basicsize */
   0,                          /* tp_itemsize */
   PyInstanceMethod_dealloc,   /* tp_dealloc */
   0,                          /* tp_print */
   0,                          /* tp_getattr */
   0,                          /* tp_setattr */
   0,                          /* tp_compare */
   0,                          /* tp_repr */
   0,                          /* tp_as_number */
   0,                          /* tp_as_sequence */
   0,                          /* tp_as_mapping */
   0,                          /* tp_hash  */
   0,                          /* tp_call */
   0,                          /* tp_str */
   0,                          /* tp_getattro */
   0,                          /* tp_setattro */
   0,                          /* tp_as_buffer */
   Py_TPFLAGS_DEFAULT
      | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
   0,                          /* tp_doc */
   PyInstanceMethod_traverse,  /* tp_traverse */
   0,                          /* tp_clear */
   0,                          /* tp_richcompare */
   0,                          /* tp_weaklistoffset */
   0,                          /* tp_iter */
   0,                          /* tp_iternext */
   0,                          /* tp_methods */
   0,                          /* tp_members */
   0,                          /* tp_getset */
   0,                          /* tp_base */
   0,                          /* tp_dict */
   PyInstanceMethod_descr_get, /* tp_descr_get */
   0,                          /* tp_descr_set */
   0,                          /* tp_dictoffset */
   0,                          /* tp_init */
   0,                          /* tp_alloc */
   PyType_GenericNew,          /* tp_new */
   0,                          /* tp_free */
   0,                          /* tp_is_gc */
   0,                          /* tp_bases */
   0,                          /* tp_mro */
   0,                          /* tp_cache */
   0,                          /* tp_subclasses */
   0,                          /* tp_weaklist */
   0,                          /* tp_del */
};

PyObject *
PyInstanceMethod_New(PyObject *fun) {
   PyInstanceMethod *method;
   method = PyObject_GC_New(PyInstanceMethod, &PyInstanceMethod_Type);
   if (method == NULL) return NULL;
   Py_INCREF(fun);
   method->fun = fun;
   _PyObject_GC_TRACK(method);
   return (PyObject *)method;
}

Initialization:

   if (PyType_Ready(&PyInstanceMethod_Type) == -1) ...

Needs the ability to be constructed from Python.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From lists at cheimes.de  Tue Dec 11 13:49:47 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 11 Dec 2007 13:49:47 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <1197366659.22820.52.camel@qrnik>
References: <1197135930.24311.26.camel@qrnik>	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>	<1197327447.9136.21.camel@qrnik>	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>	<475DDAB6.5030900@cheimes.de>
	<1197366659.22820.52.camel@qrnik>
Message-ID: <475E876B.5070804@cheimes.de>

Marcin ?Qrczak? Kowalczyk wrote:
> Below is what I have, after some cleaning and renaming. Needs more
> cleaning to plug it into Python modules and conform to Python coding
> standards.

http://bugs.python.org/issue1587
I've added \t to the formatting, changed the name slightly and filled a
bunch of slots.

>>> class Example:
...     id = instancemethod(id)
...     str = instancemethod(str)
...     hash = hash
...
>>> Example.id
<built-in function id>
>>> Example().id
<bound method Example.id of <__main__.Example object at 0x83b3bcc>>

>>> ex = Example()
>>> hex(ex.id())
'0x83b3ea4'
>>> ex.id
<bound method Example.id of <__main__.Example object at 0x83b3ea4>>
>>> ex.str()
'<__main__.Example object at 0x83b3ea4>'

>>> ex.hash()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: hash() takes exactly one argument (0 given)

>>> instancemethod(id)
<instancemethod id at 0x83a15a4>
>>> instancemethod(id).__func__
<built-in function id>

> I'm not convinced that Python on its own needs it. Perhaps Python
> already distinguishes function-like objects from others rigorously
> enough that they should care about being descriptors themselves.
> CFunction does not define descr_get - why? Maybe it should?

I'm sure Guido can answer the question better than me. :)

Christian

From guido at python.org  Tue Dec 11 18:39:27 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 11 Dec 2007 09:39:27 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <1197366659.22820.52.camel@qrnik>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
Message-ID: <ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>

On Dec 11, 2007 1:50 AM, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> I'm not convinced that Python on its own needs it. Perhaps Python
> already distinguishes function-like objects from others rigorously
> enough that they should care about being descriptors themselves.

Right. The use case just doesn't exist.

> CFunction does not define descr_get - why?

Because C functions aren't typically placed in classes defined in
Python -- they enter the world through various tables of function
pointers linked from the type object.

> Maybe it should?

I don't see why we should bother.

I know it would break all sorts of stuff; lots of code stores a
builtin function on a class (for all sorts of reasons), relying on it
not having a __get__ method.

[...]
> I never liked the idea that in Python an instance method is distinguished
> from a class member by the fact of being a function. What if someone
> wants to have a function as a class member? Now Python has staticmethod
> to override this behavior (the method wrapper that we will add or not is
> the overriding in the other direction), but it would be more clean if
> Python distinguished functions from methods since the beginning, e.g.:
>
>    method self.foo(args):
>       ...
>
> with regular functions not being turned into methods, i.e. being
> staticmethods by default.

Yeah, that won't happen.

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

From greg.ewing at canterbury.ac.nz  Wed Dec 12 03:10:29 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 12 Dec 2007 15:10:29 +1300
Subject: [Python-3000] Method descriptors
In-Reply-To: <ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
Message-ID: <475F4315.9080907@canterbury.ac.nz>

Guido van Rossum wrote:
> On Dec 11, 2007 1:50 AM, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> 
> > CFunction does not define descr_get - why?
> 
> I don't see why we should bother.

I put forward a possible reason recently -- so that
Pyrex-defined functions could be used as methods
without requiring any special trickery.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From guido at python.org  Wed Dec 12 06:30:58 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 11 Dec 2007 21:30:58 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <475F4315.9080907@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
Message-ID: <ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>

On Dec 11, 2007 6:10 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Dec 11, 2007 1:50 AM, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> >
> > > CFunction does not define descr_get - why?
> >
> > I don't see why we should bother.
>
> I put forward a possible reason recently -- so that
> Pyrex-defined functions could be used as methods
> without requiring any special trickery.

Would the new API that Christian just checked in help?

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

From fdrake at acm.org  Wed Dec 12 06:52:49 2007
From: fdrake at acm.org (Fred Drake)
Date: Wed, 12 Dec 2007 00:52:49 -0500
Subject: [Python-3000] Combined configparse + optparse (interest?)
In-Reply-To: <fjknvq$odc$1@ger.gmane.org>
References: <fjbpcm$c7r$1@ger.gmane.org> <fjknvq$odc$1@ger.gmane.org>
Message-ID: <03D6AF20-41BD-4EFE-9E82-D6AB0834EE06@acm.org>

On Dec 10, 2007, at 8:09 PM, Neal Becker wrote:
> Can python learn from c++?  Maybe sometimes.  I think the design of
> boost::program_options is a pretty example.

Nice, overall, but the devil is in the details, as always.  I didn't  
see anything in the documentation about how unrecognized values are  
handled; do they cause exceptions to be raised, or otherwise get  
reported to the application in some way?

Is the configuration file handled by that an ini file?  After looking  
around the documentation briefly, but without downloading the code/ 
tests, I couldn't see anything about the actual file format.  It's  
entirely possible I missed something; a link would be appreciated.

On the whole, while ignoring the C++-centric aspects of the API  
described in the documentation, I'm inclined to say that the model may  
be a lot simpler than would be needed for something like zc.buildout  
which ends up adding a lot on top of the basic ConfigParser model.   
But the boost::program_options package looks like it supports a much  
simpler model than ConfigParser.

ConfigParser provides only two parts of the boost::program_options  
"stack": a parser, and storage.  (Admittedly it conflates the two  
concerns.)  This is actually an advantage, as it supports alternate  
approaches to defining the schema for the configuration data.

The relationship between the command-line and configuration files can  
certainly be made easier to deal with by adding a schema component,  
but it's not actually necessary.  For zc.buildout, command line  
options of the form section:option=value are interpreted as another  
configuration file that takes precedence over the ini-format files  
that are loaded using ConfigParser.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>


From lists at cheimes.de  Wed Dec 12 20:08:49 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 12 Dec 2007 20:08:49 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <475F4315.9080907@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>	<1197327447.9136.21.camel@qrnik>	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>	<475DDAB6.5030900@cheimes.de>
	<1197366659.22820.52.camel@qrnik>	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
Message-ID: <476031C1.2030904@cheimes.de>

Greg Ewing wrote:
> I put forward a possible reason recently -- so that
> Pyrex-defined functions could be used as methods
> without requiring any special trickery.

http://svn.python.org/view?rev=59469&view=rev

PyObject *wrapped = PyInstanceMethod_New(PyObject *callable);

The API isn't exposed to Python programs yet but it implements all
necessary bits and pieces for Python code.

Christian


From lists at cheimes.de  Wed Dec 12 20:08:49 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 12 Dec 2007 20:08:49 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <475F4315.9080907@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>	<1197327447.9136.21.camel@qrnik>	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>	<475DDAB6.5030900@cheimes.de>
	<1197366659.22820.52.camel@qrnik>	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
Message-ID: <476031C1.2030904@cheimes.de>

Greg Ewing wrote:
> I put forward a possible reason recently -- so that
> Pyrex-defined functions could be used as methods
> without requiring any special trickery.

http://svn.python.org/view?rev=59469&view=rev

PyObject *wrapped = PyInstanceMethod_New(PyObject *callable);

The API isn't exposed to Python programs yet but it implements all
necessary bits and pieces for Python code.

Christian


From greg.ewing at canterbury.ac.nz  Wed Dec 12 23:45:05 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 13 Dec 2007 11:45:05 +1300
Subject: [Python-3000] Method descriptors
In-Reply-To: <ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
	<ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>
Message-ID: <47606471.90608@canterbury.ac.nz>

Guido van Rossum wrote:
> On Dec 11, 2007 6:10 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>>I put forward a possible reason recently -- so that
>>Pyrex-defined functions could be used as methods
>>without requiring any special trickery.
> 
> 
> Would the new API that Christian just checked in help?

Can you give me a link to that? I wasn't following the
discussion that closely.

--
Greg



From guido at python.org  Wed Dec 12 23:52:52 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 12 Dec 2007 14:52:52 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <47606471.90608@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
	<ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>
	<47606471.90608@canterbury.ac.nz>
Message-ID: <ca471dc20712121452n696e6a9cu53df4ddb9c17b08f@mail.gmail.com>

On Dec 12, 2007 2:45 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Dec 11, 2007 6:10 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >
> >>I put forward a possible reason recently -- so that
> >>Pyrex-defined functions could be used as methods
> >>without requiring any special trickery.
> >
> >
> > Would the new API that Christian just checked in help?
>
> Can you give me a link to that? I wasn't following the
> discussion that closely.

http://svn.python.org/view?rev=59469&view=rev

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

From qrczak at knm.org.pl  Thu Dec 13 00:03:34 2007
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Thu, 13 Dec 2007 00:03:34 +0100
Subject: [Python-3000] Method descriptors
In-Reply-To: <475F4315.9080907@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
Message-ID: <1197500614.14452.46.camel@qrnik>

Dnia 12-12-2007, ?r o godzinie 15:10 +1300, Greg Ewing pisze:

> > > CFunction does not define descr_get - why?
> > 
> > I don't see why we should bother.
> 
> I put forward a possible reason recently -- so that
> Pyrex-defined functions could be used as methods
> without requiring any special trickery.

My case doesn't use the method wrapper type anymore. Adding the
appropriate descr_get to the generic wrapper of foreign objects,
distinguishing a foreign function type, works well. I'm still
surprised that CFunction differs from a Python function

I must say that I find the current set of various wrappers and
descriptors confusing: it doesn't seem to be described in one place;
a type has up to four names (a C API name, the name in repr of the type,
the name in repr of instances, and a name in types or builtin module);
the repr names have words separated by " ", "-" or "_" seemingly at
random; the sets of types available directly from C and from the types
module differ from each other, and also differ by Python versions;
and the types depend on technical details - for example the types of:
   MyClass.my_method
   str.upper
   str.__len__
are all different, even though they are all kinds of unbound methods.

Examples of name inconsistencies (with common "Type" suffixes stripped):

- a. CFunction 
  b. builtin_function_or_method
  c. built-in function
  d. BuiltinFunction = BuiltinMethod

- a. MemberDescr
  b. member_descriptor
  c. member
  d. MemberDescriptor

- a. MethodDescr
  b. method_descriptor
  c. method
  d. -

- a. Method
  b. method
  c. bound method
  d. Method

- a. - (wrapper, but not exported)
  b. method-wrapper
  c. method-wrapper
  d. -

- a. WrapperDescr
  b. wrapper_descriptor
  c. slot wrapper
  d. -

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From greg.ewing at canterbury.ac.nz  Thu Dec 13 00:06:28 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 13 Dec 2007 12:06:28 +1300
Subject: [Python-3000] Method descriptors
In-Reply-To: <ca471dc20712121452n696e6a9cu53df4ddb9c17b08f@mail.gmail.com>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101101r36b468eav330869015fc9d5e3@mail.gmail.com>
	<1197327447.9136.21.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
	<ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>
	<47606471.90608@canterbury.ac.nz>
	<ca471dc20712121452n696e6a9cu53df4ddb9c17b08f@mail.gmail.com>
Message-ID: <47606974.9050709@canterbury.ac.nz>

Guido van Rossum wrote:
> On Dec 12, 2007 2:45 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>>Can you give me a link to that? I wasn't following the
>>discussion that closely.
> 
> http://svn.python.org/view?rev=59469&view=rev

That's not quite what I had in mind -- Pyrex already solves
the problem by wrapping the function in another object.
My suggestion was to make the PyCFunction itself obey the
descriptor protocol so as to create bound methods.

--
Greg

From guido at python.org  Thu Dec 13 00:13:55 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 12 Dec 2007 15:13:55 -0800
Subject: [Python-3000] Method descriptors
In-Reply-To: <47606974.9050709@canterbury.ac.nz>
References: <1197135930.24311.26.camel@qrnik>
	<ca471dc20712101516m1d28291ay9d635075a7b3e560@mail.gmail.com>
	<475DDAB6.5030900@cheimes.de> <1197366659.22820.52.camel@qrnik>
	<ca471dc20712110939t74b4e23em694b5e2f010ad2ef@mail.gmail.com>
	<475F4315.9080907@canterbury.ac.nz>
	<ca471dc20712112130g14e8d9bdmdcdbad168ffc8010@mail.gmail.com>
	<47606471.90608@canterbury.ac.nz>
	<ca471dc20712121452n696e6a9cu53df4ddb9c17b08f@mail.gmail.com>
	<47606974.9050709@canterbury.ac.nz>
Message-ID: <ca471dc20712121513i21b4389du5fd711faa8235a2@mail.gmail.com>

On Dec 12, 2007 3:06 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Dec 12, 2007 2:45 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >
> >>Can you give me a link to that? I wasn't following the
> >>discussion that closely.
> >
> > http://svn.python.org/view?rev=59469&view=rev
>
> That's not quite what I had in mind -- Pyrex already solves
> the problem by wrapping the function in another object.
> My suggestion was to make the PyCFunction itself obey the
> descriptor protocol so as to create bound methods.

As I explained earlier, that would break a fair amount of existing code.

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

From vizcaynot at gmail.com  Tue Dec 11 23:18:18 2007
From: vizcaynot at gmail.com (Vizcayno)
Date: Tue, 11 Dec 2007 14:18:18 -0800 (PST)
Subject: [Python-3000] Is it possible that some issues reported in the
	tracker can loose or be deleted?
Message-ID: <70aa9170-ea1e-4c20-9cdd-4b970ea0b318@e23g2000prf.googlegroups.com>

I reported a pair of issues in diferent dates, last one was 3 days
ago. However, each time I save and verify the status, it dissapears
from the tracker. Why does it occur?
Thanks!

From noamraph at gmail.com  Thu Dec 13 10:24:42 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Thu, 13 Dec 2007 11:24:42 +0200
Subject: [Python-3000] Dropping the parentheses after dict.keys?
Message-ID: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>

Hello,

Was it considered to drop the parentheses after "dict.keys()", to make
it "dict.keys" (that is, to make it a property instead of a method
with no arguments)? If it was, please forgive me - a few minutes of
googling didn't find it.

I now write (another?) ordered dict, and I thought that the easiest
way to get the key with a given index would be "d.keys[5]". But it
means that d.keys is a collection of keys, not a method - and why not?

If backwards compatibility is a problem, we can make d.keys return the
same object that d.keys() currently returns, and add to the dict_keys
object a calling operation which raises a warning and returns itself.

Of course, d.values and d.items are the same.

Have a good day,
Noam

From ggpolo at gmail.com  Thu Dec 13 10:29:25 2007
From: ggpolo at gmail.com (Guilherme Polo)
Date: Thu, 13 Dec 2007 07:29:25 -0200
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
Message-ID: <ac2200130712130129x6250cd02w9e83d30c1fe98a2c@mail.gmail.com>

2007/12/13, Noam Raphael <noamraph at gmail.com>:
> Hello,
>
> Was it considered to drop the parentheses after "dict.keys()", to make
> it "dict.keys" (that is, to make it a property instead of a method
> with no arguments)? If it was, please forgive me - a few minutes of
> googling didn't find it.

Such thing wasn't considered, I doubt it will.

>
> I now write (another?) ordered dict, and I thought that the easiest
> way to get the key with a given index would be "d.keys[5]". But it
> means that d.keys is a collection of keys, not a method - and why not?
>

d.keys()[5] won't work on python 3.0 aswell because it returns a view now.

> If backwards compatibility is a problem, we can make d.keys return the
> same object that d.keys() currently returns, and add to the dict_keys
> object a calling operation which raises a warning and returns itself.
>
> Of course, d.values and d.items are the same.
>
> Have a good day,
> Noam
> _______________________________________________
> 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/ggpolo%40gmail.com
>


-- 
-- Guilherme H. Polo Goncalves

From noamraph at gmail.com  Thu Dec 13 10:41:50 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Thu, 13 Dec 2007 11:41:50 +0200
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <ac2200130712130129x6250cd02w9e83d30c1fe98a2c@mail.gmail.com>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
	<ac2200130712130129x6250cd02w9e83d30c1fe98a2c@mail.gmail.com>
Message-ID: <b348a0850712130141x2c957492u52569880d4a027aa@mail.gmail.com>

2007/12/13, Guilherme Polo <ggpolo at gmail.com>:
> 2007/12/13, Noam Raphael <noamraph at gmail.com>:
> > Hello,
> >
> > Was it considered to drop the parentheses after "dict.keys()", to make
> > it "dict.keys" (that is, to make it a property instead of a method
> > with no arguments)? If it was, please forgive me - a few minutes of
> > googling didn't find it.
>
> Such thing wasn't considered, I doubt it will.

You know, that is a very well-reasoned explanation.

> >
> > I now write (another?) ordered dict, and I thought that the easiest
> > way to get the key with a given index would be "d.keys[5]". But it
> > means that d.keys is a collection of keys, not a method - and why not?
> >
>
> d.keys()[5] won't work on python 3.0 aswell because it returns a view now.
>
Let me clarify myself. I just meant to say that I think that "for x in
d.keys" looks better than "for x in d.keys()", and that if you create
a dict subclass which has ordering, "d.keys[5]" looks really better
than "d.keys()[5]".

Noam

From skip at pobox.com  Thu Dec 13 13:36:02 2007
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 13 Dec 2007 06:36:02 -0600
Subject: [Python-3000] Is it possible that some issues reported in the
 tracker can loose or be deleted?
In-Reply-To: <70aa9170-ea1e-4c20-9cdd-4b970ea0b318@e23g2000prf.googlegroups.com>
References: <70aa9170-ea1e-4c20-9cdd-4b970ea0b318@e23g2000prf.googlegroups.com>
Message-ID: <18273.10034.84700.687329@montanaro.dyndns.org>


    Vizcayno> I reported a pair of issues in diferent dates, last one was 3
    Vizcayno> days ago. However, each time I save and verify the status, it
    Vizcayno> dissapears from the tracker. Why does it occur?

I don't know.  I passed your mail along to the people who manage the
tracker.

-- 
Skip Montanaro - skip at pobox.com - http://www.webfast.com/~skip/

From guido at python.org  Thu Dec 13 16:51:17 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 13 Dec 2007 07:51:17 -0800
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
Message-ID: <ca471dc20712130751p286fbf78v16663300d4a9cf81@mail.gmail.com>

On Dec 13, 2007 1:24 AM, Noam Raphael <noamraph at gmail.com> wrote:
> Was it considered to drop the parentheses after "dict.keys()", to make
> it "dict.keys" (that is, to make it a property instead of a method
> with no arguments)? If it was, please forgive me - a few minutes of
> googling didn't find it.

Yes, it was considered, and rejected over a combination of backwards
compatibility and concerns that for some user-defined sequences it
would be expensive to compute and hence wrong to look like a mere
attribute. (The backwards compatibility concerns weren't merely of
breaking every line of code in existence -- we can fix that with the
2to3 tool; they were also over user expectations.)

> I now write (another?) ordered dict, and I thought that the easiest
> way to get the key with a given index would be "d.keys[5]". But it
> means that d.keys is a collection of keys, not a method - and why not?
>
> If backwards compatibility is a problem, we can make d.keys return the
> same object that d.keys() currently returns, and add to the dict_keys
> object a calling operation which raises a warning and returns itself.
>
> Of course, d.values and d.items are the same.

I'm not going to argue over your API choice for your own class, but I
have to take a firm stance regarding changes to the core language and
its builtins at this point. We had an extensive period for submission
and review of change proposals, which ended in April. While we are
still making some adjustments, we are limiting changes at this point
to what appears necessary based on actual experience with the alpha
releases, and your proposal doesn't fall in that category.

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

From greg.ewing at canterbury.ac.nz  Thu Dec 13 21:19:03 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 14 Dec 2007 09:19:03 +1300
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
Message-ID: <476193B7.8080202@canterbury.ac.nz>

Noam Raphael wrote:
> I thought that the easiest
> way to get the key with a given index would be "d.keys[5]". But it
> means that d.keys is a collection of keys, not a method - and why not?

Half of your suggestion is being done -- d.keys() will create
and return an indexable view object, rather than a list.

Keeping it as a method rather than a property makes sense,
since it still involves the creation of an object rather than
just providing access to something already existing.

--
Greg

From greg.ewing at canterbury.ac.nz  Thu Dec 13 21:24:51 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 14 Dec 2007 09:24:51 +1300
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <476193B7.8080202@canterbury.ac.nz>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
	<476193B7.8080202@canterbury.ac.nz>
Message-ID: <47619513.7080207@canterbury.ac.nz>

I wrote:
> d.keys() will create
> and return an indexable view object,

Sorry, that's not quite right -- it probably won't be
indexable, only iterable.

But the argument for keeping it as a method still
applies.

--
Greg

From martin at v.loewis.de  Thu Dec 13 23:27:21 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 13 Dec 2007 23:27:21 +0100
Subject: [Python-3000] Is it possible that some issues reported in the
 tracker can loose or be deleted?
In-Reply-To: <70aa9170-ea1e-4c20-9cdd-4b970ea0b318@e23g2000prf.googlegroups.com>
References: <70aa9170-ea1e-4c20-9cdd-4b970ea0b318@e23g2000prf.googlegroups.com>
Message-ID: <4761B1C9.6020406@v.loewis.de>

> I reported a pair of issues in diferent dates, last one was 3 days
> ago. However, each time I save and verify the status, it dissapears
> from the tracker. Why does it occur?

Can you report more details? When you did "Submit changes", did you get
a green box saying "issue XYZ created"? If so, what was the number XYZ?
If not, did you get instead a red box giving some error message? If
so, what was the error message?

Without those details, it will be impossible to determine what happened.
Just try again in case you cannot remember.

The tracker will not ever lose any issues.

Regards,
Martin

From alexandre at peadrop.com  Thu Dec 13 23:42:17 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 13 Dec 2007 17:42:17 -0500
Subject: [Python-3000] Should str and bytes hash equally?
Message-ID: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>

In Python 2.x, having the byte string and unicode hash equally was
desirable, since u'' == ''. But since the bytes and str are always
considered unequal, in Python 3k, I think would be good idea to make
their hash unequal too. So, what do you think?

-- Alexandre

From rhamph at gmail.com  Thu Dec 13 23:46:08 2007
From: rhamph at gmail.com (Adam Olsen)
Date: Thu, 13 Dec 2007 15:46:08 -0700
Subject: [Python-3000] Should str and bytes hash equally?
In-Reply-To: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
References: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
Message-ID: <aac2c7cb0712131446y7a206024q901ef294b6bbfddf@mail.gmail.com>

On Dec 13, 2007 3:42 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> In Python 2.x, having the byte string and unicode hash equally was
> desirable, since u'' == ''. But since the bytes and str are always
> considered unequal, in Python 3k, I think would be good idea to make
> their hash unequal too. So, what do you think?

It's irrelevant.  It's always possible to get the same hashes.  We'd
need a performance reason or the like to bother changing either of
them.

-- 
Adam Olsen, aka Rhamphoryncus

From martin at v.loewis.de  Fri Dec 14 00:03:13 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 14 Dec 2007 00:03:13 +0100
Subject: [Python-3000] Should str and bytes hash equally?
In-Reply-To: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
References: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
Message-ID: <4761BA31.3060709@v.loewis.de>

> In Python 2.x, having the byte string and unicode hash equally was
> desirable, since u'' == ''. But since the bytes and str are always
> considered unequal, in Python 3k, I think would be good idea to make
> their hash unequal too. So, what do you think?

To phrase Adam Olsen's observation in a different way: *Why* do you
think it would be good idea? Do you think it would make things more
correct, or more efficient? If neither, what other desirable effect
would that change have?

Regards,
Martin

From noamraph at gmail.com  Fri Dec 14 00:04:14 2007
From: noamraph at gmail.com (Noam Raphael)
Date: Fri, 14 Dec 2007 01:04:14 +0200
Subject: [Python-3000] Dropping the parentheses after dict.keys?
In-Reply-To: <47619513.7080207@canterbury.ac.nz>
References: <b348a0850712130124t3303a4bbi2ead46984219747b@mail.gmail.com>
	<476193B7.8080202@canterbury.ac.nz>
	<47619513.7080207@canterbury.ac.nz>
Message-ID: <b348a0850712131504r42ac7105qa067fb1857168a04@mail.gmail.com>

Thanks for the explanation. I'm sure that I will be able to live
(although miserably) with dict.keys(). ;)

Noam

From alexandre at peadrop.com  Fri Dec 14 00:50:54 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 13 Dec 2007 18:50:54 -0500
Subject: [Python-3000] Should str and bytes hash equally?
In-Reply-To: <4761BA31.3060709@v.loewis.de>
References: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
	<4761BA31.3060709@v.loewis.de>
Message-ID: <acd65fa20712131550w3e882fc5gb7974b0663336eac@mail.gmail.com>

On Dec 13, 2007 6:03 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> > In Python 2.x, having the byte string and unicode hash equally was
> > desirable, since u'' == ''. But since the bytes and str are always
> > considered unequal, in Python 3k, I think would be good idea to make
> > their hash unequal too. So, what do you think?
>
> To phrase Adam Olsen's observation in a different way: *Why* do you
> think it would be good idea? Do you think it would make things more
> correct, or more efficient? If neither, what other desirable effect
> would that change have?
>

I first thought that would avoid the somehow odd behavior that appears
when mixing unicode and byte strings in dictionaries:

   >>> d = {}
   >>> d = {'spam': 0}
   >>> d[u'spam'] = 1
   >>> d
   {'spam': 1}

But then, I realized this wasn't a problem anymore, in Python 3k,
since unicode string (str) and byte string (bytes) are always unequal.

However, that is not why I proposed to make the hashes unequal. I was
worry that people would be tempted to use this equality property as an
easy way (but wrong) to compare strings:

   >>> hash('hello') == hash(b'hello')
   True

I do realize now that it is really a weak argument. And, I don't think
anymore that it justifies changing the hashing functions.

-- Alexandre

From greg.ewing at canterbury.ac.nz  Fri Dec 14 06:36:49 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 14 Dec 2007 18:36:49 +1300
Subject: [Python-3000] Should str and bytes hash equally?
In-Reply-To: <aac2c7cb0712131446y7a206024q901ef294b6bbfddf@mail.gmail.com>
References: <acd65fa20712131442j68317473n841c2b0a0298569b@mail.gmail.com>
	<aac2c7cb0712131446y7a206024q901ef294b6bbfddf@mail.gmail.com>
Message-ID: <47621671.2050209@canterbury.ac.nz>

Adam Olsen wrote:
> It's irrelevant.  It's always possible to get the same hashes.  We'd
> need a performance reason or the like to bother changing either of
> them.

And since there's no reason to think that storing bytes
and unicode in the same dict is likely to be a frequent
requirement, it probably won't affect anything much.

--
Greg

From mark at qtrac.eu  Fri Dec 14 08:05:42 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 14 Dec 2007 07:05:42 +0000
Subject: [Python-3000] the right way to open text files in P3K?
Message-ID: <200712140705.42926.mark@qtrac.eu>

Hi,

I was wondering if it is yet known what the right way to open text files
in P3K will be?

According to the docs the signature for open() is:

    open(filename[, mode[, bufsize]])

Is that going to stay the same and default to UTF-8 if "b" is not in the
mode (or if no mode is specified) and bytes if "b" is present?

Or will the signature change to match the one provided by codecs?

    codecs.open(filename, mode[, encoding[, errors[, buffering]]])

using the logic described above regarding mode?

Or some other way?

Thanks!

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From hashcollision at gmail.com  Fri Dec 14 08:39:05 2007
From: hashcollision at gmail.com (hashcollision)
Date: Fri, 14 Dec 2007 02:39:05 -0500
Subject: [Python-3000] Why lowercase?
Message-ID: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>

I don't think there is any chance that this will change in python 3000
but...
Why is the builtin types lowercase when the convention is for classes to be
in CamelCase? For example, frozenset versus UserDict. Was there any reason
that this is the way it is or is it just a "wart"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071214/5f80209e/attachment.htm 

From lists at cheimes.de  Fri Dec 14 08:42:42 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 14 Dec 2007 08:42:42 +0100
Subject: [Python-3000] the right way to open text files in P3K?
In-Reply-To: <200712140705.42926.mark@qtrac.eu>
References: <200712140705.42926.mark@qtrac.eu>
Message-ID: <476233F2.8010501@cheimes.de>

Mark Summerfield wrote:
> Hi,
> 
> I was wondering if it is yet known what the right way to open text files
> in P3K will be?
> 
> According to the docs the signature for open() is:
> 
>     open(filename[, mode[, bufsize]])

The docs must be outdated. open() accepts more arguments:

open(file, mode='r', buffering=None, encoding=None, errors=None,
newline=None, closefd=True)

> Is that going to stay the same and default to UTF-8 if "b" is not in the
> mode (or if no mode is specified) and bytes if "b" is present?

The new IO library is using UTF-8 as default encoding for text mode
unless a different encoding is given. The open() function and the IO
streams are much closer to the codecs package.

help(open) isn't very helpful in 3.0a2 and earlier. I fixed the doc
string shortly after the release. import io; help(io.open) gives you the
real open function. Please note that the IO library is mostly written in
Python, see Lib/io.py

Christian

From lists at cheimes.de  Fri Dec 14 08:51:28 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 14 Dec 2007 08:51:28 +0100
Subject: [Python-3000] Why lowercase?
In-Reply-To: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
Message-ID: <47623600.7080605@cheimes.de>

hashcollision wrote:
> I don't think there is any chance that this will change in python 3000
> but...
> Why is the builtin types lowercase when the convention is for classes to be
> in CamelCase? For example, frozenset versus UserDict. Was there any reason
> that this is the way it is or is it just a "wart"?

Frozenset is a built-in type and not a class. All built-in types like
dict and float are spelled in lower case. UserDict is a relict from the
past and scheduled for removal. It's functionality is replaced by the
subclass-able dict type and ABCs.

Python 3.0 will be wart free.

Christian

From mark at qtrac.eu  Fri Dec 14 11:11:41 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 14 Dec 2007 10:11:41 +0000
Subject: [Python-3000] the right way to open text files in P3K?
In-Reply-To: <476233F2.8010501@cheimes.de>
References: <200712140705.42926.mark@qtrac.eu> <476233F2.8010501@cheimes.de>
Message-ID: <200712141011.41874.mark@qtrac.eu>

On 2007-12-14, Christian Heimes wrote:
> Mark Summerfield wrote:
> > Hi,
> >
> > I was wondering if it is yet known what the right way to open text files
> > in P3K will be?
> >
> > According to the docs the signature for open() is:
> >
> >     open(filename[, mode[, bufsize]])
>
> The docs must be outdated. open() accepts more arguments:
>
> open(file, mode='r', buffering=None, encoding=None, errors=None,
> newline=None, closefd=True)
>
> > Is that going to stay the same and default to UTF-8 if "b" is not in the
> > mode (or if no mode is specified) and bytes if "b" is present?
>
> The new IO library is using UTF-8 as default encoding for text mode
> unless a different encoding is given. The open() function and the IO
> streams are much closer to the codecs package.
>
> help(open) isn't very helpful in 3.0a2 and earlier. I fixed the doc
> string shortly after the release. import io; help(io.open) gives you the
> real open function. Please note that the IO library is mostly written in
> Python, see Lib/io.py

The API is exactly what I'd hoped it would be:-)
(So is there any need for codecs.open(), apart from backwards
compatibility?)

I've now updated library/functions.rst (change 59499) to reflect your
io.open() docs.

If you had the time you might want to check that I haven't said anything
untrue!

Unfortunately io.open() doesn't say what errors=None means. I hope it
means 'strict', but whatever it means, I'd like to specify the meaning
in the docs.

Thanks!

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From pje at telecommunity.com  Fri Dec 14 12:54:06 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 14 Dec 2007 06:54:06 -0500
Subject: [Python-3000] Why lowercase?
In-Reply-To: <47623600.7080605@cheimes.de>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
Message-ID: <20071214115407.607383A40A4@sparrow.telecommunity.com>

At 08:51 AM 12/14/2007 +0100, Christian Heimes wrote:
>UserDict is a relict from the
>past and scheduled for removal.

Really?  Why?

>It's functionality is replaced by the
>subclass-able dict type and ABCs.

Er, no, its functionality *isn't* replaced by subclassable dict, 
since subclassable dict does stuff you can't override (e.g. copy() 
doesn't return a subclass instance).


From guido at python.org  Fri Dec 14 17:08:02 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 14 Dec 2007 08:08:02 -0800
Subject: [Python-3000] Why lowercase?
In-Reply-To: <20071214115407.607383A40A4@sparrow.telecommunity.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
Message-ID: <ca471dc20712140808q7b6f6ebdv108b29fc1d72d986@mail.gmail.com>

On Dec 14, 2007 3:54 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:51 AM 12/14/2007 +0100, Christian Heimes wrote:
> >UserDict is a relict from the
> >past and scheduled for removal.
>
> Really?  Why?

Yes. Or it should be rewritten as a tiny shim on top of
collections.MutableMapping, which has nearly all the functionality and
matches the dict type.

> >It's functionality is replaced by the
> >subclass-able dict type and ABCs.
>
> Er, no, its functionality *isn't* replaced by subclassable dict,
> since subclassable dict does stuff you can't override (e.g. copy()
> doesn't return a subclass instance).

Correct, Christian needs more practice channeling me. :-)

Regarding the OP's question about the lowercase names, this *is* in a
large part historic -- int, str, float and a few others were
*functions* before Python 2.2, like len, id etc. still are. We turned
int etc. into builtin types, added some more type names that didn't
have builtin names before (dict, list etc.), and in order to be
compatible the names remained lowercase.

The convention nowadays seems to be that built-in types are lower case
and user-defined types use CamelCase. I can live with it.

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

From facundobatista at gmail.com  Fri Dec 14 20:51:33 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 14 Dec 2007 16:51:33 -0300
Subject: [Python-3000] Call for Project Participation in Development Sprints
	at PyCon 2008
Message-ID: <e04bdf310712141151g1a71ada4g12f9bd769cb24e11@mail.gmail.com>

Python-related projects: join the PyCon Development Sprints!

The development sprints are a key part of PyCon, a chance for the
contributors to open-source projects to get together face-to-face for
up to four days of intensive learning and development.  Newbies sit at
the same table as the gurus, go out for lunch and dinner together, and
have a great time while advancing their project.  At PyCon 2007 in
Dallas we must have had 20 projects sprinting.

If your project would like to sprint at PyCon, now is the time to let
us know.  We need to collect the info and publish it, so participants
will have time to make plans.  We need to get the word out early,
because no matter what we do during the conference, most people who
haven't already decided to sprint won't be able to stay, because they
have a planes to catch and no hotel rooms.

In the past, many people have been reluctant to commit to sprinting.
Some may not know what sprinting is all about; others may think that
they're not "qualified" to sprint.  We want to change that perception.

* We want to help promote your sprint.  The PyCon website, the PyCon
 blog, the PyCon podcast, and press releases will be there for you.

* PyCon attendees will be asked to commit to sprints on the
 registration form, which will include a list of sprints with links
 to further info.

* We will be featuring a "How To Sprint" session on Sunday afternoon,
 followed by sprint-related tutorials, all for free.

* Some sponsors are helping out with the sprints as well.

There's also cost.  Although the sprinting itself is free, sprints
have associated time and hotel costs.  We can't do anything about the
time cost, but we may have some complimentary rooms and funding
available for sprinters.  We will have more to say on financial aid
later.

Those who want to propose a sprint should send the following
information to pycon-organizers at python.org:

* Project/sprint name
* Project URL
* The name and contact info (email & telephone) for the sprint
 leader(s) and other contributors who will attend the sprint
* Instructions for accessing the project's code repository and
 documentation (or a URL)
* Pointers to new contributor information (setup, etc.)
* Any special requirements (projector? whiteboard? flux capacitor?)

We will add this information to the PyCon website and set up a wiki
page for you (or we can link to yours).  Projects need a list of goals
(bugs to fix, features to add, docs to write, etc.), especially some
goals for beginners, to attract new sprinters.  The more detail you
put there, the more prepared your sprinters will be, and the more
results you'll get.

In 2007 there were sprints for Python, Jython, Zope, Django,
TurboGears, Python in Education, SchoolTool, Trac, Docutils, the
Python Job Board, PyCon-Tech, and other projects.  We would like to
see all these and more!

The sprints will run from Monday, March 17 through Thursday, March
20, 2008.  You can find more details here:
http://us.pycon.org/2008/sprints/.

Thank you very much, and happy coding!

Facundo Batista, PyCon 2008 Sprint Coordinator
David Goodger, PyCon 2008 Chair

From brett at python.org  Fri Dec 14 21:32:05 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 14 Dec 2007 12:32:05 -0800
Subject: [Python-3000] Call for Project Participation in Development
	Sprints at PyCon 2008
In-Reply-To: <e04bdf310712141151g1a71ada4g12f9bd769cb24e11@mail.gmail.com>
References: <e04bdf310712141151g1a71ada4g12f9bd769cb24e11@mail.gmail.com>
Message-ID: <bbaeab100712141232q301d3ab7u9effa8b9abaafa4a@mail.gmail.com>

On Dec 14, 2007 11:51 AM, Facundo Batista <facundobatista at gmail.com> wrote:
> Python-related projects: join the PyCon Development Sprints!
>
> The development sprints are a key part of PyCon, a chance for the
> contributors to open-source projects to get together face-to-face for
> up to four days of intensive learning and development.  Newbies sit at
> the same table as the gurus, go out for lunch and dinner together, and
> have a great time while advancing their project.  At PyCon 2007 in
> Dallas we must have had 20 projects sprinting.
>
> If your project would like to sprint at PyCon, now is the time to let
> us know.  We need to collect the info and publish it, so participants
> will have time to make plans.  We need to get the word out early,
> because no matter what we do during the conference, most people who
> haven't already decided to sprint won't be able to stay, because they
> have a planes to catch and no hotel rooms.
>

Just so people know, I have already been tapped to be the coach for
the core sprint again this year.  I have also been asked to give
Facundo some help (who needs to reply to my other email; nudge, nudge
=), so the core is definitely being taken care of.

-Brett

From lists at cheimes.de  Fri Dec 14 21:57:32 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 14 Dec 2007 21:57:32 +0100
Subject: [Python-3000] Why lowercase?
In-Reply-To: <20071214115407.607383A40A4@sparrow.telecommunity.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
Message-ID: <4762EE3C.1010700@cheimes.de>

Phillip J. Eby wrote:
> At 08:51 AM 12/14/2007 +0100, Christian Heimes wrote:
>> UserDict is a relict from the
>> past and scheduled for removal.
> 
> Really?  Why?

Because a Google Spreed Sheet says so. *jk*

> Er, no, its functionality *isn't* replaced by subclassable dict, 
> since subclassable dict does stuff you can't override (e.g. copy() 
> doesn't return a subclass instance).

Brett has started the stdlib reorg. In the past couple of days we have
created a list of modules to be renamed or removed. We have *not* made
any decision yet. The User* modules are just marked as to be
extinguished during the stdlib reorg.

I see your point. A few minutes ago I added another sheet that lists
modules to be replaced or rewritten.

Christian

From alexandre at peadrop.com  Fri Dec 14 23:22:00 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 14 Dec 2007 17:22:00 -0500
Subject: [Python-3000] Why lowercase?
In-Reply-To: <4762EE3C.1010700@cheimes.de>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
	<4762EE3C.1010700@cheimes.de>
Message-ID: <acd65fa20712141422y44ec8376p28e21ae450bd2e04@mail.gmail.com>

On Dec 14, 2007 3:57 PM, Christian Heimes <lists at cheimes.de> wrote:
> Brett has started the stdlib reorg. In the past couple of days we have
> created a list of modules to be renamed or removed. We have *not* made
> any decision yet. The User* modules are just marked as to be
> extinguished during the stdlib reorg.
>

Oh, that is my fault. I did mark User* modules for removal, but that
was certainly not to be taken as an "official statement". Remember
that the spreadsheet is only a tool for organizing ourselves. It's
PEP-3108 that will hold all the official decisions.

-- Alexandre

From greg.ewing at canterbury.ac.nz  Sat Dec 15 00:46:08 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 15 Dec 2007 12:46:08 +1300
Subject: [Python-3000] Why lowercase?
In-Reply-To: <20071214115407.607383A40A4@sparrow.telecommunity.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
Message-ID: <476315C0.1050308@canterbury.ac.nz>

Phillip J. Eby wrote:
> Er, no, its functionality *isn't* replaced by subclassable dict, 
> since subclassable dict does stuff you can't override (e.g. copy() 
> doesn't return a subclass instance).

But you could override copy() in your dict subclass.

--
Greg

From greg.ewing at canterbury.ac.nz  Sat Dec 15 01:00:51 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 15 Dec 2007 13:00:51 +1300
Subject: [Python-3000] Why lowercase?
In-Reply-To: <ca471dc20712140808q7b6f6ebdv108b29fc1d72d986@mail.gmail.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
	<ca471dc20712140808q7b6f6ebdv108b29fc1d72d986@mail.gmail.com>
Message-ID: <47631933.6070203@canterbury.ac.nz>

Guido van Rossum wrote:
> int, str, float and a few others were
> *functions* before Python 2.2, like len, id etc. still are. We turned
> int etc. into builtin types

I think this illustrates that any convention which assigns
different case to functions and classes can only ever be
a heuristic in Python and not a hard-and-fast rule, since any
class could become a factory function later or vice versa.

Although it's inconsistent, it somehow seems right that the
most fundamental things you use all the time should have
names that are easy on the eyes and fingers.

--
Greg

From pje at telecommunity.com  Sat Dec 15 01:05:35 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 14 Dec 2007 19:05:35 -0500
Subject: [Python-3000] Why lowercase?
In-Reply-To: <476315C0.1050308@canterbury.ac.nz>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
	<476315C0.1050308@canterbury.ac.nz>
Message-ID: <20071215000619.BBF413A40AC@sparrow.telecommunity.com>

At 12:46 PM 12/15/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > Er, no, its functionality *isn't* replaced by subclassable dict,
> > since subclassable dict does stuff you can't override (e.g. copy()
> > doesn't return a subclass instance).
>
>But you could override copy() in your dict subclass.

Or you could just use UserDict (or the DictMixin classes) and save 
yourself the trouble.

Now, if there are replacements that let you do the same stuff (e.g. 
delegate to a '.data' member), then great.  Otherwise, why should 
everybody duplicate the same functionality over again, when there's a 
nice stable implementation?

Or is the idea that these things should get spun off into PyPI 
packages, a la bsddb185?


From brett at python.org  Sat Dec 15 02:28:01 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 14 Dec 2007 17:28:01 -0800
Subject: [Python-3000] Why lowercase?
In-Reply-To: <20071215000619.BBF413A40AC@sparrow.telecommunity.com>
References: <37f76d50712132339i5b611e61sbf069b4aa963ebe2@mail.gmail.com>
	<47623600.7080605@cheimes.de>
	<20071214115407.607383A40A4@sparrow.telecommunity.com>
	<476315C0.1050308@canterbury.ac.nz>
	<20071215000619.BBF413A40AC@sparrow.telecommunity.com>
Message-ID: <bbaeab100712141728l5990143bl75f1a9e31417b497@mail.gmail.com>

On Dec 14, 2007 4:05 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:46 PM 12/15/2007 +1300, Greg Ewing wrote:
> >Phillip J. Eby wrote:
> > > Er, no, its functionality *isn't* replaced by subclassable dict,
> > > since subclassable dict does stuff you can't override (e.g. copy()
> > > doesn't return a subclass instance).
> >
> >But you could override copy() in your dict subclass.
>
> Or you could just use UserDict (or the DictMixin classes) and save
> yourself the trouble.
>
> Now, if there are replacements that let you do the same stuff (e.g.
> delegate to a '.data' member), then great.  Otherwise, why should
> everybody duplicate the same functionality over again, when there's a
> nice stable implementation?
>
> Or is the idea that these things should get spun off into PyPI
> packages, a la bsddb185?

As of right now the User* modules are only slated for a rename.  I can
probably stand a rewrite, but I am not planning to push for their
removal as at least the mixin classes have use still.

-Brett

From steven.bethard at gmail.com  Sun Dec 16 00:34:08 2007
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 15 Dec 2007 16:34:08 -0700
Subject: [Python-3000] Combined configparse + optparse (interest?)
In-Reply-To: <47596AE6.8050102@trueblade.com>
References: <fjbpcm$c7r$1@ger.gmane.org> <47596AE6.8050102@trueblade.com>
Message-ID: <d11dcfba0712151534j44a4a4d8m7a10850bd9df16ec@mail.gmail.com>

On Dec 7, 2007 8:46 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> Neal Becker wrote:
> > Right now we have 2 rather different stdlib modules for parsing options from
> > ini-style files and from command line.  I believe it would be desirable to
> > have one module that can handle both.  Is there interest in pursuing this
> > idea?
>
> I'd be interested.  I think rolling in the functionality of argparse to
> handle non-option arguments would also be good:
> http://argparse.python-hosting.com/

Yeah, I've had a request for this (and I think it's a great idea) but
I've been distracted by finishing up my Ph.D.  ;-)  I should have some
more time starting in January.  If anyone would like to help out, let
me know.

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 tjreedy at udel.edu  Thu Dec 20 23:33:30 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 20 Dec 2007 17:33:30 -0500
Subject: [Python-3000] List quiet? or gmane broken?
Message-ID: <fkeqjr$l9d$1@ger.gmane.org>

Has this list really had no posts for 6 days?
Or is the gmane bridge broken?

Terry




From guido at python.org  Fri Dec 21 00:49:56 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 20 Dec 2007 15:49:56 -0800
Subject: [Python-3000] List quiet? or gmane broken?
In-Reply-To: <fkeqjr$l9d$1@ger.gmane.org>
References: <fkeqjr$l9d$1@ger.gmane.org>
Message-ID: <ca471dc20712201549kb476252rdea3384dc70ee45d@mail.gmail.com>

Just quiet. Last post I've seen was "Combined configparse + optparse
(interest?)" on Dec 15.

On Dec 20, 2007 2:33 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Has this list really had no posts for 6 days?
> Or is the gmane bridge broken?

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

From hashcollision at gmail.com  Fri Dec 21 21:54:39 2007
From: hashcollision at gmail.com (hashcollision)
Date: Fri, 21 Dec 2007 15:54:39 -0500
Subject: [Python-3000] API changes?
Message-ID: <37f76d50712211254n5ce057caq85dfa42bd99fea75@mail.gmail.com>

I have a few questions.

1) Where can I suggest API changes?
2) Are there any plans to add more modules in python 3000 either in python
3.0 or later?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071221/5689ea36/attachment.htm 

From charles.merriam at gmail.com  Sat Dec 22 07:30:07 2007
From: charles.merriam at gmail.com (Charles Merriam)
Date: Fri, 21 Dec 2007 22:30:07 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
Message-ID: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>

Hello all,

My first post to the mailing list, so pardon if I open a can of worms.
I know everyone groans whenever a metaclass is mentioned.

I gave a talk last week that included Metaclasses.  From what I've
read, there seems to be only one use case for metaclasses:  go through
and play with the attributes when the class is created.

That is, the use cases are:
1.   Go through the attributes on creation, in order, and create some
new attribute entries that call my IDL, XML, object database, or other
mapper.    For example, use a metaclass that looks at all class data
attributes and adds a "save_as_XML" function that writes these
correctly.
2.  Go through the attributes on creation, and throw exceptions if
some attributes are not specified, or if other attributes are
specified.  For example, require that all my methods include
docstrings and that each class have a "project_home_URI' data member
of type string.
3.  Go through the attributes on creation.  Add some common functions
all classes from this metaclass must have.  For example, all these
classes get the same "print_license" function.
4.  Go through the attributes on creation.  Apply decorators to most
methods to enforce security, logging, lazy loading, or persistence
management.  For example, all public functions get decorated with the
"@require_admin_access" decorator.

Are there any other use cases?   So far, there seems to be a lot of
boiler plate code to get here.  PEP 3115 adds some extra non-intuitive
code for specifying an alternate container which could be anything,
but will always be an array instead of a dict.

If there are no other use cases, then the syntax and implementation
could be made much simpler.   The usual boilerplate code looks like
this:

class Midnight_Hack(type):
 def __new__(cls, name, bases, attributes):
   for a,v in attributes.items():
         # process attributes here....
   return type.__new__(cls, name, bases,attributes)

So, instead we could make a routine that gets called from the 'type'
class directly.  It can have handy convenience functions, and has can
have more understandable semantics when classes inherit from multiple
base classes that each use metaclasses.   Here's a proposed syntax
sample:

def print_license:
    print "This is mine, mine, mine!"

def process(mc):   #mc for "meta class info"
       # I could just get and set mc.attr_list, but let's use
convenience functions

       mc.require_attribute("IDL_Version")
       # Might throw a Missing_Metaclass_Requirement_Exception

       mc.add_attr"print_license", print_license)   # every class needs this
       mc.add_attr("swizzle",  Swizzle.make_func(mc.public_variable_list())
       mc.decorate_attr("swizzle", Swizzle.confirm_license_paid)

I call it like this:
@@super_swizzle
class Hourly_Employee(Employee, Contractor):
   IDL_Version = 3.2    # required by metaclass
   Name = ""  # a class attribute...
   SSN = ""
   ....

Unfortunately, this can't unroll gracefully, as it needs some execution
after partially compiling the class, but before it has been
fully finished.  The compilation pseudo-code:

    If there is an @@metaclass:
        remember the metaclass function ("superswizzle")
        attributes will go in a list, not a dict during class compilation
        compile up the class
        create a new Metaclass object with cls, bases, attrs_list
        call @@metaclass function
        take the (changed) Metaclass object, and call 'type' to make it.
        make sure the class remembers which metaclass function to make
on creation.
     else:
        do the usual.

The psudo-code for calling the superclass's @@metaclass is left as an exercise.


So this has the advantages:
+ Metaclass becomes far less boilerplate, error-prone, black magic.
+ Metaclass stops being a subclassing hack, which simplifies things.
+ __metaclass__ goes away.  It was a crufty syntax.
+ the odd syntax of PEP 3115 goes away, while still easy to see if a
    metaclass was used.
+ lots of future hacking on novel ways to use metaclasses
    now that they are easier.
+ Moving the metaclass specialness to a single function simplifies
    diamond inheritence from classes with multiple metaclasses.
- Some people will use metaclasses for stupid things.

This feels like a Python 3000 type of solution.  Still, it is really
late to party.  I would love to see use cases for which this solution
does not work.  Is this a matter of writing a PEP?, writing a sample
cpython patch?, learning to live without?


Charles Merriam

---
Refs:
The PEP
http://www.python.org/dev/peps/pep-3115/

David Mertz's Metaclass Tutorials
http://www.ibm.com/developerworks/linux/library/l-pymeta.html
http://www.ibm.com/developerworks/linux/library/l-pymeta2/
http://www.ibm.com/developerworks/linux/library/l-pymeta3.html
- A long overview of metaclasses, more than you might want to know.
- Very few uses for metaclasses

Charles Merriam's recent talk
http://charlesmerriam.com/talk

From brett at python.org  Sat Dec 22 07:35:36 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Dec 2007 22:35:36 -0800
Subject: [Python-3000] API changes?
In-Reply-To: <37f76d50712211254n5ce057caq85dfa42bd99fea75@mail.gmail.com>
References: <37f76d50712211254n5ce057caq85dfa42bd99fea75@mail.gmail.com>
Message-ID: <bbaeab100712212235u2d7b0746h41096f3e29b340f9@mail.gmail.com>

On Dec 21, 2007 12:54 PM, hashcollision <hashcollision at gmail.com> wrote:
> I have a few questions.
>
> 1) Where can I suggest API changes?

Here or the bug tracker; depends on the scope.

> 2) Are there any plans to add more modules in python 3000 either in python
> 3.0 or later?

None are definite at the moment, but there is nothing saying something
could go in before the beta is reached.

-Brett

From tanzer at swing.co.at  Sat Dec 22 13:57:01 2007
From: tanzer at swing.co.at (Christian Tanzer)
Date: Sat, 22 Dec 2007 13:57:01 +0100
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: Your message of "Fri, 21 Dec 2007 22:30:07 PST."
	<b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
Message-ID: <E1J63uX-0007uy-FN@swing.co.at>


"Charles Merriam" <charles.merriam at gmail.com> wrote:

> I gave a talk last week that included Metaclasses.  From what I've
> read, there seems to be only one use case for metaclasses:  go through
> and play with the attributes when the class is created.

A metaclass can define behavior for its classes. I'm using that quite
a bit.

-- 
Christian Tanzer                                    http://www.c-tanzer.at/


From pje at telecommunity.com  Sat Dec 22 15:05:54 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 22 Dec 2007 09:05:54 -0500
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
 Alternate syntax.
In-Reply-To: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.co
 m>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
Message-ID: <20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>

At 10:30 PM 12/21/2007 -0800, Charles Merriam wrote:
>Are there any other use cases?

Yes, several.  You haven't been reading the previous discussion 
threads, in which I've repeatedly posted other use cases for PEP 
3115, every time someone else who hasn't read the previous posting of 
those use cases, and tries to "simplify" the PEP.  Other people have 
posted a few as well.

You're also utterly ignoring metaclass runtime use cases in your 
proposal, in a way that suggests you don't really know what a 
metaclass *is*, even pre-PEP 3115.


>Unfortunately, this can't unroll gracefully, as it needs some execution
>after partially compiling the class, but before it has been
>fully finished.  The compilation pseudo-code:
>
>     If there is an @@metaclass:
>         remember the metaclass function ("superswizzle")
>         attributes will go in a list, not a dict during class compilation
>         compile up the class
>         create a new Metaclass object with cls, bases, attrs_list
>         call @@metaclass function
>         take the (changed) Metaclass object, and call 'type' to make it.
>         make sure the class remembers which metaclass function to make
>on creation.
>      else:
>         do the usual.

This description makes me think you don't understand how class 
creation works, either.  In particular, you keep using the phrase 
"compiling the class", but I don't think you know what that phrase means.


>The psudo-code for calling the superclass's @@metaclass is left as 
>an exercise.

What about multiple inheritance?  That doesn't seem like such a 
trivial exercise, and AFAICT, your proposal is more complex to 
implement than that of Python 2.x metaclasses.


>So this has the advantages:
>+ Metaclass becomes far less boilerplate, error-prone, black magic.
>+ Metaclass stops being a subclassing hack, which simplifies things.

And eliminates the ability to have a *meta* *class* in the 
process.  No thanks.  (Plus, you have moved the complexity from a 
well-understood and well-grounded-in-theory model to a handwaving 
"left as an exercise" non-proposal.)


>+ __metaclass__ goes away.  It was a crufty syntax.

And yet it was still better than your @@ proposal, and the keyword 
syntax of PEP 3115 is better still.


>+ lots of future hacking on novel ways to use metaclasses
>     now that they are easier.

Er, huh?  How in blue blazes is what you just described *easier* in 
any way, shape or form?  I can't tell through all the hand-waving in 
the semantics, since you didn't provide any real explanation of what 
your "metaclass info" object does, nor did you provide a definition 
of 'super_swizzle'.

Meanwhile, all of the functionality you implied would exist on the 
"mc" object, could easily be implemented as utility functions taking 
a class object in today's Python, and trivially invoked from a 
metaclass __init__, cleanly supporting multiple inheritance in the 
process (by standard super() calls).

Heck, if you don't like defining new metaclasses, the DecoratorTools 
package includes a class that allows its subclasses to define a 
'__class_init__' method that is called in lieu of a metaclass 
__init__, allowing every class to almost be its own metaclass (in the 
limited sense of getting to define certain nominally-metaclassy 
methods like new, init, and call).

I use this class in a lot of libraries because it eliminates the need 
to define custom metaclasses in all but the most demanding metaclass 
use cases, and thus avoids most of the problems involved in mixing 
metaclasses via multiple inheritance.  It lets you define a base 
class that does your "super_swizzle" magic, and then simply inherit 
from it to use it.

In any case, my point is that AFAICT here, there isn't anything 
you've proposed here that can't already be done within the status 
quo, without implementing a new way of "compiling the class" (which 
doesn't mean what you seem to think it means).


>+ Moving the metaclass specialness to a single function simplifies
>     diamond inheritence from classes with multiple metaclasses.

Uh, no, it doesn't.


>I would love to see use cases for which this solution
>does not work.

How about all of the use cases that actually need a *metaclass*, 
rather than merely inherited class decoration?



From hashcollision at gmail.com  Sat Dec 22 21:15:43 2007
From: hashcollision at gmail.com (hashcollision)
Date: Sat, 22 Dec 2007 15:15:43 -0500
Subject: [Python-3000] XOR and NOT operator syntax
Message-ID: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>

Currently,
True or False
works as expected, but
True xor False
is invalid. I don't see a reason why and, or, not are valid python keywords
but xor is not. Can this be added in python 3.0 for completeness?

Also,
True & False, True | False, True ^ Fals, True != False
works but
!True, !False
dosn't. Again, IMHO this is inconsistent and should be fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071222/1270cee3/attachment.htm 

From phd at phd.pp.ru  Sat Dec 22 21:31:05 2007
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Sat, 22 Dec 2007 23:31:05 +0300
Subject: [Python-3000] XOR and NOT operator syntax
In-Reply-To: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
References: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
Message-ID: <20071222203105.GA1798@phd.pp.ru>

On Sat, Dec 22, 2007 at 03:15:43PM -0500, hashcollision wrote:
> Currently,
> True or False
> works as expected, but
> True xor False
> is invalid. I don't see a reason why and, or, not are valid python keywords
> but xor is not. Can this be added in python 3.0 for completeness?
> 
> Also,
> True & False, True | False, True ^ Fals, True != False
> works but
> !True, !False
> dosn't. Again, IMHO this is inconsistent and should be fixed.

   "There should be one-- and preferably only one --obvious way to do it."
- from "The Zen of Python, by Tim Peters".

   There are bitwise operations and boolean operations in Python, and for an
every operation there is one and only one keyword or an operator.

   '&', '|', '^' are bitwise operators. "and" and "or" are short-circuiting
boolean operators. They are not equivalent, are not interchangeable.
   "not" is an unary boolean operator. Bitwise "not" is spelled '~'. Again,
they are not interchangeable.
   There is no need to have a bitwise "not" as '~' is already exists. And
there is no way to have a boolean short-circuiting "xor" - hence there is
only bitwise '^' and there is no corresponding keyword.

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  Sun Dec 23 04:13:06 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 23 Dec 2007 13:13:06 +1000
Subject: [Python-3000] XOR and NOT operator syntax
In-Reply-To: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
References: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
Message-ID: <476DD242.9050606@gmail.com>

hashcollision wrote:
> Currently,
> True or False
> works as expected, but
> True xor False
> is invalid. I don't see a reason why and, or, not are valid python 
> keywords but xor is not. Can this be added in python 3.0 for completeness?

XOR can't be shortcircuited, so it doesn't gain from having a special 
keyword the way AND and OR do. If you really want a logical XOR, 
'bool(var1) ^ bool(var2)' will do the trick, or you can just write your 
own xor function. In my experience, logical XOR is pretty rare anyway 
(while bitwise XOR is common).

> Also,
> True & False, True | False, True ^ Fals, True != False
> works but
> !True, !False
> dosn't. Again, IMHO this is inconsistent and should be fixed.

Why? As Oleg already stated, if you want a bitwise negation, use '~' 
(giving -2 and -1 respectively), if you want logical negation, use 'not' 
(giving False and True respectively).

Cheers,
Nick.

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

From charles.merriam at gmail.com  Sun Dec 23 05:04:48 2007
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sat, 22 Dec 2007 20:04:48 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
Message-ID: <b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>

>
> Yes, several.  You haven't been reading the previous discussion
> threads, in which I've repeatedly posted other use cases for PEP
> 3115, every time someone else who hasn't read the previous posting of
> those use cases, and tries to "simplify" the PEP.  Other people have
> posted a few as well.

Great!  Point to them or explain them.  I read back two months before
posting, but you
must referencing discussions six months old?  fourteen months old?

>
> You're also utterly ignoring metaclass runtime use cases in your
> proposal, in a way that suggests you don't really know what a
> metaclass *is*, even pre-PEP 3115.

?


>
>
> >Unfortunately, this can't unroll gracefully, as it needs some execution
> >after partially compiling the class, but before it has been
> >fully finished.  The compilation pseudo-code:
> >
> >     If there is an @@metaclass:
> >         remember the metaclass function ("superswizzle")
> >         attributes will go in a list, not a dict during class compilation
> >         compile up the class
> >         create a new Metaclass object with cls, bases, attrs_list
> >         call @@metaclass function
> >         take the (changed) Metaclass object, and call 'type' to make it.
> >         make sure the class remembers which metaclass function to make
> >on creation.
> >      else:
> >         do the usual.
>
> This description makes me think you don't understand how class
> creation works, either.  In particular, you keep using the phrase
> "compiling the class", but I don't think you know what that phrase means.
>

Fill me in.  I view it as classes executing in their own namespace, then calling
type._init__ to transform the defined function signatures to take 'self'
arguments and add the class name to its enclosing namespace.  If you have
a point, make it.  Don't just name call.

>
> >The psudo-code for calling the superclass's @@metaclass is left as
> >an exercise.
>
> What about multiple inheritance?  That doesn't seem like such a
> trivial exercise, and AFAICT, your proposal is more complex to
> implement than that of Python 2.x metaclasses.
>
Actually, it should be considerably simpler as the problem can devolve
into an order list of function calls.  Specifically, I didn't want to write
a bunch more in a first post until the first 'use cases' question was
handled.

>
> >So this has the advantages:
> >+ Metaclass becomes far less boilerplate, error-prone, black magic.
> >+ Metaclass stops being a subclassing hack, which simplifies things.
>
> And eliminates the ability to have a *meta* *class* in the
> process.  No thanks.  (Plus, you have moved the complexity from a
> well-understood and well-grounded-in-theory model to a handwaving
> "left as an exercise" non-proposal.)

What?  English please.

>
>
> >+ __metaclass__ goes away.  It was a crufty syntax.
>
> And yet it was still better than your @@ proposal, and the keyword
> syntax of PEP 3115 is better still.
>
>
> >+ lots of future hacking on novel ways to use metaclasses
> >     now that they are easier.
>
> Er, huh?  How in blue blazes is what you just described *easier* in
> any way, shape or form?  I can't tell through all the hand-waving in
> the semantics, since you didn't provide any real explanation of what
> your "metaclass info" object does, nor did you provide a definition
> of 'super_swizzle'.
>

OK, I didn't explain any 'super_swizzle' outside of the use case cited.
Assume I need to take an ordered list of class attributes that are not
functions for use in either on old IDL interface, OR mapper, or whatever.
I want these items in the declared order, and want to mention them once.
There wasn't handwaving, just using sample code of spec. language.

>From the comments, you should see that the metaclass info is an object
created and passed which provides the same basic baseclass and attrs
list that go to type.__init__().



> Meanwhile, all of the functionality you implied would exist on the
> "mc" object, could easily be implemented as utility functions taking
> a class object in today's Python, and trivially invoked from a
> metaclass __init__, cleanly supporting multiple inheritance in the
> process (by standard super() calls).

Actually, I was looking at using a single type subclass to provide this,
and would do so if there we no way to change in syntax.   A hack in 2.6,
or simply decorating __init__ per Mertz.  If syntax is allowed
to change, I would prefer beautiful rather than ugly.
>
> Heck, if you don't like defining new metaclasses, the DecoratorTools
> package includes a class that allows its subclasses to define a
> '__class_init__' method that is called in lieu of a metaclass
> __init__, allowing every class to almost be its own metaclass (in the
> limited sense of getting to define certain nominally-metaclassy
> methods like new, init, and call).

Haven't delved into this.  DecoratorTools looks like to a tool you or your
group wrote to hack around lack of decorators.

>
> I use this class in a lot of libraries because it eliminates the need
> to define custom metaclasses in all but the most demanding metaclass
> use cases, and thus avoids most of the problems involved in mixing
> metaclasses via multiple inheritance.  It lets you define a base
> class that does your "super_swizzle" magic, and then simply inherit
> from it to use it.
>
Annoyingly, the swizzle is a choice that needs an array instead of a dict.
Also, the division is not class or mix-in based; I want to alter behavior of the
class at a particualr point creation.

> In any case, my point is that AFAICT here, there isn't anything
> you've proposed here that can't already be done within the status
> quo, without implementing a new way of "compiling the class" (which
> doesn't mean what you seem to think it means).
>
>
> >+ Moving the metaclass specialness to a single function simplifies
> >     diamond inheritence from classes with multiple metaclasses.
>
> Uh, no, it doesn't.
>
>
> >I would love to see use cases for which this solution
> >does not work.
>
> How about all of the use cases that actually need a *metaclass*,
> rather than merely inherited class decoration?
>
>
>

So, provide the use cases you mention, read more carefully.

I can see why contributing to Python is more chore than joy.

Charles

From charles.merriam at gmail.com  Sun Dec 23 05:06:42 2007
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sat, 22 Dec 2007 20:06:42 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <E1J63uX-0007uy-FN@swing.co.at>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<E1J63uX-0007uy-FN@swing.co.at>
Message-ID: <b8c6f6c40712222006vb22d234hf1a04e78006766c5@mail.gmail.com>

Could you provide some more information?   One can define behavior as
simply as wrapping an indirection around each method of a class.   I'd welcome
pointers to the additional cases.

Thank you,

Charles


On Dec 22, 2007 4:57 AM, Christian Tanzer <tanzer at swing.co.at> wrote:
>
> "Charles Merriam" <charles.merriam at gmail.com> wrote:
>
> > I gave a talk last week that included Metaclasses.  From what I've
> > read, there seems to be only one use case for metaclasses:  go through
> > and play with the attributes when the class is created.
>
> A metaclass can define behavior for its classes. I'm using that quite
> a bit.
>
> --
> Christian Tanzer                                    http://www.c-tanzer.at/
>
>

From pje at telecommunity.com  Sun Dec 23 06:08:38 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 23 Dec 2007 00:08:38 -0500
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
 Alternate syntax.
In-Reply-To: <b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.co
 m>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
Message-ID: <20071223050830.DBD933A408B@sparrow.telecommunity.com>

At 08:04 PM 12/22/2007 -0800, Charles Merriam wrote:
> >
> > Yes, several.  You haven't been reading the previous discussion
> > threads, in which I've repeatedly posted other use cases for PEP
> > 3115, every time someone else who hasn't read the previous posting of
> > those use cases, and tries to "simplify" the PEP.  Other people have
> > posted a few as well.
>
>Great!  Point to them or explain them.  I read back two months before
>posting, but you
>must referencing discussions six months old?  fourteen months old?

There's a mailing list archive you can search for discussion of PEP 
3115.  Beyond that, the PEP itself includes some of those use cases - 
see paragraph six of the "Rationale", for example.

It would be best if you checked the PEP rationale before asking for 
alternate use cases, or at least indicate why you think the use cases 
listed in the PEP itself are invalid, or ask a question specifically 
about them.  However your rough definition of your perception of the 
use cases indicates you've largely missed the point of what a 
metaclass is, does, and is for, so I've attempted a further 
explanation later in this email.


> > This description makes me think you don't understand how class
> > creation works, either.  In particular, you keep using the phrase
> > "compiling the class", but I don't think you know what that phrase means.
> >
>
>Fill me in.  I view it as classes executing in their own namespace, 
>then calling
>type._init__ to transform the defined function signatures to take 'self'
>arguments and add the class name to its enclosing namespace.  If you have
>a point, make it.  Don't just name call.

Er, my point was that your proposal is vague and uses confusing 
terminology.  "Compiling" is the translation of the class statement 
to bytecode -- not the execution of the class suite.  If you mean 
execution of the class suite, say so.


> > >The psudo-code for calling the superclass's @@metaclass is left as
> > >an exercise.
> >
> > What about multiple inheritance?  That doesn't seem like such a
> > trivial exercise, and AFAICT, your proposal is more complex to
> > implement than that of Python 2.x metaclasses.
> >
>Actually, it should be considerably simpler as the problem can devolve
>into an order list of function calls.  Specifically, I didn't want to write
>a bunch more in a first post until the first 'use cases' question was
>handled.

It was handled by the PEP before you posted.  Meanwhile, your 
statement that it's simpler isn't currently backed up by any 
specification of your algorithm.


> > >+ lots of future hacking on novel ways to use metaclasses
> > >     now that they are easier.
> >
> > Er, huh?  How in blue blazes is what you just described *easier* in
> > any way, shape or form?  I can't tell through all the hand-waving in
> > the semantics, since you didn't provide any real explanation of what
> > your "metaclass info" object does, nor did you provide a definition
> > of 'super_swizzle'.
> >
>
>OK, I didn't explain any 'super_swizzle' outside of the use case cited.

You gave an example using "@@super_swizzle", but which never defined 
what 'super_swizzle' consists of.  How are we to guess what its 
meaning is?  (Off hand, I would guess that the function you called 
'process' was actually supposed to be named 'super_swizzle', but 
that's far from a slam dunk, given the general vagueness of the proposal.)


>Assume I need to take an ordered list of class attributes that are not
>functions for use in either on old IDL interface, OR mapper, or whatever.
>I want these items in the declared order, and want to mention them once.
>There wasn't handwaving, just using sample code of spec. language.

You handwaved inheritance -- you handwaved how this metaclass info is 
created, you handwaved "compiling"...  there is very little that 
isn't handwaving in your proposal.  It may seem otherwise to you, if 
you do in fact have some mental model that includes all the details 
your written proposal left out, but if that is the case you have a 
*lot* more writing to do to make it not appear as handwaving to 
anyone who might try to actually *implement* the proposal.


> From the comments, you should see that the metaclass info is an object
>created and passed which provides the same basic baseclass and attrs
>list that go to type.__init__().

Yes, I got that part, and I can infer several other things from your 
sketch.  My complaints are with the things you didn't list, or which 
you did list but which have significant drawbacks (e.g. @@syntax, 
lack of actual metaclass capabilities).


>Haven't delved into this.  DecoratorTools looks like to a tool you or your
>group wrote to hack around lack of decorators.

Actually, it's just a collection of tools having to do with 
decoration, as the name implies, although originally it was just 
class decorators and function decorator support for Python 2.3.


>Annoyingly, the swizzle is a choice that needs an array instead of a dict.
>Also, the division is not class or mix-in based; I want to alter 
>behavior of the
>class at a particualr point creation.

And PEP 3115 doesn't let you do this?


>So, provide the use cases you mention, read more carefully.

My point is that your proposal appears to be ignoring what 
metaclasses are for in the first place: to define the runtime 
behavior of the *class objects* (as opposed to the instances).  It 
didn't mention anything about how one would have an actual metaclass, 
as opposed to inheritable decoration and customized class 
creation.  How would you customize the actual *type* of the classes?

Your message to Christian Tanzer indicates that you are still not 
getting this concept -- it's the behavior of the *class*, not the 
behavior of the class' instances.  For example, a metaclass can 
create a property that the class accesses, e.g.:

    class mymeta(type):
       p = property(lambda self: 42)

    class cls: __metaclass__=mymeta

    assert cls.p==42                 # class has it
    assert not hasattr(cls(), 'p')   # instances don't

Another example might be a metaclass that keeps a dictionary of all 
instances of a particular class, and defines __getitem__ so that you 
can do SomeClass[someKey] to look up a the specified instance of that class.

These are the sorts of use cases that your proposal appears 
completely oblivious to (entirely independent of PEP 3115, which 
merely refines the existing metaclass model a bit).


>I can see why contributing to Python is more chore than joy.

Yes, it is indeed a chore to repeat the same things over and over 
when people don't:

* read the relevant PEP,
* do a Google search of the archives for relevant discussions,
* understand even the most basic ideas about the constructs they're 
proposing to modify, or
* use words that reflect what they mean (e.g. not saying "compiling" 
when they mean "executing").

Until eventually, somebody snaps and gets all "argument clinic" when 
the same thing gets asked enough times, even though the answers are 
already in the PEP.  :)

That having been said... happy holidays, and sorry for the rough 
welcome.  I totally understand now why Guido gets gruff sometimes 
when somebody brings up the same darn FAQ or previously-rejected 
proposal for the Nth time.


From tomasnovella at gmail.com  Sun Dec 23 14:39:49 2007
From: tomasnovella at gmail.com (Tomy novella)
Date: Sun, 23 Dec 2007 14:39:49 +0100
Subject: [Python-3000] python3000 C and C++ style coments
Message-ID: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>

Hi,
I think it would be great if  C style(/* */) and C++ style(//)
comments appeared in python3000.

At least I need C style comments and I think they would be useful for
everybody because for example when I am "debugging" program(commenting
code which doesnt work); much easier to comment a block of lines by
tags /* and */ than adding # on the start of each line...


PS: Sorry for some grammar mistakes, if there are any ;-)
-- 
Tom at sQo
tomasnovella at gmail.com

From aahz at pythoncraft.com  Sun Dec 23 16:40:43 2007
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 23 Dec 2007 07:40:43 -0800
Subject: [Python-3000] python3000 C and C++ style coments
In-Reply-To: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
References: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
Message-ID: <20071223154042.GA18570@panix.com>

On Sun, Dec 23, 2007, Tomy novella wrote:
>
> I think it would be great if  C style(/* */) and C++ style(//)
> comments appeared in python3000.

This kind of discussion would be better on python-ideas.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith

From martin at v.loewis.de  Mon Dec 24 00:13:50 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Dec 2007 00:13:50 +0100
Subject: [Python-3000] XOR and NOT operator syntax
In-Reply-To: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
References: <37f76d50712221215t5cc734dl4491cb7241efc52f@mail.gmail.com>
Message-ID: <476EEBAE.4020004@v.loewis.de>

> I don't see a reason why and, or, not are valid python
> keywords but xor is not. Can this be added in python 3.0 for completeness?

It's already there; it's spelled "!=".

Regards,
Martin

From martin at v.loewis.de  Mon Dec 24 00:16:00 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 24 Dec 2007 00:16:00 +0100
Subject: [Python-3000] python3000 C and C++ style coments
In-Reply-To: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
References: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
Message-ID: <476EEC30.7030707@v.loewis.de>

> At least I need C style comments

If you repost to python-ideas (as Aahz suggested), don't
forget to explain why you *need* such comments.

Python is Turing-complete even without comments at all,
so it is not obvious that anybody could ever need a specific
spelling of comments. What problem are you trying to solve
that could not be solved without C style comments?

Regards,
Martin

From rbonvall at gmail.com  Mon Dec 24 05:10:08 2007
From: rbonvall at gmail.com (Roberto Bonvallet)
Date: Sun, 23 Dec 2007 22:10:08 -0600
Subject: [Python-3000] python3000 C and C++ style coments
In-Reply-To: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
References: <46e1f0de0712230539k2cb2421dgb86a0d5df38a67f3@mail.gmail.com>
Message-ID: <1908cb6b0712232010v36bd9d9bid84ad07c894f479f@mail.gmail.com>

2007/12/23, Tomy novella <tomasnovella at gmail.com>:
> I think it would be great if  C style(/* */) and C++ style(//)
> comments appeared in python3000.

In order to comment block of lines, you can enclose the code between a
pair of triple quotes.  // already has a meaning: it is the integer
division operator.
-- 
Roberto Bonvallet

From alexandre at peadrop.com  Wed Dec 26 22:24:57 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 26 Dec 2007 16:24:57 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with their
	optimized C version?
Message-ID: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>

I started to play again with the _bytesio and _stringio modules I
created, during last summer. Right now, I am mostly porting my changes
to the current trunk. If all goes well, the modules should be ready to
merged in the trunk by this week. (question: How should this be done?
Should I just bundle a set of patches and put on the tracker?)

However, I found a little problem which I am not sure how to fix
properly. Early during the interpreter initialization process, the
_bytesio and _stringio modules seems to be unavailable for some
unknown reason. And since io.py is imported before the modules become
available, this causes io.py to always use the Python version of
BytesIO and StringIO. So my question is, how should I override
io.BytesIO and io.StringIO with their optimized C version? My first
thought is to override the module in site.py, but I am not sure yet if
this the right thing to do.

Cheers and happy holidays,
-- Alexandre

From lists at cheimes.de  Wed Dec 26 22:50:03 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 26 Dec 2007 22:50:03 +0100
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
Message-ID: <4772CC8B.2000307@cheimes.de>

Alexandre Vassalotti wrote:
> I started to play again with the _bytesio and _stringio modules I
> created, during last summer. Right now, I am mostly porting my changes
> to the current trunk. If all goes well, the modules should be ready to
> merged in the trunk by this week. (question: How should this be done?
> Should I just bundle a set of patches and put on the tracker?)

Merry Christmas Alex!

You could also create a branch. I find a branch more convenient for
large changes like your io optimization. But I'm only a junior core
developer and the seniors or your dictator might think different. ;)

> However, I found a little problem which I am not sure how to fix
> properly. Early during the interpreter initialization process, the
> _bytesio and _stringio modules seems to be unavailable for some
> unknown reason. And since io.py is imported before the modules become
> available, this causes io.py to always use the Python version of
> BytesIO and StringIO. So my question is, how should I override
> io.BytesIO and io.StringIO with their optimized C version? My first
> thought is to override the module in site.py, but I am not sure yet if
> this the right thing to do.

How did you register the optimized versions? Did you add them to
_PyImport_Inittab in Modules/config.c? Modules in _PyImport_Inittab are
available before the io module is loaded.

Christian

From alexandre at peadrop.com  Wed Dec 26 23:28:36 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 26 Dec 2007 17:28:36 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <4772CC8B.2000307@cheimes.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
Message-ID: <acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>

On Dec 26, 2007 4:50 PM, Christian Heimes <lists at cheimes.de> wrote:
> Alexandre Vassalotti wrote:
> > I started to play again with the _bytesio and _stringio modules I
> > created, during last summer. Right now, I am mostly porting my changes
> > to the current trunk. If all goes well, the modules should be ready to
> > merged in the trunk by this week. (question: How should this be done?
> > Should I just bundle a set of patches and put on the tracker?)
>
> Merry Christmas Alex!
>

Thanks Christian, merry Christmas to you too!

> You could also create a branch. I find a branch more convenient for
> large changes like your io optimization. But I'm only a junior core
> developer and the seniors or your dictator might think different. ;)
>

Well, I been working on branches since the beginning. Although, I now
use Mercurial (which is lovely IMHO) to keep my changes (url:
http://peadrop.com/alex-py3k/).

> > However, I found a little problem which I am not sure how to fix
> > properly. Early during the interpreter initialization process, the
> > _bytesio and _stringio modules seems to be unavailable for some
> > unknown reason. And since io.py is imported before the modules become
> > available, this causes io.py to always use the Python version of
> > BytesIO and StringIO. So my question is, how should I override
> > io.BytesIO and io.StringIO with their optimized C version? My first
> > thought is to override the module in site.py, but I am not sure yet if
> > this the right thing to do.
>
> How did you register the optimized versions? Did you add them to
> _PyImport_Inittab in Modules/config.c? Modules in _PyImport_Inittab are
> available before the io module is loaded.
>

How would that works? The modules in Module/config.c need to linked to
the main binary, no?

-- Alexandre

From lists at cheimes.de  Wed Dec 26 23:40:21 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 26 Dec 2007 23:40:21 +0100
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
Message-ID: <4772D855.6010108@cheimes.de>

Alexandre Vassalotti wrote:
> Well, I been working on branches since the beginning. Although, I now
> use Mercurial (which is lovely IMHO) to keep my changes (url:
> http://peadrop.com/alex-py3k/).

Someday I need to play with Hg. It looks interesting and I've heard only
good about it.

> How would that works? The modules in Module/config.c need to linked to
> the main binary, no?

Correct! Do you want to build shared library extensions?

Your problem is related to http://bugs.python.org/issue586680. It could
be fixed in two ways. Either we move initstdio() after initsite()
(Python/pythonrun.c) or we add the ./build/lib.<platform>-<version> to
sys.path before we initialize the standard streams.

Christian

From skip at pobox.com  Wed Dec 26 23:57:50 2007
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 26 Dec 2007 16:57:50 -0600
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
Message-ID: <18290.56430.842138.886692@montanaro.dyndns.org>

>>>>> "Alexaandre" == Alexandre Vassalotti <alexandre at peadrop.com> writes:

    >> How did you register the optimized versions? Did you add them to
    >> _PyImport_Inittab in Modules/config.c? Modules in _PyImport_Inittab
    >> are available before the io module is loaded.

    Alexaandre> How would that works? The modules in Module/config.c need to
    Alexaandre> linked to the main binary, no?

Assuming they aren't huge I don't see any real problem linking them into the
interpreter's binary image.  A few other modules are handled that way (sys,
marshal, etc).

Skip


From lists at cheimes.de  Thu Dec 27 00:16:16 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 27 Dec 2007 00:16:16 +0100
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <18290.56430.842138.886692@montanaro.dyndns.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<18290.56430.842138.886692@montanaro.dyndns.org>
Message-ID: <4772E0C0.30000@cheimes.de>

skip at pobox.com wrote:
> Assuming they aren't huge I don't see any real problem linking them into the
> interpreter's binary image.  A few other modules are handled that way (sys,
> marshal, etc).

Both modules look small to me. They are just about 18k of C code each
and they contain lots of comments, too.

_stringio.c and _bytesio.c:
http://peadrop.com/alex-py3k/?file/96d2f18e1b0a/Modules/

Christian

From brett at python.org  Thu Dec 27 02:20:09 2007
From: brett at python.org (Brett Cannon)
Date: Wed, 26 Dec 2007 17:20:09 -0800
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <4772D855.6010108@cheimes.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
Message-ID: <bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>

On Dec 26, 2007 2:40 PM, Christian Heimes <lists at cheimes.de> wrote:
> Alexandre Vassalotti wrote:
> > Well, I been working on branches since the beginning. Although, I now
> > use Mercurial (which is lovely IMHO) to keep my changes (url:
> > http://peadrop.com/alex-py3k/).
>
> Someday I need to play with Hg. It looks interesting and I've heard only
> good about it.
>

It is nice.  Once Mercurial hits version 1.0 I am going to look at
whether it is reasonable to move Python to hg or bzr to make it easier
for people to do development on their own machines with local checkins
instead of forcing people who can't create a branch to create their
own VCS solution when doing offline work.

> > How would that works? The modules in Module/config.c need to linked to
> > the main binary, no?
>
> Correct! Do you want to build shared library extensions?
>
> Your problem is related to http://bugs.python.org/issue586680. It could
> be fixed in two ways. Either we move initstdio() after initsite()
> (Python/pythonrun.c) or we add the ./build/lib.<platform>-<version> to
> sys.path before we initialize the standard streams.

I would like to see the former option work.  Keeps build dependencies
down to a minimum.  Otherwise the issue Christian references should be
re-evaluated.  But I personally would rather not see more stuff be
built into Python, especially when it is optional in terms of Python's
execution needs.

-Brett

From stephen at xemacs.org  Thu Dec 27 06:34:00 2007
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 27 Dec 2007 14:34:00 +0900
Subject: [Python-3000] [OT] Mercurial [was: How to override io.BytesIO ...]
In-Reply-To: <bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
Message-ID: <87y7bgvgzb.fsf@uwakimon.sk.tsukuba.ac.jp>

Brett Cannon writes:

 > It is nice.  Once Mercurial hits version 1.0 I am going to look at
 > whether it is reasonable to move Python to hg or bzr to make it easier
 > for people to do development on their own machines with local checkins
 > instead of forcing people who can't create a branch to create their
 > own VCS solution when doing offline work.

My project just switched to Mercurial and the frequent merges are
driving me nuts.

Mercurial *is* nice because you can just do what comes naturally,
commit your own code when it makes sense to you, pull from upstream
when you think of it, and Mercurial will automatically make a branch
(but Mercurial calls it a "new head", Mercurial "branches" are either
something slightly heavier weight or a whole new repo).  And, it won't
let you push without complaining if you would create a new head in a
remote repository.

The downside is that the usual way of resolving the "Mercurial won't
let me push" situation is to do a merge, and that merge will get
committed to the main repo as well.  If you've got an automated commit
notifier, you can easily get hundreds or thousands of lines of useless
diffs this way.  We're thinking about just filtering those in the
commit notifier, but haven't yet decided that it's harmless to ignore
them.

This may be a local problem, but you may want to think about workflow
to avoid this kind of thing.


From alexandre at peadrop.com  Thu Dec 27 08:43:27 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 27 Dec 2007 02:43:27 -0500
Subject: [Python-3000] Weird truncate() behavior.
Message-ID: <acd65fa20712262343x29b46e42l32a7e52b4238915f@mail.gmail.com>

I have been working on lately on a small semantic to the truncate()
method of file objects -- i.e., make file.truncate(pos) imply a seek
to the given argument. I thought I had it all working, but I found out
that one test was failing -- testTruncateOnWindows in test_file. Tried
to fix it by myself, but I failed miserably. So, I  am thinking maybe
someone, with a fresh look on the problem, could help me.

By applying the following (simplified) patch:


--- Modules/_fileio.c   (revision 59594)
+++ Modules/_fileio.c   (working copy)
@@ -635,7 +635,8 @@
                   return NULL;
         }
         else {
-               Py_INCREF(posobj);
+               /* Move to the position to be truncated. */
+               posobj = portable_lseek(fd, posobj, 0);
         }

 #if !defined(HAVE_LARGEFILE_SUPPORT)


I get the desired truncate() behavior. However, this causes truncate()
to fail in a weird but predictable manner, as shown by the following
example:

f = open("@test","wb")
f.write(b"1234567890")
f.close()
f = open("@test","rb+")
f.read(4)
f.truncate(4)
print(f.tell())  # should print 4, but print -2 instead (?!)
f.seek(0, 1)     # this shouldn't change the file position
print(f.tell())  # print 4 (?!)

It is worthy to note, that calling write(), while tell() returns -2,
raises the following exception:

>>> f.write(b"hello")
Traceback (most recent call last):
  ...
IOError: [Errno 22] Invalid argument

The thing that I find really weird is that the example translate to
the correct (except for the last write() call) following library
function calls:

f.truncate(4):
  lseek64(3, 4, 0, 0, 0xb7da9814)                  = 4
  ftruncate64(3, 4, 0, 0x80aa6c6, 0xb7da9814)      = 0
print(f.tell()):
  lseek64(3, 0, 0, 1, 0x82ea99c)                   = 4
  write(1, "-2\n", 3)                              = 3

[The original output of ltrace was much larger; I just show the bare minimum]

There is only three things that comes to my mind that could explain
this weird behavior (in order of likeliness):
  1. My code is utter nonsense.
  2. I am relying on some undefined behavior.
  3. There is a bug in the C library.

Thanks,
-- Alexandre

From barry at python.org  Thu Dec 27 17:38:02 2007
From: barry at python.org (Barry Warsaw)
Date: Thu, 27 Dec 2007 11:38:02 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
Message-ID: <2466AA49-7057-4A75-B0CC-96BC28888257@python.org>

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

On Dec 26, 2007, at 8:20 PM, Brett Cannon wrote:

> It is nice.  Once Mercurial hits version 1.0 I am going to look at
> whether it is reasonable to move Python to hg or bzr to make it easier
> for people to do development on their own machines with local checkins
> instead of forcing people who can't create a branch to create their
> own VCS solution when doing offline work.

You guys know I'm not an unbiased observer, but I'll just point out  
that Bazaar 1.0 was released on 14-Dec.

Having used it daily for the past year on a very large and complex  
project, with dozens of developers and and 10s of branches/merges per  
week I can definitely say that Bazaar is ready for prime time.  It's  
one of those rare tools that stays out of the way and just does the  
right thing almost all the time.  I also use it on all my smaller non- 
work related projects now too.  I think Bazaar would serve the Python  
project well.

http://bazaar-vcs.org

- -Barry

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

iQCVAwUBR3PU7HEjvBPtnXfVAQLtMAQAhmRYKr/y8XFXKqh5LWyygErxvldqfXYz
r2dOV5EhEjJUrFU2T6//r8emAJ1YiYVaLGt3DRXBrv9Q2/BCzteNgiEWXz3oW1f9
eXK73uWpeR/Jo1YL870nGccRXbqQ2x9QvIUezcWyD1Lpc+k7+XxbZkkilMB+uJex
HXmggC976/k=
=tFPc
-----END PGP SIGNATURE-----

From mnordhoff at mattnordhoff.com  Fri Dec 28 08:06:51 2007
From: mnordhoff at mattnordhoff.com (Matt Nordhoff)
Date: Fri, 28 Dec 2007 02:06:51 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
Message-ID: <4774A08B.2090902@mattnordhoff.com>

Brett Cannon wrote:
> On Dec 26, 2007 2:40 PM, Christian Heimes <lists at cheimes.de> wrote:
>> Alexandre Vassalotti wrote:
>>> Well, I been working on branches since the beginning. Although, I now
>>> use Mercurial (which is lovely IMHO) to keep my changes (url:
>>> http://peadrop.com/alex-py3k/).
>> Someday I need to play with Hg. It looks interesting and I've heard only
>> good about it.
>>
> 
> It is nice.  Once Mercurial hits version 1.0 I am going to look at
> whether it is reasonable to move Python to hg or bzr to make it easier
> for people to do development on their own machines with local checkins
> instead of forcing people who can't create a branch to create their
> own VCS solution when doing offline work.

Why wait until 1.0? Hg is mature and used by a number of major projects.

BTW, there's a copy of Python's trunk converted to bzr on Launchpad:
<https://code.launchpad.net/~vcs-imports/python/trunk>
(that's the web page, not the branch itself)

I don't know of any conversions to hg. I half want to do it myself, but
I'm afraid to try to download so much from svn.python.org. :-P
-- 

From brett at python.org  Fri Dec 28 08:11:04 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 27 Dec 2007 23:11:04 -0800
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <4774A08B.2090902@mattnordhoff.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com>
Message-ID: <bbaeab100712272311i4950cff7q9f8142a3dc39bef6@mail.gmail.com>

On Dec 27, 2007 11:06 PM, Matt Nordhoff <mnordhoff at mattnordhoff.com> wrote:
> Brett Cannon wrote:
> > On Dec 26, 2007 2:40 PM, Christian Heimes <lists at cheimes.de> wrote:
> >> Alexandre Vassalotti wrote:
> >>> Well, I been working on branches since the beginning. Although, I now
> >>> use Mercurial (which is lovely IMHO) to keep my changes (url:
> >>> http://peadrop.com/alex-py3k/).
> >> Someday I need to play with Hg. It looks interesting and I've heard only
> >> good about it.
> >>
> >
> > It is nice.  Once Mercurial hits version 1.0 I am going to look at
> > whether it is reasonable to move Python to hg or bzr to make it easier
> > for people to do development on their own machines with local checkins
> > instead of forcing people who can't create a branch to create their
> > own VCS solution when doing offline work.
>

Just so people know, I won't start this for months, so we don't need
to keep discussing this and making noise on python-dev about it.

> Why wait until 1.0? Hg is mature and used by a number of major projects.
>

Yes, I know it is mature and used by many people, but for something as
critical as our VCS, I want the developers to be so much behind it
they are willing to call it version 1.0.

> BTW, there's a copy of Python's trunk converted to bzr on Launchpad:
> <https://code.launchpad.net/~vcs-imports/python/trunk>
> (that's the web page, not the branch itself)
>
> I don't know of any conversions to hg. I half want to do it myself, but
> I'm afraid to try to download so much from svn.python.org. :-P

Well, I won't stop you.  We get so much download traffic I doubt
downloading the entire history by one person will be a big deal.

-Brett

From alexandre at peadrop.com  Fri Dec 28 08:19:26 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 28 Dec 2007 02:19:26 -0500
Subject: [Python-3000] Some notes on newline conversion.
Message-ID: <acd65fa20712272319q7a10c94j87fbb92e6588a4f4@mail.gmail.com>

Hi,

I had a hard time, earlier today, figuring out what was the rules for
converting newline characters (only from the code of
io.TextIOWrapper). So, I wrote some notes for myself. I don't know if
there's any documentation about this yet -- that is why am posting my
notes to the list. Free it to use them for whatever you want to.

Cheers,
-- Alexandre


Known newline type:
  LF: \n or "universal newline"
  CRLF: \r\n
  CR: \r

Argument |
value    | Notes
---------+-------------------------------------------------------
None     | Default mode for open().
         | LF are converted to the value of os.linesep on writes.
         | Convert any known newline type to LF on reads.
         | Readline splits on LF.
---------+-------------------------------------------------------
""       | No conversions on writes.
         | No conversions on reads.
         | Readline splits on any known newline type.
---------+-------------------------------------------------------
LF       | Default mode for StringIO.
         | No conversions on writes.
         | No conversions on reads.
         | Readline splits on LF.
---------+-------------------------------------------------------
CRLF     | Convert LF to CRLF on writes.
         | No conversions on reads.
         | Readline splits on CRLF.
---------+-------------------------------------------------------
CR       | Convert LF to CR on writes.
         | No conversions on reads.
         | Readline splits on CR.
---------+-------------------------------------------------------

From mnordhoff at mattnordhoff.com  Fri Dec 28 08:30:07 2007
From: mnordhoff at mattnordhoff.com (Matt Nordhoff)
Date: Fri, 28 Dec 2007 02:30:07 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <bbaeab100712272311i4950cff7q9f8142a3dc39bef6@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	
	<4772CC8B.2000307@cheimes.de>	
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	
	<4772D855.6010108@cheimes.de>	
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	
	<4774A08B.2090902@mattnordhoff.com>
	<bbaeab100712272311i4950cff7q9f8142a3dc39bef6@mail.gmail.com>
Message-ID: <4774A5FF.5000606@mattnordhoff.com>

Brett Cannon wrote:
> On Dec 27, 2007 11:06 PM, Matt Nordhoff <mnordhoff at mattnordhoff.com> wrote:
>> Brett Cannon wrote:
>>> On Dec 26, 2007 2:40 PM, Christian Heimes <lists at cheimes.de> wrote:
>>>> Alexandre Vassalotti wrote:
>>>>> Well, I been working on branches since the beginning. Although, I now
>>>>> use Mercurial (which is lovely IMHO) to keep my changes (url:
>>>>> http://peadrop.com/alex-py3k/).
>>>> Someday I need to play with Hg. It looks interesting and I've heard only
>>>> good about it.
>>>>
>>> It is nice.  Once Mercurial hits version 1.0 I am going to look at
>>> whether it is reasonable to move Python to hg or bzr to make it easier
>>> for people to do development on their own machines with local checkins
>>> instead of forcing people who can't create a branch to create their
>>> own VCS solution when doing offline work.
> 
> Just so people know, I won't start this for months, so we don't need
> to keep discussing this and making noise on python-dev about it.
> 
>> Why wait until 1.0? Hg is mature and used by a number of major projects.
>>
> 
> Yes, I know it is mature and used by many people, but for something as
> critical as our VCS, I want the developers to be so much behind it
> they are willing to call it version 1.0.

Ok. I guess that's reasonable, but I think hg is close enough.

>> BTW, there's a copy of Python's trunk converted to bzr on Launchpad:
>> <https://code.launchpad.net/~vcs-imports/python/trunk>
>> (that's the web page, not the branch itself)
>>
>> I don't know of any conversions to hg. I half want to do it myself, but
>> I'm afraid to try to download so much from svn.python.org. :-P
> 
> Well, I won't stop you.  We get so much download traffic I doubt
> downloading the entire history by one person will be a big deal.

Heh, ok.

I just tried it, and it seems I don't have the svn Python bindings set
up properly. Never mind, I guess, at least for now.

> -Brett
-- 

From martin at v.loewis.de  Fri Dec 28 10:49:07 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 28 Dec 2007 10:49:07 +0100
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <4774A08B.2090902@mattnordhoff.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com>
Message-ID: <4774C693.5070207@v.loewis.de>

> Why wait until 1.0? 

When I suggested moving from CVS to subversion, people asked that
a PEP is written; this became PEP 347.

I would like to ask the same for any conversion *from* subversion,
be it to hg, bzr, git, bk, or ClearCase.

So anybody who wants to seriously attempt introducing such a change,
please present your PEP. Anybody else, please stand back and watch.

Regards,
Martin

From lists at cheimes.de  Fri Dec 28 14:01:19 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 28 Dec 2007 14:01:19 +0100
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <4774C693.5070207@v.loewis.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>
	<4774C693.5070207@v.loewis.de>
Message-ID: <4774F39F.2050300@cheimes.de>

Martin v. L?wis wrote:
> I would like to ask the same for any conversion *from* subversion,
> be it to hg, bzr, git, bk, or ClearCase.
> 
> So anybody who wants to seriously attempt introducing such a change,
> please present your PEP. Anybody else, please stand back and watch.

I also like to some good answers for a bunch of questions.

What are the benefits and strengths of bzr/git/hg better over svn? What
problems do the distributed version control systems solve that svn
doesn't solve.

Why should we choose bzr/git/hg over bzr/git/hg?

Do the new feature justify the extra burden on the core developers to
learn a new VCS and new tools?

Does a new VCS come with all the nifty and handy small tools, OS
integration and IDE integration I like? I definitely don't want to loose
the explorer integration of tortoisesvn on Windows or meld on Unix. The
new VCS may have reached version 1.0 but do they come with the rich tool
set? Although I'm a CLI fetishist I still like a decent GUI for some tasks.

Christian

From mnordhoff at mattnordhoff.com  Fri Dec 28 15:30:31 2007
From: mnordhoff at mattnordhoff.com (Matt Nordhoff)
Date: Fri, 28 Dec 2007 09:30:31 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
 their optimized C version?
In-Reply-To: <4774F39F.2050300@cheimes.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de>
Message-ID: <47750887.70708@mattnordhoff.com>

Christian Heimes wrote:
> Martin v. L?wis wrote:
>> I would like to ask the same for any conversion *from* subversion,
>> be it to hg, bzr, git, bk, or ClearCase.
>>
>> So anybody who wants to seriously attempt introducing such a change,
>> please present your PEP. Anybody else, please stand back and watch.
> 
> I also like to some good answers for a bunch of questions.
> 
> What are the benefits and strengths of bzr/git/hg better over svn? What
> problems do the distributed version control systems solve that svn
> doesn't solve.

Intelligent (I'd say "functional", but most people seem to be more
forgiving than me) branching and merging. On merging, they all can merge
two branches together while preserving history. You don't lose history,
and you don't have to keep track of revision numbers for repeated
merges. All you have to do is "$vcs merge" and the VCS will work out
which revisions need to be merged.

On branching, every checkout is really its own branch. (That might sound
complicated, but it's not. If you just want to keep a copy of another
branch, all you have to do is e.g. "hg pull -u" instead of "svn up".)

This means that you don't have to have commit access to the central
server to make your own branch and commit to it. After working
privately, you can publish your branch (also much easier to do than in
svn), or generate a patch-like file, and other people or the central
developers can easily merge your changes, preserving history.

That also means that developers can create tons of small branches
without making a mess of the central server (just their own ;-) ).

Those three also have three different rename handling designs, all more
advanced than svn's basic copy+delete.

(Checkouts being branches, (usually) with the full history downloaded,
also means you can diff or annotate or commit or whatever you want while
offline, useful on a train or whatever.)

> Why should we choose bzr/git/hg over bzr/git/hg?

Mostly (going on their general reputations):

Git is a speed demon, but has a horrible, complicated UI (which has
recently been improving). It's also only recently started to get decent
Windows support.

Bzr has a nice UI and is cross-platform (and has great dumb server
(HTTP, SFTP, FTP) support), but is slow (not a problem on non-huge
projects, and it's getting better).

Hg is cross-platform, almost as fast as git, and with nice UI.

Git is written in C (with some shell scripts and stuff that are being
rewritten in C). Bzr and hg are both written in Python with some C bits
for performance.

(I prefer bzr's UI to hg's. Hg uses more technical and lower-level terms
than really necessary, and bzr doesn't. Not a major problem, though. Hg
might even promote a better understanding of the tool, which would be nice.

Hg also has a simpler UI and tends to have minimal (or no) output, e.g.
you have to supply -v to commit just to get the list of files modified;
by default it outputs nothing.)

> Do the new feature justify the extra burden on the core developers to
> learn a new VCS and new tools?

Once everybody switches to bzr/git/hg, that won't be a problem anymore! :-D

Well, the core developers don't experience one of the main disadvantages
of svn: that non-core developers don't have the ability to make their
own branches or commit. But I would still say that the more branchy and
history-preserving workflow is absolutely worth it.

(Of course, with less technical teams, having to learn even one more
term is practically a deal-breaker. But that shouldn't be a problem
among an FOSS programming language's developers...)

> Does a new VCS come with all the nifty and handy small tools, OS
> integration and IDE integration I like? I definitely don't want to loose
> the explorer integration of tortoisesvn on Windows or meld on Unix. The
> new VCS may have reached version 1.0 but do they come with the rich tool
> set? Although I'm a CLI fetishist I still like a decent GUI for some tasks.

For bzr and hg (and I presume git), not yet. The GUI and tool situation
is getting better all the time, but it still isn't as good as
Subversion. A lot of tools are available now, but they aren't that mature.

> Christian

As a disclaimer, I should say that I'm not a big-time programmer, but I
am a nerd who is very interested in VCSes and does use them. I've also
never used git, but I use both bzr and hg a lot, chat with their
developers on IRC and have even written a few tiny patches.

Err, when did this become a big discussion on VCSes? I didn't really
mean to do that, but I can't resist pushing DVCSes whenever I get the
opportunity. :-P


Ok, I'm really tired of working on this message now. And when I make
changes, I'm just hacking them in without reworking the surrounding text
much. So I'll hit Send now.

I haven't seen a basic, practical, "vs.-svn" sort of introductory
article on DVCSes. I wish there was one, because I'm sure it would sound
better than anything I could come up with. :-P
-- 

From damonmc at gmail.com  Fri Dec 28 17:40:36 2007
From: damonmc at gmail.com (Damon McCormick)
Date: Fri, 28 Dec 2007 08:40:36 -0800
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <47750887.70708@mattnordhoff.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com> <4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de> <47750887.70708@mattnordhoff.com>
Message-ID: <3cce76f60712280840h4d17706bq20fbd103ad7f9df8@mail.gmail.com>

I just wrote up a summary of Mercurial and distributed version control
systems for a coworker.  I figured I'd add it to the discussion in case it
helps get some of the main ideas of these systems across...

-Damon

-----


Mercurial (hg) is one of a new breed of "distributed" version control
systems, which I think have a lot of advantages over traditional systems
that have a single copy of the repository.  I am using it for my own
personal software these days and highly recommend it.  If you've heard of or
used svk with svn, then you may be familiar with a few of the ideas
involved.

*Basic Ideas of Distribute Version Control*

Here are a some points that should give a flavor for what distributed
version control and hg are all about:


   - It turns out that with the right representation of a repository on
   disk, you can usually store the entire history of a project in not much more
   space than it takes to store the current snapshot of the project.  And in
   some cases, you can store the entire history in less space. (also note that
   the size of compiled libraries and executables often dwarfs the size of the
   source + history.
   - Given this, it makes sense for each developer to have a copy of the
   entire repository on their local hard drive.  Then they can do a series of
   commits on their laptop hard drive without waiting for any kind of network
   activity (or even while they're on a plane) and then push the changes onto
   the "master" repository at a later date without losing all the incremental
   local revisions.  Besides mobile/disconnected development, the major benefit
   of a local repository is that it makes most operations effectively
   instantaneous.  Even some of the slowest operations, such as large
   (entire-project) diffs become quick.
   - You take the hit for downloading the repository once, up front.
   From then on, compressed diffs (just like those used in the repository
   itself) are sent over the network.  The diffs for a revision also come with
   a cryptographic signature so that when they are expanded you can be sure
   they're not corrupted (more on that later).
   - There is a separation/independence between the most recent revision
   of the project that your repository knows about and the state of the source
   files on your disk.  You can make your source reflect a previous state of
   the project and then jump forward to the most current state without
   connecting to the master repository.  This separation also means that
   downloading a set of revisions from the "master" repository (for instance,
   all the changes that have occurred since your last download) is a separate
   step from actually updating your source files to reflect those changes.
   This way, if you're in the middle of some local changes, you can download
   the latest revisions without merging them into your source, disconnect from
   the network, keep working on your local changes, and then, only when you're
   happy with your changes, you can merge them with those that you downloaded.

   - Since repositories are small and copying local files is fast,
   there's low overhead for having multiple copies of a repository on your
   drive.  So a branch is implemented as a copy of a repository, along with a
   pointer to the original (this is very fast because hard links are used for
   the files that make up the repository itself, with copy-on-write semantics
   for later changes).  You can do independent changes in an independent
   repository and then merge the results when you're done.  Once again, you can
   do multiple experimental commits on each repository without worries of
   polluting the master repository with a record of those changes until you're
   sure they're worth pushing back.
   - Changes can be either pulled from another repository or pushed to
   it.  Again, the separation between the set of revisions a repository knows
   about and the state of the source files on the disk means that the owner of
   the repository gets to review the changes before making them official.
   - Since multiple branches are the norm, merging is a common
   operation.  As much merge support as possible is included in the tool and
   the rest is easy to plug in via standard interactive merge tools.  The
   result is that merges tend to be quite easy and when your lines of code
   don't overlap you typically don't even have to think about them.
   - Given that each developer has a copy of the entire repository,
   there's no reason that two developers have to communicate changes through
   the centralized repository.  If I have changes you want, you can pull them
   from my repository, preserving all the incremental revisions and comments
   that I've made, and then push the entire thing back to the master when
   you're done.  The history of branches and merges, including who did what, is
   kept so that the history reflects what actually happened (including the fact
   that there were 2 parallel branches for a while).
   - By cryptographically signing each "change set" (not only the state
   of the files in that revision but also the history of the revision), the
   revision control system can give you a single unique 40-digit "change set
   number" that can be verified against an actual repository to guarantee that
   it is not corrupted in any way.  (For day-to-day use, a developer only needs
   to use the first few digits of the number?enough to be unambiguous within
   that repository, or can instead use simple, consecutive revision numbers.)
   - The final idea is that in this model, there's nothing special about
   the master repository.  Every repository is has the same capabilities as
   every other, and it's up to a project to assign any special significance to
   one or more repositories.
   - Every file required by the version control system can be stored in a
   single hidden (.hg) file at the top directory of the repository.  This is
   the single point of file namespace pollution for using the system in a
   project.


That's probably enough to give the basic idea.


*User Interface  *

As far as the interface goes, you type "hg init" at the top level of a
project directory containing your source files to create a boilerplate
"blank-slate" .hg directory.  You type "hg status" see which new files
Mercurial sees in your directory (all files show up as new files).  You
create a .hgignore file at the top level and add glob- or regex-style
patterns to tell Mercurial about the files that it should not track (object
files, backup files, etc.).  You type "hg status" to confirm that the set of
files Mercurial sees are the ones you want to add to the project and then
"hg add" to add them all (you can also add a subset with "hg add
<filenames>").  Finally, you do "hg commit" ("hg ci" is equivalent).  At
this point you have your first revision and a "hg status" should show
nothing (or whatever files you chose not to add if you didn't add them all
for the first commit).  Typing "hg clone <hg_dir>" in a completely separate
directory will create a copy (branch) of your project there.  "hg clone
<url>" or "hg clone ssh://user at host:22/<hg_dir>" will create a branch of a
network-visible project.  "hg pull [<repository>]" will copy/download any
new revisions from the named repository, which defaults to the one you
branched from.  "hg update" is required to bring the state of your sandbox
in sync with the downloaded revisions.  An "hg merge" may be needed if there
are conflicts.  "hg push" will push changes back up to the place your
directory was cloned from (again, an "hd update" and "hg commit" are
required on the other end to make those changes official).

Mercurial also has a built-in web server that can be started if you want
people on a shared network to be able to browse your repository that way.
In addition, it comes with a graphical tool (hgk) which allows you to see
the history of a project including branches and merges.  I'm fond of using
tkdiff to diff my sandbox with a repository so I hacked a copy of tkdiff to
do this (perhaps by now the official one supports it as well.)

One more cool feature I have to mention: Mercurial has a "bisect" command
that you can use for finding when a bug was introduced.  You start bisect,
which chooses a revision of the code for you.  You run your regression test
and run bisect again, telling it whether your test succeeded or failed.
This chooses a new revision of the code using a binary search.  In a small
number of iterations, you find the change that broke the code.  Clearly,
with an automated test this is easy to automate.  I haven't used the command
yet, but am looking forward to it.  I think we should create something
similar for use with xcs, since this automates a useful process that many
people find prohibitively tedious.
*
Mercurial Weaknesses*

One weakness of mercurial is that it does not have support for storing
multiple projects (i.e. you might want to selectively check out a single
project without checking out the rest) in the same repository.  If your
project source includes large, independent subsystems and projects (a
situation that I haven't dealt with yet in my own use of hg), it sounds like
the way to handle this is to use relative symbolic links in the separate
projects.  But I've only read some references to doing this and I don't
completely understand it yet.


*Other Distributed Version Control Tools*

There's another system, called Git, that is probably just as good as
Mercurial.  Git was created by Linus Torvalds and is based on almost the
same set of ideas as mercurial.  Git is quite a bit faster for many
operations and uses a little less disk space, but last I checked it still
had bad Windows support and Mercurial had better documentation.  Otherwise,
they seem pretty similar in terms of robustness and features, although I
found git to be a bit more confusing on first glance because of the large
number of additional "plumbing" commands that it makes available. Recently I
took a second look and got the impression that there's a subset of the git
commands that are almost identical to the hg commands.  Although I
originally tried git first, I later tried Mercurial and (perhaps because of
the better documentation) never went back.  I was also  impressed by the
fact that the original mercurial source code was just a couple thousand
lines of pure python and was?at the time?within a factor of 2 of the speed
of git?I appreciate the engineering required to write something in an
elegant, concise way and still have it perform within an order of magnitude
of C code written by a master of ultra-efficient OS-level C.  The Mercurial
source is larger now, and includes 3 small (<500 lines each) C files to
speed up diffs, patch files, and some other low-level feature, but is still
pretty small (~20KLOC vs. ~90KLOC for Git).  In any case, both tools were so
many times faster than any version control I'd used in the past that I
really didn't care about that last percent of speed that git might give me.
The tools have shared a lot of ideas and even some code (e.g. hgk is derived
from a Git gui called gitk, git has copied some of hg's features) and I
expect this to continue since they're both developed by active members of
the linux kernel community.

The rest of the distributed version control systems I know of are: bzr
("Bazaar", written in Python), monotone, GNU Arch, and darcs (written in
Haskell).  Darcs is supposed to be conceptually different from the others
but I really don't know much about it.  All of these others had
significantly lower performance than git or hg last I checked, but things
are changing fast.  Bzr is supposed to have a slightly easier command line
interface, but I find Mercurial's to be pretty easy already.  There are
tools for migrating projects from each of these to any of the others.

SVK is a tool for use with SVN that lets you have a local repository.  I
think it's kind of like an svn  repository on one side (the user side) and
an svn client on the other (the side that talks to the real SVN server).  A
good friend uses it and recommends it for SVN users who want to be able to
do "offline" publishes.  My understanding, however, is that it doesn't
provide any of the other features of the tools above.

*Migrating to Mercurial*

There are a few tools for migrating projects from SVN and CVS.  The one
called "hgsvn" seemed like the best for SVN last time I checked.  The
original import is kind of slow, though, since it has to do something like
check out each revision from the SVN server.

Some people seem to feel productive using hg locally while publishing to a
cvs or svn server.  I'm not sure how that works though.

*Links*

Official Page - http://www.selenic.com/mercurial/wiki/
Tutorial - http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial
Book - http://hgbook.red-bean.com/hgbook.html

Google Tech Talk about Hg: http://www.youtube.com/watch?v=JExtkqzEoHY
Linus' egotistical talk about Git:
http://www.youtube.com/watch?v=4XpnKHJAok8
Randal Schwartz' talk about Git: http://www.youtube.com/watch?v=8dhZ9BXQgc4

Performance Benchmarks (of varying quality and age) -
  http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html

http://weblogs.mozillazine.org/jst/archives/2007/02/bzr_and_different_network_prot.html
  http://git.or.cz/gitwiki/GitBenchmarks
  https://lists.ubuntu.com/archives/bazaar/2006q2/011953.html


-Damon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071228/b69e7194/attachment-0001.htm 

From ncoghlan at gmail.com  Fri Dec 28 17:49:58 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 29 Dec 2007 02:49:58 +1000
Subject: [Python-3000] not switching core VCS (was How to override
 io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <47750887.70708@mattnordhoff.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>
	<47750887.70708@mattnordhoff.com>
Message-ID: <47752936.20208@gmail.com>

Matt Nordhoff wrote:
> Christian Heimes wrote:
>> Do the new feature justify the extra burden on the core developers to
>> learn a new VCS and new tools?
> 
> Once everybody switches to bzr/git/hg, that won't be a problem anymore! :-D
> 
> Well, the core developers don't experience one of the main disadvantages
> of svn: that non-core developers don't have the ability to make their
> own branches or commit. But I would still say that the more branchy and
> history-preserving workflow is absolutely worth it.

I think getting over this hurdle is going to be the deal breaker. While 
I suspect such a switch will happen eventually (as I believe the DVCS 
approach really is a better one for open source projects), there also 
doesn't seem to be anything which is a major driver for making this 
change in the case of Python in particular. The CVS to SVN change was a 
natural migration, since it didn't involve any real changes to the 
existing development workflow and brought a lot of direct benefits to 
the core developers (and got us away from the Sourceforge CVS 
repository, which we'd been having a few problems with).

For migrating from a centralised to a distributed VCS though, since the 
PSF repository is the upstream of all of the derived builds, it doesn't 
really gain any major benefits from the switch (the major activity which 
could have benefited - the parallel 2.6 and 3.0 development - should be 
effectively over by the time this comes up for discussion as a serious 
proposal). And downstream can get a pretty good work-alike by creating a 
vendor branch in their own preferred DVCS and making their modifications 
based on that (the only bit missing is integrated tracking of submitted 
changes which are accepted back into the central repository).

But I certainly don't see any reason for urgency - what we have now 
works reasonably well, and I personally don't want to contemplate any 
major procedural changes until both 3.0 and 2.6 are out the door.

Cheers,
Nick.

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

From skip at pobox.com  Fri Dec 28 18:18:21 2007
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 28 Dec 2007 11:18:21 -0600
Subject: [Python-3000] Maybe change the subject?
In-Reply-To: <3cce76f60712280840h4d17706bq20fbd103ad7f9df8@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<4772CC8B.2000307@cheimes.de>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com> <4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de> <47750887.70708@mattnordhoff.com>
	<3cce76f60712280840h4d17706bq20fbd103ad7f9df8@mail.gmail.com>
Message-ID: <18293.12253.118950.977652@montanaro.dyndns.org>

I don't have any problem with a discussion of Mercurial or Bazaar as they
relate to hosting Python's source code, but could we maybe not cloak the
discussion with a subject about the io module?

Thx,

Skip

From barry at python.org  Fri Dec 28 18:40:00 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Dec 2007 12:40:00 -0500
Subject: [Python-3000] How to override io.BytesIO and io.StringIO with
	their optimized C version?
In-Reply-To: <47750887.70708@mattnordhoff.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de> <47750887.70708@mattnordhoff.com>
Message-ID: <6C9388AC-CE64-4FD7-8B4E-F9EA886230A6@python.org>

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

On Dec 28, 2007, at 9:30 AM, Matt Nordhoff wrote:

> Bzr has a nice UI and is cross-platform (and has great dumb server
> (HTTP, SFTP, FTP) support), but is slow (not a problem on non-huge
> projects, and it's getting better).

In fact, my /personal/ opinion is that Bazaar is fast enough for  
nearly all daily uses.  I've not done benchmarking myself, but the  
numbers I've seen make Bazaar performance at least on par with  
Mercurial these days (some operations are faster, some are slower, but  
all seem in the ballpark and acceptable).  Specific subjective  
performance will depend on lots of factors of course, but I don't  
think the knock on Bazaar's performance is really true any more.

For the Bazaar project's take on a comparison between the major dvcs  
players, see:

http://bazaar-vcs.org/BzrWhy

> Well, the core developers don't experience one of the main  
> disadvantages
> of svn: that non-core developers don't have the ability to make their
> own branches or commit. But I would still say that the more branchy  
> and
> history-preserving workflow is absolutely worth it.

I would definitely agree.  Putting aside the dvcs wars for now, I  
think moving /to/ a dvcs for Python would be a huge win both for core  
developers and the rest of the community.  I won't speak for any other  
dvcs, but I do not think an experienced svn user would have any  
trouble switching to bzr after a day or so of use.

For core developers, I'd say the major benefits include cheap and  
functional branching (I agree with you here Matt! :), simple and fully  
functional disconnected use, great merging, and many options for  
sharing changing (e.g. bundling branch diffs in an email).

For non-core developers it's a huge win because a dvcs democratizes  
the development process.  You don't have to beg a core developer to  
get your patch in.  You can easily track the official mainlines and  
publish your own first class branches.  I kind of envision a scenario  
where non-core devs can promote their ideas in fully functional  
branches rather than a disconnected set of patches.

Giving that kind of power to everyone is worth a little bit of  
disruption I think.

>> Does a new VCS come with all the nifty and handy small tools, OS
>> integration and IDE integration I like? I definitely don't want to  
>> loose
>> the explorer integration of tortoisesvn on Windows or meld on Unix.  
>> The
>> new VCS may have reached version 1.0 but do they come with the rich  
>> tool
>> set? Although I'm a CLI fetishist I still like a decent GUI for  
>> some tasks.
>
> For bzr and hg (and I presume git), not yet. The GUI and tool  
> situation
> is getting better all the time, but it still isn't as good as
> Subversion. A lot of tools are available now, but they aren't that  
> mature.

I'm not so sure about that.  Although I'm a pure CLI-ster, my  
understanding is that bzr has GUI tools for gtk and other GUIs.

> Err, when did this become a big discussion on VCSes? I didn't really
> mean to do that, but I can't resist pushing DVCSes whenever I get the
> opportunity. :-P

I know what you mean!  Moving to a dvcs can be a life altering event  
for a developer :).

> I haven't seen a basic, practical, "vs.-svn" sort of introductory
> article on DVCSes. I wish there was one, because I'm sure it would  
> sound
> better than anything I could come up with. :-P

 From the bzr perspective:

http://bazaar-vcs.org/BzrVsSvn

Cheers,
- -Barry

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

iQCVAwUBR3U08XEjvBPtnXfVAQIIrgP/Xi46nhqSG7KpjzMkgFqFlB3KcWyvzTo5
ciSCAF+rwbvApwbUQbWwAH/MjJAafq9KIzugKqXPVDieU0uzG6OAaVVtfu7C3IMT
pgtRvf4CBiQLX7uWfaKRKV+HMXrN9s06mcs11zZ6aE+mdyQdQrKtEL31tStqlIJ4
2ZG9cvk+lfg=
=aaYq
-----END PGP SIGNATURE-----

From barry at python.org  Fri Dec 28 18:43:31 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Dec 2007 12:43:31 -0500
Subject: [Python-3000] not switching core VCS (was How to override
	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <47752936.20208@gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>
	<47750887.70708@mattnordhoff.com> <47752936.20208@gmail.com>
Message-ID: <5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>

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

On Dec 28, 2007, at 11:49 AM, Nick Coghlan wrote:

> For migrating from a centralised to a distributed VCS though, since  
> the
> PSF repository is the upstream of all of the derived builds, it  
> doesn't
> really gain any major benefits from the switch (the major activity  
> which
> could have benefited - the parallel 2.6 and 3.0 development - should  
> be
> effectively over by the time this comes up for discussion as a serious
> proposal). And downstream can get a pretty good work-alike by  
> creating a
> vendor branch in their own preferred DVCS and making their  
> modifications
> based on that (the only bit missing is integrated tracking of  
> submitted
> changes which are accepted back into the central repository).

Sorry Nick, but I have to disagree.  Switching to a dvcs would be a  
huge win for Python, both for core developers and others who wish to  
hack on Python but don't have commit privileges.  I've talked about  
why I think this in previous messages.

> But I certainly don't see any reason for urgency - what we have now
> works reasonably well, and I personally don't want to contemplate any
> major procedural changes until both 3.0 and 2.6 are out the door.

We'll leave the timing up to Brett and the infrastructure committee,  
but IMO, there's no overriding reason to wait.  In fact, it would be  
better to do the switch now before we're in the crush or decompression  
of new releases.

- -Barry

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

iQCVAwUBR3U1w3EjvBPtnXfVAQL8bwQArXsUO2PxOlJtqb4PQDTB6S8YU03o4UMp
Y14iLJHOWDPQtOW4Nxko0DPiyoF7ykJhR4qudOABs+2QitMS+tTc4yNMgOs+0UBe
MwQkQ6busnd7GzTTK3H1QmeRzdhT911dRVdVQeIni9tNhy95KQwO+cF8CL2sKShc
3+IQ7JL5zMg=
=oc10
-----END PGP SIGNATURE-----

From rhamph at gmail.com  Fri Dec 28 18:56:36 2007
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 28 Dec 2007 10:56:36 -0700
Subject: [Python-3000] not switching core VCS (was How to override
	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com> <4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de> <47750887.70708@mattnordhoff.com>
	<47752936.20208@gmail.com>
	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
Message-ID: <aac2c7cb0712280956l6d0e97b5p2fa46147bb6eb7d3@mail.gmail.com>

On Dec 28, 2007 10:43 AM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Dec 28, 2007, at 11:49 AM, Nick Coghlan wrote:
>
> > For migrating from a centralised to a distributed VCS though, since
> > the
> > PSF repository is the upstream of all of the derived builds, it
> > doesn't
> > really gain any major benefits from the switch (the major activity
> > which
> > could have benefited - the parallel 2.6 and 3.0 development - should
> > be
> > effectively over by the time this comes up for discussion as a serious
> > proposal). And downstream can get a pretty good work-alike by
> > creating a
> > vendor branch in their own preferred DVCS and making their
> > modifications
> > based on that (the only bit missing is integrated tracking of
> > submitted
> > changes which are accepted back into the central repository).
>
> Sorry Nick, but I have to disagree.  Switching to a dvcs would be a
> huge win for Python, both for core developers and others who wish to
> hack on Python but don't have commit privileges.  I've talked about
> why I think this in previous messages.


Providing official mirrors of all (or at least several important) svn
branches in popular DVCS tools would be sufficient.  Better, if you consider
that you can do several tools simultaneously, and there's no transition
necessary for the existing developers.

The word "distributed" in DVCS is exaggerated anyway.  You'll always need a
stable server to host public branches (as opposed to private ones, which can
just use your laptop's LAN ip address.)

The advantages related to merging are merely "nice" features, not critical
ones to warrant moving away from svn.

-- 
Adam Olsen, aka Rhamphoryncus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071228/c75b10e1/attachment.htm 

From barry at python.org  Fri Dec 28 19:07:25 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Dec 2007 13:07:25 -0500
Subject: [Python-3000] not switching core VCS (was How to override
	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <aac2c7cb0712280956l6d0e97b5p2fa46147bb6eb7d3@mail.gmail.com>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com>
	<4774C693.5070207@v.loewis.de> <4774F39F.2050300@cheimes.de>
	<47750887.70708@mattnordhoff.com> <47752936.20208@gmail.com>
	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
	<aac2c7cb0712280956l6d0e97b5p2fa46147bb6eb7d3@mail.gmail.com>
Message-ID: <6D8D73CF-47DB-43D0-BA62-1D7B699237A0@python.org>

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

On Dec 28, 2007, at 12:56 PM, Adam Olsen wrote:

> Providing official mirrors of all (or at least several important)  
> svn branches in popular DVCS tools would be sufficient.  Better, if  
> you consider that you can do several tools simultaneously, and  
> there's no transition necessary for the existing developers.

That's a transitional stage only, and in fact such beasts currently  
exist, so you could play with Python under <favorite dvcs> right now.   
But again, IMO, there are very big wins for even the official code  
base, and core developers, to want to host those branches natively  
under a dvcs.

Here's a simple one: how about not having your vcs force you to commit  
changes to a public repository before you're ready?  Under svn if you  
modify a file and before you commit it decide you want to rename it,  
svn puts up roadblocks, sometimes forcing you to commit your  
modification before you can do the rename.  bzr just does what you  
tell it to do.

> The word "distributed" in DVCS is exaggerated anyway.  You'll always  
> need a stable server to host public branches (as opposed to private  
> ones, which can just use your laptop's LAN ip address.)

It's distributed in the sense that connection to the public server is  
only necessary to publish change, not to make those changes, merge,  
branch, revert, commit, diff, etc. It's an important distinction  
worthy of the term, IMO.  Heck, that server isn't even necessary if  
you consider bundling branches (not patches!) into an email  
"publishing".

> The advantages related to merging are merely "nice" features, not  
> critical ones to warrant moving away from svn.

I respectfully disagree. :)

- -Barry

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

iQCVAwUBR3U7XXEjvBPtnXfVAQJnBAP/S9MJ3866WF2iSAS0pNrJBs102s3MqE1s
VP1ad3RvP/v9pGm9sG8IXjkl6ug2PV/gPsAXpkeq75ko7Dhn3toE+b0K8dctUOk3
RzkJ//cAUZwee/4smczKfET1Tu53UG4/gKNyzoPfSHpQHxQmDFZILxMy5o0dS3mm
erD+kGGwc94=
=UB+X
-----END PGP SIGNATURE-----

From alexandre at peadrop.com  Fri Dec 28 20:37:10 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 28 Dec 2007 14:37:10 -0500
Subject: [Python-3000] Reimplementing TextIOWrapper in C?
Message-ID: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>

As you all know now, I am working on a reimplementation of StringIO in
C (the Python version is just a BytesIO object in a TextIOWrapper). I
thought I was almost done, but it turns out that I need to reimplement
the whole newline translation mechanism in C. To do so, I will need to
modify almost every methods of StringIO just to make it handle
newlines properly -- basically reimplementing most of TextIOWrapper. I
realized it would be a better idea, to rewrite TextIOWrapper in C,
instead of StringIO. And then, add to it some special cases for
StringIO to avoid the encoding/decoding overheads.

Already wrote a good chunk of code for this -- i.e., I rewrote
IncrementalNewlineDecoder in C yesterday (turning 70 line of elegant
Python code into almost 300 lines of grotesque C). Anyway, I would
just like to know if some of you have hints or recommendations about
this.

Thanks,
-- Alexandre

From brett at python.org  Fri Dec 28 20:41:42 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 28 Dec 2007 11:41:42 -0800
Subject: [Python-3000] Maybe change the subject?
In-Reply-To: <18293.12253.118950.977652@montanaro.dyndns.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>
	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>
	<4772D855.6010108@cheimes.de>
	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>
	<4774A08B.2090902@mattnordhoff.com> <4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de> <47750887.70708@mattnordhoff.com>
	<3cce76f60712280840h4d17706bq20fbd103ad7f9df8@mail.gmail.com>
	<18293.12253.118950.977652@montanaro.dyndns.org>
Message-ID: <bbaeab100712281141h26621cdbv972140582ed7b0d@mail.gmail.com>

On Dec 28, 2007 9:18 AM,  <skip at pobox.com> wrote:
> I don't have any problem with a discussion of Mercurial or Bazaar as they
> relate to hosting Python's source code, but could we maybe not cloak the
> discussion with a subject about the io module?

The discussion should just stop.  My comment was just an aside and not
meant to spark any discussion of any form.

-Brett

From brett at python.org  Fri Dec 28 20:47:08 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 28 Dec 2007 11:47:08 -0800
Subject: [Python-3000] Reimplementing TextIOWrapper in C?
In-Reply-To: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>
References: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>
Message-ID: <bbaeab100712281147g700cb289wb9ec567f7f1a88b3@mail.gmail.com>

On Dec 28, 2007 11:37 AM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> As you all know now, I am working on a reimplementation of StringIO in
> C (the Python version is just a BytesIO object in a TextIOWrapper). I
> thought I was almost done, but it turns out that I need to reimplement
> the whole newline translation mechanism in C. To do so, I will need to
> modify almost every methods of StringIO just to make it handle
> newlines properly -- basically reimplementing most of TextIOWrapper. I
> realized it would be a better idea, to rewrite TextIOWrapper in C,
> instead of StringIO. And then, add to it some special cases for
> StringIO to avoid the encoding/decoding overheads.
>
> Already wrote a good chunk of code for this -- i.e., I rewrote
> IncrementalNewlineDecoder in C yesterday (turning 70 line of elegant
> Python code into almost 300 lines of grotesque C). Anyway, I would
> just like to know if some of you have hints or recommendations about
> this.
>

No specific hints, but why do you feel you must implement the whole
thing in C?  Can't you just import 'io' in your StringIO code and make
calls into the Python code?

-Brett

From alexandre at peadrop.com  Fri Dec 28 21:56:00 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 28 Dec 2007 15:56:00 -0500
Subject: [Python-3000] Reimplementing TextIOWrapper in C?
In-Reply-To: <bbaeab100712281147g700cb289wb9ec567f7f1a88b3@mail.gmail.com>
References: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>
	<bbaeab100712281147g700cb289wb9ec567f7f1a88b3@mail.gmail.com>
Message-ID: <acd65fa20712281256i59ae7cf7y90d6cbfc5ad74a05@mail.gmail.com>

On Dec 28, 2007 2:47 PM, Brett Cannon <brett at python.org> wrote:
> No specific hints, but why do you feel you must implement the whole
> thing in C?  Can't you just import 'io' in your StringIO code and make
> calls into the Python code?
>

Honestly, I didn't really consider this as a possibility, since
TextIOWrapper only accepts bytes buffer, as far as I know. The other
obstacle is newline conversion has a fair amount of state that needs
to be managed at the API level.

But, I thinking two better solutions. Could I add a "switch" to
TextIOWrapper to disable the encoding/decoding process for a unicode
buffer? Then, I could wrap my StringIO with TextIOWrapper without
adding any huge overhead. Otherwise, could I simply subclass my
StringIO and write the newlines conversion facilities in Python?

Btw, my reimplementation of IncrementalNewlineDecoder in C was just an
experiment. I certainly don't indent to propose it as a replacement.

-- Alexandre

From brett at python.org  Fri Dec 28 23:41:27 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 28 Dec 2007 14:41:27 -0800
Subject: [Python-3000] Reimplementing TextIOWrapper in C?
In-Reply-To: <acd65fa20712281256i59ae7cf7y90d6cbfc5ad74a05@mail.gmail.com>
References: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>
	<bbaeab100712281147g700cb289wb9ec567f7f1a88b3@mail.gmail.com>
	<acd65fa20712281256i59ae7cf7y90d6cbfc5ad74a05@mail.gmail.com>
Message-ID: <bbaeab100712281441kff33468h2ac4c4d4a2dc2122@mail.gmail.com>

On Dec 28, 2007 12:56 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On Dec 28, 2007 2:47 PM, Brett Cannon <brett at python.org> wrote:
> > No specific hints, but why do you feel you must implement the whole
> > thing in C?  Can't you just import 'io' in your StringIO code and make
> > calls into the Python code?
> >
>
> Honestly, I didn't really consider this as a possibility, since
> TextIOWrapper only accepts bytes buffer, as far as I know. The other
> obstacle is newline conversion has a fair amount of state that needs
> to be managed at the API level.
>
> But, I thinking two better solutions. Could I add a "switch" to
> TextIOWrapper to disable the encoding/decoding process for a unicode
> buffer? Then, I could wrap my StringIO with TextIOWrapper without
> adding any huge overhead.

I have no clue about this.

> Otherwise, could I simply subclass my
> StringIO and write the newlines conversion facilities in Python?
>

Definitely.  Nothing says C re-implementations have to be a complete
replacement.  Just do the performance-critical stuff in C and
everything else can just be Python code. It's easier to write and
maintain.

-Brett

From martin at v.loewis.de  Sat Dec 29 02:24:38 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 29 Dec 2007 02:24:38 +0100
Subject: [Python-3000] not switching core VCS (was How to
 override	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>
	<47752936.20208@gmail.com>
	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
Message-ID: <4775A1D6.3080509@v.loewis.de>

> We'll leave the timing up to Brett and the infrastructure committee,
> but IMO, there's no overriding reason to wait.

*That* is the major overriding reason: lack of volunteers. Any kind
of infrastructure work is massively short of volunteers, and that's
why any talk about switching will just pass with no effect. Of course,
volunteering to work on a change that in itself might be disputed also
is a time-consuming activity, so it's no surprise that nobody
volunteers.

Regards,
Martin

From martin at v.loewis.de  Sat Dec 29 02:28:31 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 29 Dec 2007 02:28:31 +0100
Subject: [Python-3000] not switching core VCS (was How to
 override	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <6D8D73CF-47DB-43D0-BA62-1D7B699237A0@python.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>
	<47752936.20208@gmail.com>	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>	<aac2c7cb0712280956l6d0e97b5p2fa46147bb6eb7d3@mail.gmail.com>
	<6D8D73CF-47DB-43D0-BA62-1D7B699237A0@python.org>
Message-ID: <4775A2BF.2090909@v.loewis.de>

> Here's a simple one: how about not having your vcs force you to commit
> changes to a public repository before you're ready?  Under svn if you
> modify a file and before you commit it decide you want to rename it,
> svn puts up roadblocks, sometimes forcing you to commit your
> modification before you can do the rename.  bzr just does what you
> tell it to do.

I don't see that as an advantage - it doesn't solve a problem that
I actually ever have. I rarely want to rename files, and renaming
files in the Python repository requires consensus, anyway, so any
renaming *should not* be committed along with other changes.

Regards,
Martin


From barry at python.org  Sat Dec 29 05:07:14 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Dec 2007 23:07:14 -0500
Subject: [Python-3000] not switching core VCS (was How to
	override	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <4775A1D6.3080509@v.loewis.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>
	<47752936.20208@gmail.com>
	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>
	<4775A1D6.3080509@v.loewis.de>
Message-ID: <2A18EE2D-2361-4742-8DA5-E5FF4D3F5A9F@python.org>

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

On Dec 28, 2007, at 8:24 PM, Martin v. L?wis wrote:

>> We'll leave the timing up to Brett and the infrastructure committee,
>> but IMO, there's no overriding reason to wait.
>
> *That* is the major overriding reason: lack of volunteers. Any kind
> of infrastructure work is massively short of volunteers, and that's
> why any talk about switching will just pass with no effect. Of course,
> volunteering to work on a change that in itself might be disputed also
> is a time-consuming activity, so it's no surprise that nobody
> volunteers.

If Bazaar is chosen, I would volunteer to help with the conversion.

- -Barry

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

iQCVAwUBR3XH83EjvBPtnXfVAQKVJwP9GkyCg1FaQspez2DeDbjLbnAcxdAwD0aB
WlnPP552jswhEVzKR6cyNZiVS5cDbMPIlIe2BQZcrkXZuCzXOLbBZY0dFIvfsPz9
ahmj3KzBljpTUyQsBGd7RVIuHbl1imJgdeyhGh7u5cKd8u9BE1szc+cRJZCYlOZx
MrZYQ4BImS0=
=Mbx4
-----END PGP SIGNATURE-----

From barry at python.org  Sat Dec 29 05:08:42 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Dec 2007 23:08:42 -0500
Subject: [Python-3000] not switching core VCS (was How to
	override	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <4775A2BF.2090909@v.loewis.de>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>
	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>
	<47752936.20208@gmail.com>	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>	<aac2c7cb0712280956l6d0e97b5p2fa46147bb6eb7d3@mail.gmail.com>
	<6D8D73CF-47DB-43D0-BA62-1D7B699237A0@python.org>
	<4775A2BF.2090909@v.loewis.de>
Message-ID: <B9AE299D-B846-4F2D-A036-363ABA472D97@python.org>

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

On Dec 28, 2007, at 8:28 PM, Martin v. L?wis wrote:

>> Here's a simple one: how about not having your vcs force you to  
>> commit
>> changes to a public repository before you're ready?  Under svn if you
>> modify a file and before you commit it decide you want to rename it,
>> svn puts up roadblocks, sometimes forcing you to commit your
>> modification before you can do the rename.  bzr just does what you
>> tell it to do.
>
> I don't see that as an advantage - it doesn't solve a problem that
> I actually ever have. I rarely want to rename files, and renaming
> files in the Python repository requires consensus, anyway, so any
> renaming *should not* be committed along with other changes.

I suspect you'll see quite a bit of renaming during the stdlib  
reorganization.

- -Barry

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

iQCVAwUBR3XISnEjvBPtnXfVAQLTDgQArtHVqqjvh9BZxcjavhL+K+aApGE4l6tn
q/0ql+LjMx1g5tdjr7MNIsjKSKS9KNmYOQz+CU6PzMO/ak0qfFqTqnfXmj4DD22F
tgnuZi6CyAyq2x/hKVEjkmuXzOYfBa3B+JAkEwJLE8tcc78FE6yaVVWeobvIW5TV
siDk+//x5uI=
=fdKT
-----END PGP SIGNATURE-----

From rocco.rossi at gmail.com  Tue Dec 25 23:16:44 2007
From: rocco.rossi at gmail.com (Rocco Orlando Rossi)
Date: Tue, 25 Dec 2007 23:16:44 +0100
Subject: [Python-3000] Lexical variables at last!
Message-ID: <720198610712251416m63ddf086s8d40673ab696b5cf@mail.gmail.com>

I think it's wonderful that Python 3000 will have the nonlocal keyword
allowing complete lexical closures. I've just downloaded Python 3.0 a2 and
tried the following code:

def accumulator(n):

    def foo(x):
        nonlocal n
        n = n + x
        return n

    return foo

... and it works!!! (Now let's see what Paul Graham has to say ... ;) )

However, I've also tried this:

def accumulator(n):
    return lambda x: nonlocal n = n + x

and unfortunately it gave me a syntax error. I don't see any reason why this
kind of code should not be possible.

What do you all think?


-- 
Rocco Rossi

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

"Alcuni vedono le cose come sono e dicono perch?? Io sogno cose non ancora
esistite e chiedo perch? no?"

G.B. Shaw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071225/8ad0aaea/attachment.htm 

From skip at pobox.com  Sat Dec 29 12:46:57 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 29 Dec 2007 05:46:57 -0600
Subject: [Python-3000] Lexical variables at last!
In-Reply-To: <720198610712251416m63ddf086s8d40673ab696b5cf@mail.gmail.com>
References: <720198610712251416m63ddf086s8d40673ab696b5cf@mail.gmail.com>
Message-ID: <18294.13233.689037.298202@montanaro.dyndns.org>


    Rocco> However, I've also tried this:

    Rocco> def accumulator(n):
    Rocco>     return lambda x: nonlocal n = n + x

    Rocco> and unfortunately it gave me a syntax error. I don't see any
    Rocco> reason why this kind of code should not be possible.

    Rocco> What do you all think?

Lambdas only support a single expression, not statements and that's not
going to change in 3.0.

Skip

From bwinton at latte.ca  Sat Dec 29 19:05:38 2007
From: bwinton at latte.ca (Blake Winton)
Date: Sat, 29 Dec 2007 13:05:38 -0500
Subject: [Python-3000] not switching core VCS (was How
 to	override	io.BytesIO and io.StringIO with their optimized C version?)
In-Reply-To: <2A18EE2D-2361-4742-8DA5-E5FF4D3F5A9F@python.org>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>	<47752936.20208@gmail.com>	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>	<4775A1D6.3080509@v.loewis.de>
	<2A18EE2D-2361-4742-8DA5-E5FF4D3F5A9F@python.org>
Message-ID: <47768C72.1010604@latte.ca>

Barry Warsaw wrote:
> On Dec 28, 2007, at 8:24 PM, Martin v. L?wis wrote:
>>> We'll leave the timing up to Brett and the infrastructure committee,
>>> but IMO, there's no overriding reason to wait.
>> *That* is the major overriding reason: lack of volunteers.
> If Bazaar is chosen, I would volunteer to help with the conversion.

Same here...

Later,
Blake.

From lists at cheimes.de  Sun Dec 30 17:16:51 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 30 Dec 2007 17:16:51 +0100
Subject: [Python-3000] The grand renaming
Message-ID: <4777C473.9020604@cheimes.de>

Python 3.0a2 is out and some people are working on backports of Python
3.0 features to 2.6. Shouldn't we start to rename the new API functions
and files to their final names before we back merge code to 2.6?

I'm proposing to change the names and files as following. I'm willing to
make the necessary changes myself.

API methods:
PyUnicode - keep the name
PyBytes - PyByteArray
PyString - PyBytes
PyBuffer - PyMemoryView

Files:
bytesobject.[ch] - bytearrayobject.[ch]
memoryobject.[ch] - memoryviewobject.[ch]
stringobject.[ch] - bytesobject.[ch]

Christian

From jgarber at ionzoft.com  Sun Dec 30 23:11:06 2007
From: jgarber at ionzoft.com (Jason Garber)
Date: Sun, 30 Dec 2007 16:11:06 -0600
Subject: [Python-3000] not switching core VCS (was How
	to	override	io.BytesIO and io.StringIO with their optimized C
	version?)
In-Reply-To: <47768C72.1010604@latte.ca>
References: <acd65fa20712261324m3d2180fci363ff301b4a9c233@mail.gmail.com>	<4772CC8B.2000307@cheimes.de>	<acd65fa20712261428g765ae065gc5994802dfddaa23@mail.gmail.com>	<4772D855.6010108@cheimes.de>	<bbaeab100712261720s459365abu1cb2d2cdc27df91e@mail.gmail.com>	<4774A08B.2090902@mattnordhoff.com>	<4774C693.5070207@v.loewis.de>	<4774F39F.2050300@cheimes.de>	<47750887.70708@mattnordhoff.com>	<47752936.20208@gmail.com>	<5AF3A7C6-AEC5-4111-A52D-58CBFA3A921A@python.org>	<4775A1D6.3080509@v.loewis.de><2A18EE2D-2361-4742-8DA5-E5FF4D3F5A9F@python.org>
	<47768C72.1010604@latte.ca>
Message-ID: <E7DE807861E8474E8AC3DC7AC2C75EE504AD9E89@34093-EVS2C1.exchange.rackspace.com>

Note: I cannot speak for git-on-windows (because we don't use it there)...

Our company recently completed a total conversion from svn to git on a large number of large projects.

At this point, Git:
- Is a very, very active project
- Has a easy-to-learn CLI, with some GUI goodies (the complex parts of git run deep, but give power)
- Is freakishly fast (10x to 100x faster than SVN in our case)
- Has goodies like "git stash, git grep", and the ability to switch branches fast (usually sub-second)
- Makes branching/merging/deploying a breeze
- Supports offline development
- Would make it very easy for the community to work on, test, and submit (even large) changes

After a lot of analysis of the VCS's available, we chose git based on the above, and more.

It has been an incredible benefit to our organization.

-JG

-----Original Message-----
From: python-3000-bounces+jgarber=ionzoft.com at python.org [mailto:python-3000-bounces+jgarber=ionzoft.com at python.org] On Behalf Of Blake Winton
Sent: Saturday, December 29, 2007 1:06 PM
To: Barry Warsaw
Cc: Python 3000
Subject: Re: [Python-3000] not switching core VCS (was How to override io.BytesIO and io.StringIO with their optimized C version?)

Barry Warsaw wrote:
> On Dec 28, 2007, at 8:24 PM, Martin v. L?wis wrote:
>>> We'll leave the timing up to Brett and the infrastructure committee,
>>> but IMO, there's no overriding reason to wait.
>> *That* is the major overriding reason: lack of volunteers.
> If Bazaar is chosen, I would volunteer to help with the conversion.

Same here...

Later,
Blake.
_______________________________________________
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/jgarber%40ionzoft.com



From g.brandl at gmx.net  Mon Dec 31 07:46:43 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 31 Dec 2007 07:46:43 +0100
Subject: [Python-3000] The grand renaming
In-Reply-To: <4777C473.9020604@cheimes.de>
References: <4777C473.9020604@cheimes.de>
Message-ID: <fla38v$7p5$1@ger.gmane.org>

Christian Heimes schrieb:
> Python 3.0a2 is out and some people are working on backports of Python
> 3.0 features to 2.6. Shouldn't we start to rename the new API functions
> and files to their final names before we back merge code to 2.6?
> 
> I'm proposing to change the names and files as following. I'm willing to
> make the necessary changes myself.
> 
> API methods:
> PyUnicode - keep the name
> PyBytes - PyByteArray
> PyString - PyBytes
> PyBuffer - PyMemoryView
> 
> Files:
> bytesobject.[ch] - bytearrayobject.[ch]
> memoryobject.[ch] - memoryviewobject.[ch]
> stringobject.[ch] - bytesobject.[ch]

Also for this list:

classobject -> methodobject

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.