Ian Kelly :
> On Sat, Feb 7, 2015 at 5:45 PM, Albert van der Horst
> wrote:
>> x -> x**2
>> instead of
>> lambda x : x**2
>
> Well, I don't think the existing syntax is incompatible with your
> proposal. As it is, the -> token can only appear after the argument
> list of a def statement, so there
On Sat, Feb 7, 2015 at 5:45 PM, Albert van der Horst
wrote:
> It is too bad `` -> '' as a token is now taken.
> I wanted to propose to replace the ternary syntax
> lambda .. : ..
> by a regular operator
> .. -> ..
> then we could have
> x -> x**2
> instead of
> lambda x : x**2
Well, I don't th
On Sun, Feb 8, 2015 at 6:55 PM, Steven D'Aprano
wrote:
> If this were syntax, then the compiler could just as easily set the function
> name from -> as from def. Lambda has the limitations that it has because it
> is an expression, not because of magical "def" properties.
True, it could, but it w
Chris Angelico wrote:
> On Sun, Feb 8, 2015 at 11:45 AM, Albert van der Horst
> wrote:
>> def square(x): x**2
>> but
>> square = x->x**2
>>
>> or
>>
>> mult = x,y ->
>>result = 0
>>for i in range(x):
>> result +=y
>>return result
>>
>> doing away with the ternary operator def
>
On Sun, Feb 8, 2015 at 11:45 AM, Albert van der Horst
wrote:
> def square(x): x**2
> but
> square = x->x**2
>
> or
>
> mult = x,y ->
>result = 0
>for i in range(x):
> result +=y
>return result
>
> doing away with the ternary operator def
>
> def .. ( .. ) : ..
>
> replacing it b
In article ,
Ethan Furman wrote:
>-=-=-=-=-=-
>
>On 01/21/2015 08:30 PM, Steven D'Aprano wrote:
>>
>> So what is this unspeakable, nightmarish, cryptic abomination going to look
>> like? Here's an example from PEP 484:
>>
>> def greeting(name: str) -> str:
>> return 'Hello ' + name
>>
>>
>> I
Steven D'Aprano wrote:
I'm arguing with those who insist that objects of type MethodType aren't
methods, and objects of type FunctionType aren't functions but methods,
except when they are, based on that simplified, incomplete glossary entry.
I'm not arguing that based on the glossary entry. I
Steven D'Aprano wrote:
Er, perhaps "code injection" is not the best name for this, on account of it
also being the name for a security vulnerability anti-pattern:
I'm talking about a variety of dependency injection where you either add an
entirely new method to an instance, or give the instan
Steven D'Aprano wrote:
Gregory Ewing wrote:
If things worked the way you want, it would be
impossible to store a function in an instance
attribute and get it out again *without* it
being treated as a method
>
Not impossible, just inconvenient... the
solution is to use a custom descriptor
Bu
On Tuesday, February 3, 2015 at 4:05:57 PM UTC-6, Ian wrote:
> On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano wrote:
> > AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS!
>
> Careful there, you're starting to sound like Ranting Rick. ;-)
Ha! My meme's are far more catchy and intellectual. But as t
Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>> Right now Python generates the trampoline from the class prototype every
>> time you call a method. If the semantics allowed, you could create the
>> trampoline at instantiation time (for better or worse). That way, the
>> problem you seem to be refe
Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>> For (almost) all practical purposes, that is the Python way as well. If
>> object instantiation (conceptually) copied the class's methods into the
>> object's dict, you'd get the semantics I'm looking for.
>
> If things worked the way you want, it w
On 02/03/2015 03:32 PM, Marko Rauhamaa wrote:
> Gregory Ewing :
>
>> You seem to be suggesting an optimisation that pre-creates bound
>> methods when the instance is created. Keeping a cache of bound methods
>> would achieve the same thing without changing the semantics. I think
>> CPython might a
On 03/02/2015 23:32, Marko Rauhamaa wrote:
Gregory Ewing :
You seem to be suggesting an optimisation that pre-creates bound
methods when the instance is created. Keeping a cache of bound methods
would achieve the same thing without changing the semantics. I think
CPython might already be doing
On Wed, Feb 4, 2015 at 10:32 AM, Marko Rauhamaa wrote:
> No, I'm saying Python should behave differently.
>
> Python:
>
>>>> class A:
>...def f(self):
>... print("f")
>...def g(self):
>... print("g")
>...
>>>> a = A()
>>>> a.__class__.f = a.__cla
Gregory Ewing :
> You seem to be suggesting an optimisation that pre-creates bound
> methods when the instance is created. Keeping a cache of bound methods
> would achieve the same thing without changing the semantics. I think
> CPython might already be doing that, but I'm not sure.
No, I'm sayin
Marko Rauhamaa wrote:
Right now Python generates the trampoline from the class prototype every
time you call a method. If the semantics allowed, you could create the
trampoline at instantiation time (for better or worse). That way, the
problem you seem to be referring to wouldn't materialize.
S
On Wed, Feb 4, 2015 at 4:40 AM, Steven D'Aprano
wrote:
> given that the glossary need not be 100% complete and definitive, "function
> defined inside a class body" is close enough to the truth.
* This *
We are arguing, not about an element in a formal grammar, but about a
glossary entry. If one
On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano
wrote:
> AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS!
Careful there, you're starting to sound like Ranting Rick. ;-)
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
If some methods can be defined outside of the body of a class, then being
defined inside the body of a class does not define a method.
Nobody's disputing that. The business about super() is
just a possible reason for the glossary to define the
word 'method' in a more rest
Gregory Ewing :
> Marko Rauhamaa wrote:
>> For (almost) all practical purposes, that is the Python way as well. If
>> object instantiation (conceptually) copied the class's methods into the
>> object's dict, you'd get the semantics I'm looking for.
>
> If things worked the way you want, it would b
Marko Rauhamaa wrote:
For (almost) all practical purposes, that is the Python way as well. If
object instantiation (conceptually) copied the class's methods into the
object's dict, you'd get the semantics I'm looking for.
If things worked the way you want, it would be
impossible to store a func
Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 6:07 AM, Steven D'Aprano
> wrote:
>> Run this code:
>>
>> # === cut ===
>>
>> class K(object):
>> def f(self): pass
>>
>> def f(self): pass
>>
>> instance = K()
>> things = [instance.f, f.__get__(instance, K)]
>> from random import shuffle
>> s
Steven D'Aprano wrote:
In Python 2, they are methods. In Python 3, they are functions, and aren't
converted into methods until you access them via the instance:
They're methods in both cases. They don't have to be
"converted into methods"; they already are, by virtue
of their location and inte
Steven D'Aprano wrote:
Both K.f and K.g are methods, even though only one meets the definition
given in the glossary. The glossary is wrong.
Or rather, it is not so much that it is *wrong*, but that it is incomplete
and over-simplified.
I agree with that; a more complete definition would be
"a
Chris Angelico :
> On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa wrote:
>> It's slightly sad that Python exposes the two-level attribute lookup.
>> It would be more elegant if, conceptually, all methods were retrieved
>> from the object's attribute dict. That way, the class would be simply
>> a
On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa wrote:
> It's slightly sad that Python exposes the two-level attribute lookup. It
> would be more elegant if, conceptually, all methods were retrieved from
> the object's attribute dict. That way, the class would be simply a
> mundane optimization tri
Devin Jeanpierre :
> It isn't mystical. There are differences in semantics of defining
> methods inside or outside of a class that apply in certain situations
> (e.g. super(), metaclasses). You have cherrypicked an example that
> avoids them.
It's slightly sad that Python exposes the two-level at
On Mon, Feb 2, 2015 at 6:20 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>> Oops, I just realized why such a claim might be made: the
>> documentation probably wants to be able to say that any method can use
>> super(). So that's why it claims that it isn't a method unless it's
>> defined
On Mon, Feb 2, 2015 at 6:07 AM, Steven D'Aprano
wrote:
> Run this code:
>
> # === cut ===
>
> class K(object):
> def f(self): pass
>
> def f(self): pass
>
> instance = K()
> things = [instance.f, f.__get__(instance, K)]
> from random import shuffle
> shuffle(things)
> print(things)
>
> # === c
Devin Jeanpierre wrote:
> Oops, I just realized why such a claim might be made: the
> documentation probably wants to be able to say that any method can use
> super(). So that's why it claims that it isn't a method unless it's
> defined inside a class body.
You can use super anywhere, including
Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> wrote:
>> instance.f is a method by the glossary definition. Its type is identical
>> to types.MethodType, which is what I used to create a method by hand.
>
> You are assuming that they are both methods, just because t
On Mon, Feb 2, 2015 at 5:00 AM, Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> wrote:
>>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>>> wrote:
>> Both K.f and K.g are methods, even though only one meets the definition
>> given in the glossary. The glossary is
On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
wrote:
>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>> wrote:
> Both K.f and K.g are methods, even though only one meets the definition
> given in the glossary. The glossary is wrong.
I agree, it oversimplified and has made a useless distinc
Rustom Mody wrote:
> My point was more methodological/sociological than technical:
>
> Are these dunder methods as 'internal' as say the register-allocation used
> by a C compiler?
Dunder methods are implementation, not interface. If you are the class
author, then you care about the implementat
On Monday, February 2, 2015 at 10:57:27 AM UTC+5:30, Vito De Tullio wrote:
> Steven D'Aprano wrote:
>
> > Checking the REPL first would have revealed that [].__dir__ raises
> > AttributeError. In other words, lists don't have a __dir__ method.
>
> ?
>
> Python 3.4.2 (default, Nov 29 2014, 00:45:
On Monday, February 2, 2015 at 1:13:30 PM UTC+5:30, Paul Rubin wrote:
> Steven D'Aprano writes:
> > No apples and no oranges aren't the same thing, but if somebody is
> > expecting
> > no apples, and I give them no oranges instead, it would be churlish for
> > them
> > to complain that none of
Steven D'Aprano wrote:
> Both K.f and K.g are methods, even though only one meets the definition
> given in the glossary. The glossary is wrong.
Oh I'm sure somebody is going to pick me up on this...
In Python 2, they are methods. In Python 3, they are functions, and aren't
converted into metho
Devin Jeanpierre wrote:
> -- Devin
>
> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
> wrote:
>> Gregory Ewing wrote:
>>
>>> Steven D'Aprano wrote:
[quote]
If the object has a method named __dir__(), this method will
be called and must return the list of attributes.
Steven D'Aprano writes:
> No apples and no oranges aren't the same thing, but if somebody is expecting
> no apples, and I give them no oranges instead, it would be churlish for them
> to complain that none of them are the wrong kind of fruit.
https://davedevine.wordpress.com/2011/01/20/the-sart
-- Devin
On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
wrote:
> Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> [quote]
>>> If the object has a method named __dir__(), this method will
>>> be called and must return the list of attributes.
>>> [end quote]
>>>
>>> The first
Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> [quote]
>> If the object has a method named __dir__(), this method will
>> be called and must return the list of attributes.
>> [end quote]
>>
>> The first inaccuracy is that like all (nearly all?) dunder methods,
>> Python only loo
Paul Rubin wrote:
> Chris Angelico writes:
>> So since you can set something to Nothing regardless of type, and
>> compare it against Nothing regardless of type, it doesn't really much
>> matter that there are different types of Nothing. Right?
>
> No that's not how type inference works. If you
Chris Angelico writes:
> If you say "x = 5" and pass it to a function that accepts "Int or
> String", the compiler knows that it's actually an Int. If you then
> also pass that x to something that takes "Int or List", is that legal?
You'd have to do that with type classes, but yeah, the compiler
On Mon, Feb 2, 2015 at 5:07 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> So since you can set something to Nothing regardless of type, and
>> compare it against Nothing regardless of type, it doesn't really much
>> matter that there are different types of Nothing. Right?
>
> No that's not ho
Steven D'Aprano writes:
> if type(ptr) == A:
> if ptr != Anil: ...
> if type(ptr) == B:
> if ptr != Bnil: ...
> etc. That would be insane. So how does Haskell do this?
That wouldn't make sense in Haskell: the types are known at compile
time, so you wouldn't do that runtime switching on t
Chris Angelico writes:
> So since you can set something to Nothing regardless of type, and
> compare it against Nothing regardless of type, it doesn't really much
> matter that there are different types of Nothing. Right?
No that's not how type inference works. If you have x = Nothing and
pass i
Devin Jeanpierre wrote:
I answered my own question later, by accident: Java nulls are castable
to each other if you do it explicitly (routing through Object -- e.g.
(Something)((Object) ((SomeOtherThing) null.
So in that sense, there is only one null, just with some arbitrary
compiler distin
On Mon, Feb 2, 2015 at 4:19 PM, Gregory Ewing
wrote:
> In Haskell you would just go ahead and compare ptr
> with Nothing (or more likely pattern-match it against
> Nothing).
So since you can set something to Nothing regardless of type, and
compare it against Nothing regardless of type, it doesn't
Steven D'Aprano wrote:
> Checking the REPL first would have revealed that [].__dir__ raises
> AttributeError. In other words, lists don't have a __dir__ method.
?
Python 3.4.2 (default, Nov 29 2014, 00:45:45)
[GCC 4.8.3] on linux
Type "help", "copyright", "credits" or "license" for more informa
Steven D'Aprano wrote:
If I have an arbitrary pointer, and I want to check if it is safe to
dereference, how do I do it? Surely I'm not expected to write something
like:
if type(ptr) == A:
if ptr != Anil: ...
if type(ptr) == B:
if ptr != Bnil: ...
etc. That would be insane. So how doe
Steven D'Aprano wrote:
[quote]
If the object has a method named __dir__(), this method will
be called and must return the list of attributes.
[end quote]
The first inaccuracy is that like all (nearly all?) dunder methods, Python
only looks for __dir__ on the class, not the inst
On Monday, February 2, 2015 at 9:34:53 AM UTC+5:30, Rustom Mody wrote:
> On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> > On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > > Rustom Mody wrote:
> > >
> > > > The other day I was taking a class i
On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > Rustom Mody wrote:
> >
> > > The other day I was taking a class in which I was showing
> > > - introspection for discovering -- help, type, dir et
On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
>
> > The other day I was taking a class in which I was showing
> > - introspection for discovering -- help, type, dir etc at the repl
> > - mapping of surface syntax to internals eg. a + b ←→ a.__add__
Devin Jeanpierre wrote:
> So in that sense, there is only one null, just with some arbitrary
> compiler distinctions you can break through if you try hard enough.
Woo hoo! I was right!
*Dances the Dance of Victory!*
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Feb 1, 2015 at 2:27 PM, Paul Rubin wrote:
> Devin Jeanpierre writes:
>> That said, Haskell (and the rest) do have a sort of type coercion, of
>> literals at compile time (e.g. 3 can be an Integer or a Double
>> depending on how you use it.)
>
> That's polymorphism, not coercion.
OK, yes,
Devin Jeanpierre writes:
> That said, Haskell (and the rest) do have a sort of type coercion, of
> literals at compile time (e.g. 3 can be an Integer or a Double
> depending on how you use it.)
That's polymorphism, not coercion. The compiler figures out at compile
time what type of 3 you actuall
Steven D'Aprano writes:
> C has a single nil pointer compatible with all pointer types.
C++11 has a separate type just for the null pointer, which can be
automatically coerced to other pointer types. I'm not sure but I think
that means it is couthing up slightly.
http://en.cppreference.com/w/cp
On 2/1/2015 12:45 PM, Chris Angelico wrote:
Simple answer: You write dunder methods and the interpreter calls
them. You don't call them yourself.
I can't currently think of any situation where it's appropriate to
call a dunder method manually (cue the swamping of such situations on
the list); yo
On Sun, Feb 1, 2015 at 4:36 PM, Rustom Mody wrote:
> The other day I was taking a class in which I was showing
> - introspection for discovering -- help, type, dir etc at the repl
> - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
>
> And a student asked me the diff between
> dir
On Sun, Feb 1, 2015 at 8:31 AM, Steven D'Aprano
wrote:
> Paul Rubin wrote:
>> It's completely practical: polymorphism and type inference get you the
>> value you want with usually no effort on your part.
>
> But it's the "usually" that bites you.
>
> If I have an arbitrary pointer, and I want to c
On Sun, Feb 1, 2015 at 9:55 AM, Steven D'Aprano
wrote:
> Steven D'Aprano wrote:
>
>> len tries to call __len__ if it exists, and if not, it tries walking the
>> iterable counting items.
>
> Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby.
I think you just got it backward. iter
Steven D'Aprano wrote:
> Devin Jeanpierre wrote:
>
>> It's really only dynamically typed languages that have a single null
>> value of a single type. Maybe I misunderstand the original statement.
>
> Pascal is statically typed and has a single null pointer compatible with
> all pointer types.
Steven D'Aprano wrote:
> len tries to call __len__ if it exists, and if not, it tries walking the
> iterable counting items.
Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Feb 1, 2015 at 8:34 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>
>> It's really only dynamically typed languages that have a single null
>> value of a single type. Maybe I misunderstand the original statement.
>
> Pascal is statically typed and has a single null pointer compatibl
Devin Jeanpierre wrote:
> It's really only dynamically typed languages that have a single null
> value of a single type. Maybe I misunderstand the original statement.
Pascal is statically typed and has a single null pointer compatible with all
pointer types. C has a single nil pointer compatible
Paul Rubin wrote:
> Steven D'Aprano writes:
>> Some degree of weakness in a type system is not necessarily bad. Even the
>> strongest of languages usually allow a few exceptions, such as numeric
>> coercions.
>
> Haskell doesn't have automatic coercions of any sort. You have to call
> a convers
Rustom Mody wrote:
> The other day I was taking a class in which I was showing
> - introspection for discovering -- help, type, dir etc at the repl
> - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
>
> And a student asked me the diff between
> dir([])
> and
> [].__dir__()
>
>
On 01/31/2015 09:36 PM, Rustom Mody wrote:
>
> And a student asked me the diff between
> dir([])
> and
> [].__dir__()
>
> I didnt know what to say...
> Now surely the amount of python I dont know is significantly larger than what
> I know
> Still it would be nice to have surface-syntax ←→ dunder
Sorry, sort of responding to both of you.
On Sat, Jan 31, 2015 at 10:12 PM, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Some degree of weakness in a type system is not necessarily bad. Even the
>> strongest of languages usually allow a few exceptions, such as numeric
>> coercions.
>
> Haskell
Steven D'Aprano writes:
> Some degree of weakness in a type system is not necessarily bad. Even the
> strongest of languages usually allow a few exceptions, such as numeric
> coercions.
Haskell doesn't have automatic coercions of any sort. You have to call
a conversion function if you want to tu
On Sunday, February 1, 2015 at 10:15:13 AM UTC+5:30, Ethan Furman wrote:
> On 01/31/2015 07:16 PM, Steven D'Aprano wrote:
> >
> > But by default, Python will fallback on __repr__ if __str__ doesn't exist,
> > or __str__ if __repr__ doesn't exist, or both. Or something. (I always
> > forget what th
On 01/31/2015 07:16 PM, Steven D'Aprano wrote:
>
> But by default, Python will fallback on __repr__ if __str__ doesn't exist,
> or __str__ if __repr__ doesn't exist, or both. Or something. (I always
> forget what the rules are exactly.)
If __str__ is missing, __repr__ is called.
If __repr__ is m
On Sun, Feb 1, 2015 at 2:16 PM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
>> wrote:
>>> Both ints and floats are models of the same abstract thing, namely
>>> "number". Ideally, from a mathematically standpoint, there should be no
>>> di
Chris Angelico wrote:
> On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
> wrote:
>> Both ints and floats are models of the same abstract thing, namely
>> "number". Ideally, from a mathematically standpoint, there should be no
>> difference between 23 and 23.0. Automatic coercions allow us to ge
Mario Figueiredo wrote:
> In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> Why should I feel guilty? You wrote:
>>
>>
>> "Static analysis cannot and should not clutter executable code."
>>
>>
>> But what are type declaratio
On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
wrote:
> Both ints and floats are models of the same abstract thing, namely "number".
> Ideally, from a mathematically standpoint, there should be no difference
> between 23 and 23.0. Automatic coercions allow us to get a little closer to
> that id
random...@fastmail.us wrote:
> On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote:
>> Bar language, on the other hand, tries extremely hard to ensure that
>> every
>> type is automatically able to be coerced into every other type. The
>> coercion might not do what you expect, but it will do *so
On Fri, Jan 30, 2015 at 11:42 AM, Mario Figueiredo wrote:
> To be clear, type declarations in Julia, Scala, C have the potential to
> produce side-effects, can result in optimized code and can result in
> compile time errors or warnings. They also affect runtime evaluation as
> you could easily at
On Fri, Jan 30, 2015 at 12:50 PM, Mario Figueiredo wrote:
> It would help that if instead of weakly typed or strongly typed box,
> they could be classified comparatively to each other. The terms are
> better suited to describe two languages as they stand to each other.
>
> Weakly Typed --
In article ,
breamore...@yahoo.co.uk says...
>
> No, they're not always weakly typed. The aim of the spreadsheet put up
> by Skip was to sort out (roughly) which languages belong in which camp.
> I do not regard myself as suitably qualified to fill the thing out.
> Perhaps by now others hav
In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
>
> Why should I feel guilty? You wrote:
>
>
> "Static analysis cannot and should not clutter executable code."
>
>
> But what are type declarations in statically typed languages
In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
> Why should I feel guilty? You wrote:
>
>
> "Static analysis cannot and should not clutter executable code."
>
>
> But what are type declarations in statically typed languages lik
On 2015-01-29 23:25, Chris Kaynor wrote:
On Thu, Jan 29, 2015 at 2:57 PM, BartC wrote:
[snip]
Putting in hints, (as as I implemented them using primitive types),
meant that functions and code no longer worked in a generic (or
polymorphic) manner. Code also changes, but the type hints aren't
ma
On Thu, Jan 29, 2015 at 2:57 PM, BartC wrote:
> I've read most of the thread but haven't been able to figure out /why/ this
> is being proposed. What is the advantage, speed?
Check out the rationale part of the PEP:
https://www.python.org/dev/peps/pep-0484/#rationale-and-goals. Other
parts of the
On Fri, Jan 30, 2015 at 9:57 AM, BartC wrote:
> I've read most of the thread but haven't been able to figure out /why/ this
> is being proposed. What is the advantage, speed?
Have a read of the PEP:
https://www.python.org/dev/peps/pep-0484/
ChrisA
--
https://mail.python.org/mailman/listinfo/py
On 22/01/2015 04:30, Steven D'Aprano wrote:
https://www.python.org/dev/peps/pep-0484/
Here's a potential real-world example, from the statistics module in Python
3.4, before and after adding annotations:
def median_grouped(data, interval=1): ...
def median_grouped(data:Iterable[Real], inter
On Thursday, January 29, 2015 at 10:11:56 AM UTC-6, Steven D'Aprano wrote:
>
> But what are type declarations in statically typed
> languages like C, Pascal, Haskell, etc.? They are used by
> the compiler for static analysis. The same applies to type
> declarations in dynamically typed languages li
On 29/01/2015 18:23, random...@fastmail.us wrote:
Statically typed lanugages by definition can never give you a TypeError
- there are no runtime conversions that can succeed or fail based on the
type of the arguments. What makes a statically typed language strong or
weak? Are statically typed la
On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote:
> Bar language, on the other hand, tries extremely hard to ensure that
> every
> type is automatically able to be coerced into every other type. The
> coercion might not do what you expect, but it will do *something*:
See, this is where the co
Mario Figueiredo wrote:
> In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> Ian, that's obvious. Just open your eyes:
>>
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>>
>> Python
>> def addInt( a:int, b:int ) -> int:
>>
>>
>
On Thu, Jan 29, 2015 at 1:34 AM, Mario Figueiredo wrote:
> In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> Ian, that's obvious. Just open your eyes:
>>
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>>
>> Python
>> def addInt( a:
Mario Figueiredo wrote:
> In article ,
> breamore...@yahoo.co.uk says...
>>
>> C and C++ are weakly and statically typed languages. Python is a
>> strongly and dynamically typed language. Therefore anything following
>> based on the above paragraph alone is wrong.
>>
>
> Indeed. I confused st
random...@fastmail.us wrote:
> On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote:
>> C and C++ are weakly and statically typed languages.
>
> "strong typing" has no meaning at all, and "weak typing" means "anything
> I don't like".
I see you've been reading Chris Smith's essay on typing :-)
h
On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote:
> C and C++ are weakly and statically typed languages.
"strong typing" has no meaning at all, and "weak typing" means "anything
I don't like".
The fact that you can add an int and a float, or that you can use any
object as a boolean, would make
On 29/01/2015 08:23, Mario Figueiredo wrote:
In article ,
breamore...@yahoo.co.uk says...
C and C++ are weakly and statically typed languages. Python is a
strongly and dynamically typed language. Therefore anything following
based on the above paragraph alone is wrong.
Indeed. I confused s
In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
> Ian, that's obvious. Just open your eyes:
>
> Scala
> def addInt( a:Int, b:Int ) : Int
>
> Python
> def addInt( a:int, b:int ) -> int:
>
>
> They're COMPLETELY different. In Scal
In article ,
breamore...@yahoo.co.uk says...
>
> C and C++ are weakly and statically typed languages. Python is a
> strongly and dynamically typed language. Therefore anything following
> based on the above paragraph alone is wrong.
>
Indeed. I confused strongly/weakly with static. I feel a
On Thu, Jan 29, 2015 at 11:37 AM, Steven D'Aprano
wrote:
> They're as
> different as cheese and a very slightly different cheese. Do try to keep
> up.
As different as brie and camembert?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
1 - 100 of 268 matches
Mail list logo
