tix.FileSelectBox causes crash: was A newbie question about using tix

On Wed, 2019-05-01 at 19:11 +0100, MRAB wrote: > On 2019-05-01 17:44, David Sumbler wrote: > > > > On Tue, 2019-04-30 at 20:46 +0100, MRAB wrote: ... > > > For some reason, tix widgets don't work with normal tkinter > widgets, > > > so > > > you can't put a tix FileSelectBox on a tkinter

Re: A newbie question about using tix

On 2019-05-01 17:44, David Sumbler wrote: > > On Tue, 2019-04-30 at 20:46 +0100, MRAB wrote: > > On 2019-04-30 16:40, David Sumbler wrote: > > > Running Ubuntu 18.04, Python 3.6.7, tkinter 8.6 > > > > > > I am very new to tkinter.  The simple program I am writing requires > > > a > > > user file t

Re: A newbie question about using tix

On Tue, 2019-04-30 at 20:46 +0100, MRAB wrote: > On 2019-04-30 16:40, David Sumbler wrote: > > Running Ubuntu 18.04, Python 3.6.7, tkinter 8.6 > > > > I am very new to tkinter. The simple program I am writing requires > > a > > user file to be selected before it does anything else, so I would >

Re: A newbie question about using tix

On 2019-04-30 16:40, David Sumbler wrote: Running Ubuntu 18.04, Python 3.6.7, tkinter 8.6 I am very new to tkinter. The simple program I am writing requires a user file to be selected before it does anything else, so I would like a file selection dialog in the main window as soon as the program

A newbie question about using tix

Running Ubuntu 18.04, Python 3.6.7, tkinter 8.6 I am very new to tkinter. The simple program I am writing requires a user file to be selected before it does anything else, so I would like a file selection dialog in the main window as soon as the program launches. Tkinter only has askopenfilename

Re: A newbie question

Hi, Colin. Thanks for your answer. But C:\Python27\Scripts is in my path and my trouble is about INSTALL easy_isntall. Bye A. -- http://mail.python.org/mailman/listinfo/python-list

Re: A newbie question

On 12/02/2013 10:06 AM, Alberto Salvati wrote: Hi, All. I'm a (old) delphi developer. I want to learn Python. I've python 2.7 and django. For learning purpose I want to use firebird. But, package (egg) to use firebird needs easy_install for setup. When i run: python ez_setup.py install pyth

A newbie question

Hi, All. I'm a (old) delphi developer. I want to learn Python. I've python 2.7 and django. For learning purpose I want to use firebird. But, package (egg) to use firebird needs easy_install for setup. When i run: python ez_setup.py install python says me error: Downloading http://pypi.python

Re: A newbie question about some code

Jim Qiu wrote: Hi everyone. I am reading a python library code and found something i can not understand. Please help! class Envelope(object): def __init__(self,ta_info): self.ta_info = ta_info def writefilelist(self,ta_list,tofile): for filename in ta_list:

Re: A newbie question about some code

On Mon, May 18, 2009 at 5:30 PM, Rhodri James wrote: > On Mon, 18 May 2009 10:18:52 +0100, Jim Qiu > wrote: > > Please check the blue highlighted part, I don't understand how the object >> get the property? >> > > Colours and highlighting don't come across in Usenet postings. Could > you be a

Re: A newbie question about some code

On Mon, May 18, 2009 at 2:18 AM, Jim Qiu wrote: > Hi everyone. > I am reading a python library code and found something i can not understand. > Please help! > class Envelope(object): >     def __init__(self,ta_info): >         self.ta_info = ta_info > >     def writefilelist(self,ta_list,tofile):

Re: A newbie question about some code

On Mon, 18 May 2009 10:18:52 +0100, Jim Qiu wrote: Please check the blue highlighted part, I don't understand how the object get the property? Colours and highlighting don't come across in Usenet postings. Could you be a bit more specific. Which object, and what property? -- Rhodri Jame

A newbie question about some code

Hi everyone. I am reading a python library code and found something i can not understand. Please help! class Envelope(object): def __init__(self,ta_info): self.ta_info = ta_info def writefilelist(self,ta_list,tofile): for filename in ta_list: fromfile = botsl

Re: a newbie question

On Apr 12, 11:01 pm, Peter Otten <__pete...@web.de> wrote: > zhangle2...@gmail.com wrote: > > I am just learning Python and get a problem when trying this example: > > > from urllib import urlopen > > doc=urlopen("http://www.python.org";).read() > > print(doc) > > > when i run this, i was tould tha

Re: a newbie question

zhangle2...@gmail.com wrote: > I am just learning Python and get a problem when trying this example: > > from urllib import urlopen > doc=urlopen("http://www.python.org";).read() > print(doc) > > when i run this, i was tould that 'cannot import name "urlopen" > > > What's wrong with this code?

Re: a newbie question

use urllib2 2009/4/12 : > hi, > > I am just learning Python and get a problem when trying this example: > > from urllib import urlopen > doc=urlopen("http://www.python.org";).read() > print(doc) > > when i run this, i was tould that 'cannot import name "urlopen" > > > What's wrong with this code?

a newbie question

hi, I am just learning Python and get a problem when trying this example: from urllib import urlopen doc=urlopen("http://www.python.org";).read() print(doc) when i run this, i was tould that 'cannot import name "urlopen" What's wrong with this code? Do i need to place my code in some specific

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Steve Holden" <[EMAIL PROTECTED],..eb.com> wrote: > The trouble there, though, is that although COBOL was comprehensible (to > a degree) relatively few people have the rigor of thought necessary to > construct, or even understand, an algorithm of any kind. This is true - and in my experience

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Kay Schluehr <[EMAIL PROTECTED]> writes: > >>When I remember correctly the FDIV bug was due to a wrongly filled >>lookup table and occurred only for certain bitpattern in the divisor. >>I'm not sure how a formal proof on the structure of the algorithm >>could help here? Intel r

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Kay Schluehr <[EMAIL PROTECTED]> writes: > When I remember correctly the FDIV bug was due to a wrongly filled > lookup table and occurred only for certain bitpattern in the divisor. > I'm not sure how a formal proof on the structure of the algorithm > could help here? Intel repaired the table i.e.

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Jul 20, 6:28 pm, Paul Rubin wrote: > As the Intel FDIV bug > incident reminds us, even billions of test inputs are not enough to > show that the routine does the right thing for EVERY input. When I remember correctly the FDIV bug was due to a wrongly filled lookup ta

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Steve Holden <[EMAIL PROTECTED]> writes: >> The issue I have with correctness proofs (at least as they were >> presented in the 1980s - for all I know the claims may have become >> more realistic now) is that the proof of correctness can only relate >> to some highly-formal spec

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > > Come on, this is real-time embedded software, > Since when did we restrict ourselves to such an environment? I was under the > impression that this thread is about the merits and capabilities of static > type-checking? One branch of the discussion

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Kay Schluehr <[EMAIL PROTECTED]> writes: > >>Sure. But knowing that memory is limited doesn't buy you much because >>you achieve an existential proof at best: you can show that the >>program must run out of memory but you have to run the program to know >>where this happens for

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Steve Holden <[EMAIL PROTECTED]> writes: > The issue I have with correctness proofs (at least as they were > presented in the 1980s - for all I know the claims may have become > more realistic now) is that the proof of correctness can only relate > to some highly-formal specification so complex tha

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: >> What does that buy you - where is "I'm crashed becaus I ran out of >> memory trying to evade the seventh mig" better than "sorry, you will >> be shot down because I'm not capable of processing more enemie >> fighters - but hey

Re: PEP 3107 and stronger typing (note: probably a newbie question)

John Nagle wrote: > Juergen Erhard wrote: >> On proving programs correct... from my CS study days I distinctly >> remember thinking "sure, you can prove it correct, but you cannot do >> actual useful stuff with it". We might have come a long way since >> then (late 80s :P), but I don't hold out mu

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > What does that buy you - where is "I'm crashed becaus I ran out of > memory trying to evade the seventh mig" better than "sorry, you will > be shot down because I'm not capable of processing more enemie > fighters - but hey, at least I'm still here

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Kay Schluehr <[EMAIL PROTECTED]> writes: > Sure. But knowing that memory is limited doesn't buy you much because > you achieve an existential proof at best: you can show that the > program must run out of memory but you have to run the program to know > where this happens for arbitrary input values

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin schrieb: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: >> For example, SPARK does not support dynamic allocation of memory so >> things such as pointers and heap variables are not supported. > > Right, Spark uses a profile intended for embedded systems, so > no unpredictable gc delay

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Jul 20, 6:45 am, John Nagle <[EMAIL PROTECTED]> wrote: > Juergen Erhard wrote: > > On proving programs correct... from my CS study days I distinctly > > remember thinking "sure, you can prove it correct, but you cannot do > > actual useful stuff with it". We might have come a long way since > >

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Juergen Erhard wrote: > On proving programs correct... from my CS study days I distinctly > remember thinking "sure, you can prove it correct, but you cannot do > actual useful stuff with it". We might have come a long way since > then (late 80s :P), but I don't hold out much hope (especially sinc

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Thu, Jul 12, 2007 at 11:26:22AM -0700, Paul Rubin wrote: > > Guy Steele used to describe functional programming -- the evaluation > of lambda-calculus without side effects -- as "separation of Church > and state", a highly desirable situation ;-). > > (For non-FP nerds, the above is a pun refe

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > For example, SPARK does not support dynamic allocation of memory so > things such as pointers and heap variables are not supported. Right, Spark uses a profile intended for embedded systems, so no unpredictable gc delays etc. > Which is not to say

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Hendrik van Rooyen wrote: > "Lenard Lindstrom" <[EMAIL PROTECTED]> wrote: > > >> Pascal has no break, continue or return. Eiffel doesn't even have a >> goto. In such imperative languages boolean variables are used a lot. > > Thanks did not know this. > >> from StringIO import StringIO >> lin

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Lenard Lindstrom" <[EMAIL PROTECTED]> wrote: > Pascal has no break, continue or return. Eiffel doesn't even have a > goto. In such imperative languages boolean variables are used a lot. Thanks did not know this. > > from StringIO import StringIO > lines = StringIO("one\ntwo\nthree\nfour\n"

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Ben Finney <[EMAIL PROTECTED]> writes: > This seems to make the dangerous assumption that the programmer has > the correct program in mind, and needs only to transfer it correctly > to the computer. Well, I hope the programmer can at least state some clear specficiations that a correct program sho

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Hendrik van Rooyen wrote: > "Donn Cave" <[EMAIL PROTECTED]> wrote: > >> In its day, goto was of course very well loved. > > Does anybody know for sure if it is in fact possible to > design a language completely free from conditional jumps? > > At the lower level, I don't think you can get away w

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > > This is interesting. Do you have any references we can read about this > > assertion -- specifically, that "GOTO" was not well loved (I assume > > "by the programming communit

Re: PEP 3107 and stronger typing (note: probably a newbie question)

John Nagle schrieb: > Chris Mellon wrote: >> You can't prove a program to be correct, in the sense that it's proven >> to do what it's supposed to do and only what it's supposed to do. > > Actually, you can prove quite a bit about programs with the right > tools. > For example, proving that a

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Fri, 13 Jul 2007 08:37:00 +0200, Hendrik van Rooyen wrote: > "Donn Cave" <[EMAIL PROTECTED]> wrote: > >>In its day, goto was of course very well loved. > > Does anybody know for sure if it is in fact possible to > design a language completely free from conditional jumps? GOTO is unconditiona

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On 2007-07-13, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Donn Cave" <[EMAIL PROTECTED]> wrote: > >>In its day, goto was of course very well loved. > > Does anybody know for sure if it is in fact possible to > design a language completely free from conditional jumps? I think you have to be m

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Ben Finney <[EMAIL PROTECTED]> writes: > This is interesting. Do you have any references we can read about this > assertion -- specifically, that "GOTO" was not well loved (I assume > "by the programming community at large") even by around 1966? Dijkstra's famous 1968 "GOTO considered harmful"

Re: PEP 3107 and stronger typing (note: probably a newbie question)

John Nagle <[EMAIL PROTECTED]> writes: > Donn Cave wrote: > > In its day, goto was of course very well loved. > > No, it wasn't. By 1966 or so, "GOTO" was starting to look like a > bad idea. It was a huge hassle for debugging. This is interesting. Do you have any references we can read about th

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Donn Cave" <[EMAIL PROTECTED]> wrote: >In its day, goto was of course very well loved. Does anybody know for sure if it is in fact possible to design a language completely free from conditional jumps? At the lower level, I don't think you can get away with conditional calls - hence the "jumps w

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Chris Mellon wrote: > You can't prove a program to be correct, in the sense that it's proven > to do what it's supposed to do and only what it's supposed to do. Actually, you can prove quite a bit about programs with the right tools. For example, proving that a program cannot subscript out of

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave wrote: > In its day, goto was of course very well loved. No, it wasn't. By 1966 or so, "GOTO" was starting to look like a bad idea. It was a huge hassle for debugging. It took another decade to get the iteration constructs approximately right (FORTRAN was too restrictive, AL

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Chris Mellon" <[EMAIL PROTECTED]> writes: > You can't prove a program to be correct, in the sense that it's proven > to do what it's supposed to do and only what it's supposed to do. You > can prove type-correctness, and the debate is really over the extent > that a type-correct program is also be

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On 7/12/07, Donn Cave <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Ben Finney <[EMAIL PROTECTED]> wrote: > > > Paul Rubin writes: > > > > > The idea of designing languages with more and more support for > > > ensuring program correctness is to put the e

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave <[EMAIL PROTECTED]> writes: > Don't worry - there will be a state transformation monad for you! > > Nature or nurture? it would be interesting to see some identical twin > studies on novice programmers. Since few of us were exposed first > to strictly functional programming, though, yo

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, Ben Finney <[EMAIL PROTECTED]> wrote: > Paul Rubin writes: > > > The idea of designing languages with more and more support for > > ensuring program correctness is to put the established, repetitive > > processes into the computer where

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > Donn Cave wrote: > > Someday we will look at "variables" like we look at goto. > > > How very functional. I believe some people naturally think in terms of > state transformations and some in terms of functional evaluation

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"John Nagle" <[EMAIL PROTECTED]> wrote: > I've worked in big mainframe shops, where an operating system > crash caused everything to suddenly freeze, red lights came on all > over the building, and a klaxon sounded. I've worked for aerospace > companies, where one speaks of "defects", not "bu

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin writes: > The idea of designing languages with more and more support for > ensuring program correctness is to put the established, repetitive > processes into the computer where it belongs, freeing the programmer > to be innovative while still providing high a

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave <[EMAIL PROTECTED]> writes: > I've wondered if programmers might differ a lot in how much they > dread errors, or how they react to different kinds of errors. > For example, do you feel a pang of remorse when your program > dies with a traceback - I mean, what a horrible way to die? I'm

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[EMAIL PROTECTED] (Alex Martelli) writes: > If what you wonder about, and the theory mentioned by Clemmer and > detailed by the AQF, are both true, then this may help explain why some > programmers are fiercely innovative why other, equally intelligent ones, > prefer to stick with some plodding, in

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave <[EMAIL PROTECTED]> wrote: > I've wondered if programmers might differ a lot in how much they > dread errors, or how they react to different kinds of errors. That's quite possible. I'm reminded of a by-now commonplace theory, well summarized at

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave wrote: > In article <[EMAIL PROTECTED]>, > Steve Holden <[EMAIL PROTECTED]> wrote: > >> Paul Rubin wrote: >>> Steven D'Aprano <[EMAIL PROTECTED]> writes: As far as I can see, the only difference is that the list comp variable isn't explicitly created with a statement of the fo

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Donn Cave wrote: > I've wondered if programmers might differ a lot in how much they > dread errors, or how they react to different kinds of errors. > For example, do you feel a pang of remorse when your program > dies with a traceback - I mean, what a horrible way to die? > Do you resent the compil

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > Steven D'Aprano <[EMAIL PROTECTED]> writes: > >> As far as I can see, the only difference is that the list comp variable > >> isn't explicitly created with a statement of the form "name = value". Why >

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > I don't think it's the syntax that keeps people from checking for > errors. It's more a difference of error handling philosophy - in > Python, if you can't do something sensible with an error you just > pretend it can't

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > >>>If the assertion is wrong, the compiler signals an error. In >>>that sense it's like a unit test; it makes sure the function does what >>>the user expects. >> >>It still boils down to the same problem : possibly valid typ

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > Sure. But which class of programs are decidable? There's lot's of > research going on with model checking and the like. But AFAIK, the > consensus is that the very moment you allow recursive types, the > type-checking is either incomplete, or possibl

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin schrieb: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: >>> Which implies that even in ADA, runtime type errors are in fact >>> expected - else there would be no handler for such a case. >> Well, yes, runtime errors occur - in statically typed languages as >> well. That's essentially t

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > > If the assertion is wrong, the compiler signals an error. In > > that sense it's like a unit test; it makes sure the function does what > > the user expects. > > It still boils down to the same problem : possibly valid types are > rejected based

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On 07 Jul 2007 23:27:08 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > "Hamilton, William " <[EMAIL PROTECTED]> writes: > > > Why on earth would anyone prefer taking a failure in the field over > > > having a static type check make that particular failure impossible? > > > > Because st

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: >>> Some users in fact recommend writing an explicit type signature for >>> every Haskell function, which functions sort of like a unit test. >> Stop here. explicit type signature == declarative static typing != >> unit test. >

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > >>>Which implies that even in ADA, runtime type errors are in fact >>>expected - else there would be no handler for such a case. >> >>Well, yes, runtime errors occur - in statically typed languages as >>well. That's essentially t

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > >>>Which implies that even in ADA, runtime type errors are in fact >>>expected - else there would be no handler for such a case. >> >>Well, yes, runtime errors occur - in statically typed languages as >>well. That's essentially t

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > > Which implies that even in ADA, runtime type errors are in fact > > expected - else there would be no handler for such a case. > > Well, yes, runtime errors occur - in statically typed languages as > well. That's essentially the halting-problem.

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Steve Holden <[EMAIL PROTECTED]> writes: > Maybe we just have different styles, and I naturally tend to write in > smaller scopes than you do. It's easy to make errors even in very small scopes. -- http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> As far as I can see, the only difference is that the list comp variable >> isn't explicitly created with a statement of the form "name = value". Why >> is that a problem? > > I don't know that listcomp vars are worse problem than o

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Steven D'Aprano <[EMAIL PROTECTED]> writes: > As far as I can see, the only difference is that the list comp variable > isn't explicitly created with a statement of the form "name = value". Why > is that a problem? I don't know that listcomp vars are worse problem than other vars; however there is

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Sun, 08 Jul 2007 08:49:26 -0400, Steve Holden wrote: > Paul Rubin wrote: >> Steve Holden <[EMAIL PROTECTED]> writes: Python even leaks the index variable of list comprehensions (I've mostly stopped using them because of this), though that's a recognized wart and is due to be fixe

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Jun 20, 8:53 pm, Stephen R Laniel <[EMAIL PROTECTED]> wrote: > Reading [1], I wonder: why isn't the compiler making better > use of (purely optional) type labeling? Why not make a compiler > directive so that > > a) it will check the types of all my arguments and return >values, If that is

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Steve Holden <[EMAIL PROTECTED]> writes: >>> Python even leaks the index variable of list comprehensions (I've >>> mostly stopped using them because of this), though that's a >>> recognized wart and is due to be fixed. >>> >> Wow, you really take non-pollution of the namespace s

Re: PEP 3107 and stronger typing (note: probably a newbie question)

"Hamilton, William " <[EMAIL PROTECTED]> writes: > > Why on earth would anyone prefer taking a failure in the field over > > having a static type check make that particular failure impossible? > > Because static typechecking won't make that particular failure > "impossible," but instead just chan

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Steve Holden <[EMAIL PROTECTED]> writes: > > Python even leaks the index variable of list comprehensions (I've > > mostly stopped using them because of this), though that's a > > recognized wart and is due to be fixed. > > > Wow, you really take non-pollution of the namespace seriously. I agree > i

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > > Some users in fact recommend writing an explicit type signature for > > every Haskell function, which functions sort of like a unit test. > > Stop here. explicit type signature == declarative static typing != > unit test. The user-written signat

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On Jul 5, 3:24 pm, Donn Cave <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Paul Boddie <[EMAIL PROTECTED]> wrote: > > > However, it's interesting to consider the work that sometimes needs to > > go in to specify data structures in some languages - thinking of ML > > and friends, a

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, Paul Boddie <[EMAIL PROTECTED]> wrote: > However, it's interesting to consider the work that sometimes needs to > go in to specify data structures in some languages - thinking of ML > and friends, as opposed to Java and friends. The campaign for optional > static t

RE: PEP 3107 and stronger typing (note: probably a newbie question)

> From: Paul Rubin > > greg <[EMAIL PROTECTED]> writes: > > > E.g. your program might pass its test and run properly for years > > > before some weird piece of input data causes some regexp to not quite > > > work. > > > > Then you get a bug report, you fix it, and you add a test > > for it so tha

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > John Nagle <[EMAIL PROTECTED]> writes: >> This has been tried. Original K&R C had non-enforced static typing. >> All "struct" pointers were equivalent. It wasn't pretty. >> >> It takes strict programmer discipline to make non-enforced static >> typing work. I've see

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Bruno Desthuilliers skrev: > Paul Rubin a écrit : >> Bruno Desthuilliers <[EMAIL PROTECTED]> writes: >> >>> Haskell - as other languages using type-inference like OCaml - are in >>> a different category. Yes, I know, don't say it, they are statically >>> typed - but it's mostly structural typing, n

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Eduardo "EdCrypt" O. Padoan wrote: > On 6/30/07, Bruno Desthuilliers > <[EMAIL PROTECTED]> wrote: >> Eduardo "EdCrypt" O. Padoan a écrit : >> > Remember that pure CPython has no different "compile time" and >> > runtiime. >> >> Oh yes ? So what's the compiler doing, and what are those .pyc files ?

Re: PEP 3107 and stronger typing (note: probably a newbie question)

In article <[EMAIL PROTECTED]>, John Nagle <[EMAIL PROTECTED]> wrote: > Non-enforced static typing requires a quality assurance group that > reads code and checks coding standards. In other words, it's enforced, but it's enforced by QA people instead of the compiler. -- http://mail.python.org/

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Roy Smith wrote: > greg <[EMAIL PROTECTED]> wrote: > > Then you get a bug report, you fix it, and you add a test > > for it so that particular bug can't happen again. > The TDD zealots would tell you you've got the order wrong. Instead of > "fix, then write a test", it should be "write a failin

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On 7/4/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 6/22/07, Eduardo EdCrypt O. Padoan <[EMAIL PROTECTED]> wrote: > > Remember that pure CPython has no different "compile time" and > > runtiime. But Psyco and ShedSkin could use the annotations the way > > they want. > . > > def compile(s

Re: PEP 3107 and stronger typing (note: probably a newbie question)

On 6/22/07, Eduardo EdCrypt O. Padoan <[EMAIL PROTECTED]> wrote: > Remember that pure CPython has no different "compile time" and > runtiime. But Psyco and ShedSkin could use the annotations the way > they want. . > def compile(source: "something compilable", >filename: "where the c

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > >>Haskell - as other languages using type-inference like OCaml - are in >>a different category. Yes, I know, don't say it, they are statically >>typed - but it's mostly structural typing, not declarative >>typing. Which makes

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > Haskell - as other languages using type-inference like OCaml - are in > a different category. Yes, I know, don't say it, they are statically > typed - but it's mostly structural typing, not declarative > typing. Which makes them much more usable IMH

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > >>Because static type checks impose a lot of arbitrary restrictions, >>boilerplate code etc, which tends to make code more complicated than >>it needs to be, which is a good way of introducing bugs that wouldn't >>have existe

Re: PEP 3107 and stronger typing (note: probably a newbie question)

John Nagle <[EMAIL PROTECTED]> writes: > This has been tried. Original K&R C had non-enforced static typing. > All "struct" pointers were equivalent. It wasn't pretty. > > It takes strict programmer discipline to make non-enforced static > typing work. I've seen it work in an aerospac

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Boddie wrote: > Paul Rubin wrote: > > The campaign for optional > static typing in Python rapidly became bogged down in this matter, > fearing that any resulting specification for type information might > not be the right combination of flexible and powerful to fit in with > the rest of the l

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin wrote: > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > > Because static type checks impose a lot of arbitrary restrictions, > > boilerplate code etc, which tends to make code more complicated than > > it needs to be, which is a good way of introducing bugs that wouldn't > > have exis

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > Because static type checks impose a lot of arbitrary restrictions, > boilerplate code etc, which tends to make code more complicated than > it needs to be, which is a good way of introducing bugs that wouldn't > have existed without static type chec

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Roy Smith <[EMAIL PROTECTED]> wrote: > greg <[EMAIL PROTECTED]> wrote: > > > Paul Rubin wrote: > > > E.g. your program might pass its test and run properly for years > > > before some weird piece of input data causes some regexp to not quite > > > work. > > > > Then you get a bug report, you fix

Re: PEP 3107 and stronger typing (note: probably a newbie question)

greg <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > E.g. your program might pass its test and run properly for years > > before some weird piece of input data causes some regexp to not quite > > work. > > Then you get a bug report, you fix it, and you add a test > for it so that particular bu

Re: PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin a écrit : > greg <[EMAIL PROTECTED]> writes: >>> E.g. your program might pass its test and run properly for years >>> before some weird piece of input data causes some regexp to not quite >>> work. >> Then you get a bug report, you fix it, and you add a test >> for it so that particular

Re: PEP 3107 and stronger typing (note: probably a newbie question)

greg <[EMAIL PROTECTED]> writes: > > E.g. your program might pass its test and run properly for years > > before some weird piece of input data causes some regexp to not quite > > work. > > Then you get a bug report, you fix it, and you add a test > for it so that particular bug can't happen again

  1   2   3   >