Well one thing this fixes is removal of unneeded overloading, which is an admitted problem with builtin types doubling as factories. The special method doesn't have to be __coerce__, and as a matter of fact something better named would probably be more appropriate.
On 7/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > > On 7/6/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > I would like to propose a syntax that would explicitly be read as > > "Create an object of Foo converted from object Bar". Being explicit, > > as such, could bring about some interesting optimizations in the > > future or immediately, and reduce redundant signatures (such as the > > type(foo) syntax). I understand this is likely to be given some > > negative comments, but I am interested in everyone's thoughts on the > > idea. > > > > # Coerce an object into its type > > type from foo > > > > # Create a list from some iterable > > list from bar > > > > Obviously you can see I propose the use of the 'from' keyword to mean > > "create this from that". This would not translate directly to > > type(foo) and list(bar), however, but would look for a new special > > method, named '__coerce__', and would pass the original object to this > > method to request a coerced instance of the desired type (or > > interface). This special method, which is explicitly for coercing from > > other types, can do more explicit things when we know exactly what we > > are coercing, rather than just creating a new instance. > > > > # Gives a mutable string interface to a file-like object > > string from some_file > > # Would create a new string, iterating over the file-like object > > string(some_file) > > # Where 'string' is some generic mutable string type. > > > > The same syntax could be used to implement other things, such as > > key-from-value operations: > > > > # Get the first index of a value in a list > > idx = 'b' from ['a', 'b', 'c'] > > assert idx == 'b' > > > > In this example, 'b' would not have a __coerce__ method of its own as > > an instance, and the list instance's __rcoerce__ would be called to > > acquire the index. > > > We just removed __coerce__ from Py3K. =) > > Anyway, I don't see how this will allow for any special optimization since > it will still be calling a method on the object (constructor or otherwise) > and that cannot be optimized away easily. Plus, what is wrong with passing > on object to a type/class' constructor: ``str(42)``? Not redundant and it's > still clean, obvious, and does not require new syntax. > > > -Brett _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
