SVN revision[3] (assert_type
will go into the upcoming 0.4 release) so all interested parties can
play around with this.
[1] - http://oakwinter.com/code/typecheck/
[2] - http://oakwinter.com/code/typecheck/dev/tutorial/assert_type.html
[3] - http://oakwinter.com/code/typecheck/dist/typecheck-svn-lat
sible to make the TypeError
-> ArgumentError changeover in Python 2.6.
I'm more than willing to work up a PEP and patches for this if there's interest.
Collin Winter
___
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
ntuitive in Python.
> I don't really have a preference here - the current error is a little obscure,
> but I'm not sure fixing it is worth the effort of adding a new exception type.
I would think that eliminating this obscurity is worth the minimal
overhead of a single new exception
On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/5/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 5/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > > The Type Error is actually referring to the type of 'foo' - the code is
>
On 5/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/6/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I'm not sure it's worth distinguishing call signature errors from
> > &g
On 5/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/7/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > This -- more intuitive error messages -- is really what I'm after, and
> > while you may think of type of "def foo(a, b, c):..." as "a f
e others view them as a data
structures unto themselves. My question: will (0,), (0, 1) and (0, 1,
2) all match (int,) (frozen list view), or are (int,), (int, int) and
(int, int, int) totally separate datatypes (more of a functional
programming view)?
Thanks,
Collin Winter
[1] - http://billbir
e that the
default in Python 3000. Of course, the question still remains what
mode 2.x should default to.
Collin Winter
___
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
es. (To read about all of typecheck's
annotation classes, see [5].)
Is there interest in including a hook-based system like this in Python
2.x and 3.x's respective type annotation systems?
Thanks,
Collin Winter
[1] - http://oakwinter.com/code/typecheck/dev/utility/function.html
[2] - http://o
t, "->" would be replaced with "returns":
"""def foo(a: int, b: float, c: int = 5) returns list[int]"""
To combat overly long lines, users could wrap the annotation clauses
to the next line:
"""
def my_range(min: Num
On 5/18/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
>
On 5/18/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > So, reasoning by analogy would point to something like
> > Generator(is_sent=int, yields=int).
>
> You'd probably want this to be Iterator(...) instead of Generator(...),
> sinc
On 5/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
>
On 5/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
>
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > I'd like to see the typechecking machinery ignore differences like
> > "real type" v "pseudo type", looking only at whether,
iate __parameterize__ method.
Not being able to reuse the BinaryTree class like this leads to things
like CheckBinaryTree(int) or something equally unpleasant.
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailma
eck [3] (with docs for Function() [4]). This
is by no means set in stone, so comment away. The main point I'm not
entirely happy with: the use of star() and double_star() methods to
indicate types for *vargs and **kwargs, respectively.
If you like this general approach to handling Function()
arameters, which I'm
having trouble finding useful use cases for. Every example I come up
with -- including the two at the top of this post -- can be reduced to
your .T idea.
I'm going to do a branch of typecheck to play around with this
parameterization syntax; I'll let you know ho
as
keywords, thus making explicit your intention to use excess positional
and/or keyword arguments.
Collin Winter
___
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
On 5/19/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Collin Winter" <[EMAIL PROTECTED]> writes:
> > 2. Similarly, annotation classes might want to do more complex
> > parameter validation. Or(), for instance, might want to assert tha
u differentiate between this and wanting to assert that 'a'
is a 2-tuple with a first element of type int and a second element of
type str?
> (2) Defining the complex predicate before using it
>
> def int_or_str(arg):
> ret
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > ... what do you think of ... having bracket-based parameterization be
> > redirected a call to some double-underscore method
>
> It already is -- to
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > (1) Just use a tuple, and put the smarts in your decorator if you
> > > need
I've never imagined that any of the type system would
translate into bytecode. I believe one of Guido's blog posts mentions
that the type information will be available from the callable's
__signature__ attribute.
Collin Winter
___
Python-3000
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > dict(normal=check3)["normal"] is not the same as dict["normal"] --
>
> Yes, they are. They both call __getitem__.
>
> __get
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Use of positional arguments to parameterize dict, e.g., dict[str,
> > Number], is ugly, but keyword arguments would allow the prettier
> > dict[ke
x27;t have one.
Let's go back to Function(, , ..., returns=) for
now. I'll change my own implementation of Function() to match this,
and if people start hollering at me after the next release of
typecheck, wanting vargs, kwargs and/or keyword argument support, then
we can reconsider it
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > As a quick data point, I showed around your "dict[str, str|int]"
> > example to some friends, all of whom have done a decent amount of
&
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> Let's go back to Function(, , ..., returns=)
I just finished converting typecheck's test suite to use this
notation, and I have the following to report: ick.
The main problem is when the function returns a complex type
two ints as tuple[int, int]
> though? Is (int, int) now just an alias for that or does it have a
> different meaing?
I think that returns() is smart enough to know that "returns((int,
int))" is the same as "returns(int, int)". It will know to do
something si
), it would be better to let the third-party libraries
provide their own issubtype() and issupertype() functions.
3. What will annotations on *varargs and **varkw look like? My own
suggestion is that
>>> def foo(a: , *varargs: , **varkw: )
is fully equivalent to -- and is indeed coerced to --
&g
lications somewhere. Maybe it is and I just couldn't find it?
I haven't done any real performance analysis on my system. My focus so
far has been getting things working the way I want, saving the
performance issue for later.
Collin Winter
___
Py
ion, then the CPython core should switch over to
this mindset as well. The fact that Python 2.x uses a tuple for
*varargs has caused me to jump through a number of hoops in my own
typecheck package.
If there's interest, I can put together a separate PEP on this issue
that lists all the pla
self.__class__(self.__name__, (self,), {})
newcls.T = arg if is_annotation(arg) else type(arg)[arg]
return newcls
Collin Winter
___
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
On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, May 21, 2006, Collin Winter wrote:
> >
> > This is something I've been meaning to bring up: if we're serious
> > about the "tuples = fixed-length collections, lists = unknown-length
> > collec
es this need to go through a full PEP process?
Collin Winter
___
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
On 5/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 5/22/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > One thing I've run into several times in this process is the use of
> > >
On 5/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/22/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > The main use case I'm thinking of is parameterizing mapping types. Say
> > I wanted a set of Number lists: in Python 2, I'd just convert the
>
t;
Since _C under Python 3 will be new-style, type(_C()) is _C, not (as in 2.x).
Is there interest in keeping new.instance()'s functionality (that is,
in allowing users to create instances of a type, bypassing __init__ in
the process)?
Collin Winter
___
On 5/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It should be discarded. You can already create instances bypassing
> __init__ by calling __new__.
SF patch #1495675 (http://python.org/sf/1495675) does the trick; I've
assigned it to yo
(and their tests and docs) be updated to use lists? The
former introduces extra implementation complexity, while the latter
adds backwards compatibility issues.
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mai
adjustments should be
made. Most of the changes involve the test suite, primarily where
higher-order functions are concerned.
I've submitted a patch to implement this change as SF #1498441
(http://python.orf/sf/1498441); it's assigned to Guido.
Collin Winter
__
: 1.87
As list: 2.15
./python -mtimeit 'def foo(*args): pass' 'foo(1, 2, 3)'
As tuple: 1.95
As list: 2.3
./python -mtimeit 'def foo(*args): pass' 'foo(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)'
As tuple: 2.67
As list: 2.97
Collin Winter
On 6/1/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Collin Winter writes:
> > I've attached the benchmarks as a comment on the patch, but I'll
> > repeat them here. All times are usecs per loop.
> [statistics showing list is about 15% slower]
>
&
/dicts/etc instead of the tuple[]/list[]/dict[]
spelling completely removes the issue of mixing parameterised and
non-parameterised expressions.
To sum up: I propose that -- to combat these issues -- I limit the PEP
to discussing how to supply annotations (the annotation syntax and C
API) and how
the builtins bool() and abs()?
Collin Winter
___
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
On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > PEP 3100 mentions that isCallable() and sequenceIncludes() are to be
> > removed from the operator module in Python 3000 because there are
> > bett
On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> +
But you can't pass a plus sign to higher-order functions.
> On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 7/3
On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > > Stupid que
On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > It turns out I was misled by Collin's claim that the PEP wants
> > isCallable and sequenceIncludes removed "because there are better,
> > m
allable() wouldn't be able to ship in __builtin__.
Collin Winter
___
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
rse, there is still the problem of passing the arguments to the
> inner function - but that's no worse than the problem that decorators
> have today.
I don't understand; what kind of decorators do you write that have this problem?
> For example, '@overload(int,int,a=int)
large on-disk file or CD or whatever else, you can add custom tests
for hashability yourself. There's no need to clutter the language to
cater to every odd corner case someone digs up.
Collin Winter
PS: A read-only disk file has the same problem that Nick pointed out
with your CD example, namely
ught one of the main arguments in favor of set literals is that a
literal form would allow the compiler to perform optimisations that
the set(...) spelling doesn't allow.
Collin Winter
___
Python-3000 mailing list
[email protected]
http:
tations
Version: $Revision: 43251 $
Last-Modified: $Date: 2006-03-23 09:28:55 -0500 (Thu, 23 Mar 2006) $
Author: Collin Winter
Discussions-To: [email protected]
Status: Draft
Type: Standards Track
Requires: 3XXX (Brett Cannon's __signature__ PEP)
Content-Type: text/x-rst
Created: 03-Aug
On 8/9/06, Talin <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> >There is no worry that these libraries will assign semantics at
> >random, or that a variety of libraries will appear, each with varying
> >semantics and interpretations of what, say, a tu
On 8/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> >one library might use string-based annotations to provide
> >improved help messages, like so:
> >
> > def compile(source: "something compilable",
> >
ake
function = dec(function)
function.__signature__.annotations = original
return function
return decorate
A similar function can be worked out for using dictionaries to specify
multiple annotations.
I'll update the PEP draft to include a section on guidelines for
writing su
enter comes up
> with their own unique solution to a problem which should have been
> solved in the original standard doc.
Are you referring to the fact that the PEP doesn't dictate how lists,
tuples, etc are to be interpreted, or still to the fa
ction prototype, and while I
think I'm in the direction of understanding, I'm not quite there 100%.
Could you illustrate (in code) what you've got in mind for how to
apply overloaded functions to this problem space?
Collin Winter
___
Pyt
t annotations."
Does this mean all lists "are to be used for attaching multiple
independent annotations", or just top-level lists (ie, "def foo(a: [x,
y])" indicates two independent annotations)? What does "def foo(a: [x,
[y, z]])" indicate?
Collin Winter
_
ent, or
does it match all tuples that have only Number elements?
Regardless of which you pick, somebody's going to be pissed.
> Second, we can decide to do the standardization at any point.
Um, "at any point"? You mean it's conceivable that this
standardisation could come
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > > Second, we can decide to do the standardization at any point.
> >
> > Um, &qu
ut whether a
given consumer should be provided an `annotations` argument. (It is up
to multiple_annotations() to decide whether "consumer.__name__ in
per_parameter_annotations == False" should raise an exception.)
Collin Winter
___
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
On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > The problem with using lists is that its impossible for non-decorator
> > annotation consumers to know which element "belongs" to them.
>
> The
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > The problem with using lists is that its impossible for non-decorator
> > > annota
ools, but also on those wishing to use these tools.
I want people to be able to use Python's built-in types without ugly
wrapper classes or any other similar impediments to their pre-existing
Python workflow/thought patterns.
Collin Winter
___
Py
On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Extending this same idea to static analysis tools, tools like
> > pychecker or an optimising compiler would have to supply their own
> > such wrapper cla
ard wrapper for each application of function annotations. How is
this significantly better than my dict-based approach, which uses
standardised dict keys to indicate the kind of metadata?
Collin Winter
___
Python-3000 mailing list
[email protected]
ht
On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > How is
> > this significantly better than my dict-based approach, which uses
> > standardised dict keys to indicate the kind of metadata?
>
> The
On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
>> 1) Static analysis tools (pychecker, optimising compilers, etc) must
>> be able to use the annotations
>
> As in any example given so far, the annotatio
bout how to multiple things
with annotations at the same time. Restricting annotations to type
information would be fine by me.
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscr
On 8/16/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:09 AM 8/16/2006 -0500, Collin Winter wrote:
> >On 8/15/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>Personally, I thought Guido's original proposal for function annotations,
> >>whic
ish. Consider the dict-based proposal withdrawn.
Apologies for my part in dragging this discussion into a triple-digit
comment count : )
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-300
he end of the
> > shortest input (like zip()) instead of at the end of the longest input
>
> May I suggest an additional keyword(-only?) argument to get the old behavior,
> stopping at the end of the longest input?
I thought map() and filter() were goi
On 8/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/21/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > I thought map() and filter() were going away in Py3k? Did that change?
>
> I still find them useful when using a built-in function, and unlike
> reduc
tiple sequences now that we have
> starmap and (i)zip?
FWIW, I'm ambivalent as to whether map() accepts multiple sequences,
but I'm strongly in favor of map(None, ) disappearing. Similarly,
I'd want to see filter(None, ...) go away, too; fastpathing the case
of filte
)" or find some other
> > way. I think I don't care. Do others? Collin?)
>
> That's fine with me, but just to toss out another idea: we could put the
> return annotation in func_annotations['return'].
This is the solution I had initially envisioned, for exactly
ey work and use them without a
> second thought.
I'm not sure people who ignore the big "Because of multithreading
semantics, this is not reliable" warnings should be catered to. Since
others have contributed use-cases for qsize()
an essential
> part of the semantics - and I'm inclined to say "no".
You're asking if it would be possible to automatically turn "x in [a,
b, c]" into "x in {a, b, c}"? If so, the answer is no: x may be
unhashable.
Collin Winter
___
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
enamed to
> "kwargs".
Is it conflicting with something you're doing or this just a personal
aesthetic preference?
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
U
ecursive system, and as
such bombs out when it encounters, e.g., files with a thousand
assignment statements in a row. I'd also like something more
expressive: the current DSL can't express recursive patterns.
Collin Winter
___
Python-3000 ma
On Sun, Mar 16, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Cool! Is the next plan to make lib2to3 part of the stdlib in 2.6 and 3.0?
That would be fine by me. I'll try to work up some better docs than
just a README.
> On Sun, Mar 16, 2008 at 2:47 PM, "Martin v. Löwis" <[EMAI
On Sun, Mar 16, 2008 at 10:17 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > The biggest win in terms of performance would be to reimplement the
> > pattern matching engine used by the fixers.: it by far dominates the
> > running time, taki
975: parens not removed from print(),
> please use 3to4 converter instead
>
> Thoughts?
Are you talking about the 3to2 written by the PyPy people
(http://morepypy.blogspot.com/2008/04/trying-to-get-pypy-to-run-on-python-30.html)?
You should ask them, since that's the
On Mon, Apr 28, 2008 at 7:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> [bcc to stdlib-sig]
>
> After two false starts over the YEARS of trying to cleanup and
> reorganize the stdlib, creating a SIG to get this going, having Guido
> give the PEP the once-over over the past several days, and c
On Thu, May 1, 2008 at 11:02 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Thu, May 1, 2008 at 7:41 AM, Collin Winter <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Apr 28, 2008 at 7:30 PM, Brett Cannon <[EMAIL PROTECTED]> w
On Fri, May 30, 2008 at 6:33 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Guido van Rossum python.org> writes:
>> I would be okay as well with restricting bare raise syntactically to
>> appearing only inside an except block, to emphasize the change in
>> semantics that was started when we decid
On Sat, May 31, 2008 at 6:08 PM, Mark Hammond <[EMAIL PROTECTED]> wrote:
> Antoine:
>> Mark Hammond skippinet.com.au> writes:
>> > In both Python 2.x and 3 (a few months old build of Py3k though), the
>> > traceback isn't the same. For Python 2.0 you could write it like:
>> >
>> > def handle_exce
not to INCREF their argument? It
>> means
>> the caller has to do it himself, and seems inconsistent with most of
>> Python's C
>> API. Is it too late to change those functions to do the right thing?
>
> I'm guessing Collin Winter designed it when he impleme
27;__init__',
>> '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
>> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
>> '__subclasshook__'
On Thu, Jul 24, 2008 at 9:39 PM, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
>> The intended upgrade path is through 2.6.
>> If you go straight from 2.5, you don't get
>> to go through a step with the -3 warnings
>> and optional text/bytes annotations.
>>
>> IMO, it would be
27;s really not Python any more". Agreed.
I could say You Aren't Going to Need It, but that gets the tense
wrong; we're getting along without annotations quite nicely here in
the present. In short: I'd like to request that PEP 3107 be rejected
as an overly-specific, unnecess
ar: int, baz: str)
> ...
Is whatever savings you see there worth changing the language for? Is
function overloading really that important and that common?
I'm still not convinced that the language syntax should change to make
life a tiny bit easier for third-party libraries. Not ever
On 1/2/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:48 PM 1/2/2007 -0600, Collin Winter wrote:
> >Is whatever savings you see there worth changing the language for? Is
> >function overloading really that important and that common?
>
> Ah, but now you're ma
On 1/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:06 AM 1/3/2007 -0600, Collin Winter wrote:
> >PS: I think it's interesting how nearly all the use-cases mentioned
> >involve adding type information to functions.
>
> Um, yeah, that was kind of the idea.
a patch for PEP 3107 that
will include a "possible use cases" section.
Consider my objection dropped.
Thanks,
Collin Winter
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
ht
The transformation is as Phillip outlined above, with extra logic to
handle the case where e is a tuple or list.
Thanks,
Collin Winter
___
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
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >The transformation is as Phillip outlined above, with extra logic to
> >handle the case where e is a tuple or list.
>
> In the tuple or list case, there'
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
> >On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >> >The transformation is as P
1 - 100 of 219 matches
Mail list logo
