On 4/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> This is worth thinking about. Recently when pondering the
> question of when it would or would not be appropriate to
> put in type assertions to help catch bugs, I concluded
> that it makes the most sense to do so when building a
> data structure,
On 4/21/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Another (similar) way would be to let the user pay for the high typechecking
> price in normal cases *but* provide a list[int] class, which is a list
> decorated with typechecks on modification operations. We could have
> list[int|float]() to
On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote:
...
>
> No. This is the kind of thing that would very quickly turn "optional"
> typing into *mandatory* typing. One library package adds type
> declarations. Now all packages that use it are required to either add
> type declarations or explicit
On Sat, 22 Apr 2006 03:12 am, Jim Jewett wrote:
> On 4/20/06, Birch, Bill <[EMAIL PROTECTED]> wrote:
> > Type comparison operators would only need a deep
> > inspection of the types when the godel strings don't match.
> > If most comparisons will be an exact match (not a subtype)
> > the lookup sho
> Guido van Rossum wrote:
> If I have some utterly dynamic
> code that comes up with a list of a million ints, and then I pass
> that
> as an argument to a function that requests the argument type is
> list[int],
>
> you wrap it in something that checks elements for intness
> as you access
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> Greg Ewing canterbury.ac.nz> writes:
>
> > Giovanni Bajo wrote:
> >
> > > Another (similar) way would be to let the user pay for the high
> > > typechecking
> > > price in normal cases *but* provide a list[int] class, which is a list
> > > decorated
Greg Ewing canterbury.ac.nz> writes:
> Giovanni Bajo wrote:
>
> > Another (similar) way would be to let the user pay for the high typechecking
> > price in normal cases *but* provide a list[int] class, which is a list
> > decorated with typechecks on modification operations. We could have
> > li
Giovanni Bajo wrote:
> Another (similar) way would be to let the user pay for the high typechecking
> price in normal cases *but* provide a list[int] class, which is a list
> decorated with typechecks on modification operations. We could have
> list[int|float]() to construct a list which can hold
Giovanni> One way would be to keep boolean flags like "is this a list of
Giovanni> integers". It could be updated after each list modification,
Giovanni> so that typechecks come for (almost) free.
Where would that be done? If it's in the untyped function in Guido's
example, how does
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But let me point out that the key concern I have about the expense of
> type checking is what would be done when unchecked code calls a
> function with type-checked arguments. If I have some utterly dynamic
> code that comes up with a list of a million
Guido van Rossum wrote:
> This seems a good idea to remember when we get to that point.
>
> But let me point out that the key concern I have about the expense of
> type checking is what would be done when unchecked code calls a
> function with type-checked arguments. If I have some utterly dynamic
On 4/20/06, Birch, Bill <[EMAIL PROTECTED]> wrote:
> Type comparison operators would only need a deep
> inspection of the types when the godel strings don't match.
> If most comparisons will be an exact match (not a subtype)
> the lookup should be faster.
If you're assuming that, then just checki
On Apr 21, 2006, at 8:36 AM, Greg Ewing wrote:
> Guido van Rossum wrote:
>> If I have some utterly dynamic
>> code that comes up with a list of a million ints, and then I pass
>> that
>> as an argument to a function that requests the argument type is
>> list[int],
>
> you wrap it in something th
Building from Aahz's example, what you really want is a mechanism
for typechecking that any accessed elements are ints when dynamic
code generates a list of a million elements and passes it to a
function declared to take a parameter of type "list[int]". And
then make sure the following two examples
On Sat, Apr 22, 2006, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> If I have some utterly dynamic code that comes up with a list of a
>> million ints, and then I pass that as an argument to a function that
>> requests the argument type is list[int],
>
> you wrap it in something that checks ele
On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > If I have some utterly dynamic
> > code that comes up with a list of a million ints, and then I pass that
> > as an argument to a function that requests the argument type is
> > list[int],
>
> you wrap it in something t
Guido van Rossum wrote:
> If I have some utterly dynamic
> code that comes up with a list of a million ints, and then I pass that
> as an argument to a function that requests the argument type is
> list[int],
you wrap it in something that checks elements for intness
as you access them. It'll still
This seems a good idea to remember when we get to that point.
But let me point out that the key concern I have about the expense of
type checking is what would be done when unchecked code calls a
function with type-checked arguments. If I have some utterly dynamic
code that comes up with a list of
With reference to the last Gfdl blog on type checking
(http://www.artima.com/weblogs/viewpost.jsp?thread=87182). There is concern
that type comparison at runtime using objects will be quite expensive, so this
posting is about optimisation.
An idea is to compute a single canonical string which su
19 matches
Mail list logo
