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
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 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
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:
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
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 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
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.
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
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 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
Ian Kelly wrote:
> On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo
> wrote:
>> In article <54c83ab4$0$12982$c3e8da3$54964...@news.astraweb.com>,
>> steve+comp.lang.pyt...@pearwood.info says...
>>>
>>> Mario Figueiredo wrote:
>>>
>>> > Static analysis cannot and should not clutter executable cod
On Wed, Jan 28, 2015 at 12:34 PM, Skip Montanaro
wrote:
>
>
> On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence
> wrote:
>>
>> C and C++ are weakly and statically typed languages. Python is a strongly
>> and dynamically typed language.
>
>
> Feel free to edit this Google spreadsheet:
Man, somet
On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence
wrote:
> C and C++ are weakly and statically typed languages. Python is a strongly
> and dynamically typed language.
Feel free to edit this Google spreadsheet:
--
https://mail.python.org/mailman/listinfo/python-list
On 28/01/2015 15:04, Mario Figueiredo wrote:
In article <54c83ab4$0$12982$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
Mario Figueiredo wrote:
Static analysis cannot and should not clutter executable code.
(1) It isn't clutter. The human reader uses that
On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo wrote:
> In article <54c83ab4$0$12982$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> Mario Figueiredo wrote:
>>
>> > Static analysis cannot and should not clutter executable code.
>>
>> (1) It isn't clutte
In article <54c83ab4$0$12982$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
> Mario Figueiredo wrote:
>
> > Static analysis cannot and should not clutter executable code.
>
> (1) It isn't clutter. The human reader uses that information as well as the
> compi
On Tue, Jan 27, 2015 at 7:26 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go,
> Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens
> (hundreds?) of other languages disagree with you.
>
Mario Figueiredo wrote:
> Looking at PEP 3107, i'm left wondering: what if I have for instance
> already annotated my functions for parameter marshalling, following the
> syntax expected of that specific library, and now I want to annotate
> them for type hinting for the purposes of static analysi
Mario Figueiredo wrote:
> Static analysis cannot and should not clutter executable code.
(1) It isn't clutter. The human reader uses that information as well as the
compiler, interpreter, type-checker, IDE, text editor, correctness tester,
etc.
(2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F
random...@fastmail.us wrote:
> On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
>> random...@fastmail.us wrote:
>> - lexical analysis has to look for twice as many files (it has to
>> hit the hard drive for a stub file before looking at the source),
>> and we know from importing that fil
On Wed, Jan 28, 2015 at 8:35 AM, Mario Figueiredo wrote:
> In other words, lets suggest function annotations as a restrictive
> feature, instead of a feature that can adapt to more than one use case.
PEP 3107 made a feature that can adapt to more than one use case. It's
been years now, and the us
I can now start to understand the criticism of how Python is evolving
coming from many corners, either long term python educators like Mark
Lutz.
--
https://mail.python.org/mailman/listinfo/python-list
In article ,
ros...@gmail.com says...
>
> Sure you can! But this is *itself* a weak argument, unless you
> actually have a codebase that uses it.
Wait. Are you saying that unless I show you a codebase that requires
marshalling and static analysis, you will ignore the fact that a
project, no ma
On Wed, Jan 28, 2015 at 8:19 AM, Mario Figueiredo wrote:
> @typehint@ some crazy syntax for static analysis
> @marshallib@ more crazy syntax for the marshall lib
> @anotherlib@ Whoohoo! a 3rd annotation for another lib
> """
>
> Are you telling me this is not a viable alternative.
In article ,
ros...@gmail.com says...
>
> On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo wrote:
> > Looking at PEP 3107, i'm left wondering: what if I have for instance
> > already annotated my functions for parameter marshalling, following the
> > syntax expected of that specific library, an
On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo wrote:
> Looking at PEP 3107, i'm left wondering: what if I have for instance
> already annotated my functions for parameter marshalling, following the
> syntax expected of that specific library, and now I want to annotate
> them for type hinting f
In article ,
ros...@gmail.com says...
>
> On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo wrote:
> > An optional feature says nothing of its requirements. The requirements
> > for PEP 484 are heavy. Not only will they force an update to the
> > interpreter, but will also force many users to re
On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo wrote:
> An optional feature says nothing of its requirements. The requirements
> for PEP 484 are heavy. Not only will they force an update to the
> interpreter, but will also force many users to reformate their function
> headers in order for them
In article ,
random...@fastmail.us says...
>
> On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> > random...@fastmail.us wrote:
> > - lexical analysis has to look for twice as many files (it has to
> > hit the hard drive for a stub file before looking at the source),
> > and we know f
On 27/01/2015 17:26, random...@fastmail.us wrote:
On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote:
I consider return type to be part of the function signature. The
signature
of a function is the parameters it accepts and the result it returns.
It's part of it, but not the whole of it, an
On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> random...@fastmail.us wrote:
> - lexical analysis has to look for twice as many files (it has to
> hit the hard drive for a stub file before looking at the source),
> and we know from importing that file system access is a
> significa
On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> > (header files in the 1970s didn't even actually include function
> > signature information) - which did not even participate in compilation
> > at all.
>
> If C compilers didn't use the header files, what were they for?
My sentence may ha
On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote:
> I consider return type to be part of the function signature. The
> signature
> of a function is the parameters it accepts and the result it returns.
It's part of it, but not the whole of it, and early C compilers had no
information about th
Chris Angelico wrote:
> On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano
> wrote:
>> I consider return type to be part of the function signature. The
>> signature of a function is the parameters it accepts and the result it
>> returns.
>
> It is, but there are times when it isn't significant. Fo
On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano
wrote:
> I consider return type to be part of the function signature. The signature
> of a function is the parameters it accepts and the result it returns.
It is, but there are times when it isn't significant. For instance,
C++ overloaded functions
Dan Sommers wrote:
> On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote:
>
>> random...@fastmail.us wrote:
>
>>> (header files in the 1970s didn't even actually include function
>>> signature information) - which did not even participate in
>>> compilation at all.
>
>> If C compilers did
On Mon, 26 Jan 2015 17:10:18 -0800, Rick Johnson wrote:
> On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote:
>
>> Stub files are a second-rate solution for the problem of annotating
>> functions where you are unable (or unwilling) to annotate the source
>> code directly. They
On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote:
> Stub files are a second-rate solution for the problem of
> annotating functions where you are unable (or unwilling)
> to annotate the source code directly. They suffer from
> similar problems:
>
> - you have to manage the st
On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote:
> random...@fastmail.us wrote:
>> (header files in the 1970s didn't even actually include function
>> signature information) - which did not even participate in
>> compilation at all.
> If C compilers didn't use the header files, what we
BartC wrote:
> how do you represent a raise of 10% exactly if
> not with binary floating point?
In Python today, the best solution is probably to use Decimals:
from decimal import Decimal
raise = Decimal("0.1")
But the traditional solution is to track money in cents, or a fixed fraction
of a
random...@fastmail.us wrote:
> On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote:
>> Rick Johnson wrote:
>>
>> > The solution is move the type
>> > hinting syntax completely out of the source file and into
>> > another file -- think of it as a "Python Type Hinting Header
>> > File".
>>
>> Th
[Reposting. First attempt went direct to poster, perhaps via email, not
sure why as I don't have a button to do that. If this does the same then
please ignore.]
On 23/01/2015 10:59, Steven D'Aprano wrote:
> Chris Angelico wrote:
>
>> On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano
>> wrote:
On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
> > The solution is move the type
> > hinting syntax completely out of the source file and into
> > another file -- think of it as a "Python Type Hinting Header
> > File".
>
> The 1970s called, they want their bad idea
On 25/01/2015 01:00, Rick Johnson wrote:
On Saturday, January 24, 2015 at 5:56:02 PM UTC-6, Mark Lawrence wrote:
For at least the third time the PEP was written by three
people, one of whom was the BDFL. Why do you keep
insisting that "he" is wrong, surely it should be "they" ?
TWO REASONS:
Tim Chase wrote:
> On 2015-01-25 04:31, Steven D'Aprano wrote:
>> Of course we don't have $1/3 dollar coins, but I do have a pair of
>> tin-snips and can easily cut a $1 coin into three equal pieces.
>
> I'm impressed that you can use tin-snips to cut it into exactly three
> equal pieces with gre
On Saturday, January 24, 2015 at 5:56:02 PM UTC-6, Mark Lawrence wrote:
> For at least the third time the PEP was written by three
> people, one of whom was the BDFL. Why do you keep
> insisting that "he" is wrong, surely it should be "they" ?
TWO REASONS:
(1) I don't know either of those peop
On 24/01/2015 23:20, Rick Johnson wrote:
On Saturday, January 24, 2015 at 1:49:08 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
[... snip absurdities...]
Duh! Do you think i just pulled stub files out my arse
without giving all the other alternatives due consideration?
Actually, yes.
On Sun, Jan 25, 2015 at 10:39 AM, Mario Figueiredo wrote:
> In article ,
> ros...@gmail.com says...
>>
>> On Sun, Jan 25, 2015 at 10:20 AM, Rick Johnson
>> wrote:
>> > Besides, why does he need *ME* to lick his boots when he
>> > already has plenty of fan-boys over at python-ideas and
>> > python
In article ,
ros...@gmail.com says...
>
> On Sun, Jan 25, 2015 at 10:20 AM, Rick Johnson
> wrote:
> > Besides, why does he need *ME* to lick his boots when he
> > already has plenty of fan-boys over at python-ideas and
> > python-dev lining up. This community is *NOT*, and should
> > never be, a
On Sun, Jan 25, 2015 at 10:20 AM, Rick Johnson
wrote:
> Besides, why does he need *ME* to lick his boots when he
> already has plenty of fan-boys over at python-ideas and
> python-dev lining up. This community is *NOT*, and should
> never be, a homogeneous block -- for we would be doing
> ourselve
On Saturday, January 24, 2015 at 1:49:08 AM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
> [... snip absurdities...]
>
> > Duh! Do you think i just pulled stub files out my arse
> > without giving all the other alternatives due consideration?
>
> Actually, yes. I think that had Guido pr
In article <54c2299d$0$13005$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
> I don't think that a raise of 0.10001 (10%),
> 0.035003 (3.5%) or 0.070007 (7%) is quite what
> people intended.
>
> (Don't use binary floating p
On Sat, Jan 24, 2015 at 2:14 PM, alister
wrote:
>>
>> Either that, or make up change with 20¢, 10¢ and 5¢ (we practice
>> round-to-nearest-5-cents here).
>
> I suppose if you all pay 35¢ it at least gives the waitress a tip.
"""
In the Pacific States they have made a bolder push for complexity,
>
> Of course we don't have $1/3 dollar coins, but I do have a pair of
> tin-snips and can easily cut a $1 coin into three equal pieces.
wow you have just given a physical demonstration of integer Maths
$1 /3 =$0
as the coin is now worthless ;-)
>
> Either that, or make up change with 20¢, 10¢ a
On Sunday, January 25, 2015 at 12:15:28 AM UTC+5:30, Tim Chase wrote:
> On 2015-01-25 04:31, Steven D'Aprano wrote:
> > Of course we don't have $1/3 dollar coins, but I do have a pair of
> > tin-snips and can easily cut a $1 coin into three equal pieces.
>
> I'm impressed that you can use tin-snip
On 2015-01-25 04:31, Steven D'Aprano wrote:
> Of course we don't have $1/3 dollar coins, but I do have a pair of
> tin-snips and can easily cut a $1 coin into three equal pieces.
I'm impressed that you can use tin-snips to cut it into exactly three
equal pieces with greater precision than the floa
1 - 100 of 220 matches
Mail list logo
