Re: Why assert is not a function?
On Fri, Mar 12, 2021 at 5:03 PM Mike Dewhirst wrote: > > On 12/03/2021 4:31 pm, Chris Angelico wrote: > > On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson wrote: > >> For me, try/except is for when something might reasonably "go wrong" in > >> normal use, even niche normal use. Whereas assert is for things which > >> should _never_ occur. Roughly, again for me, try/except if for catching > >> misuse and assert is for catching misdesign/misimplementation. > > Something like that, yeah. An assertion failure represents a bug *in > > this code*, something that shouldn't ever happen. If it's possible to > > trigger the failure with some other piece of code (calling something > > with bad arguments, or whatever), then assert is the wrong tool for > > the job. Similarly, if you find yourself catching AssertionError > > anywhere outside of unit testing, something is horribly wrong > > somewhere :) > > I haven't been following this thread so please forgive me if this has > been said ... > > My understanding of the reason for assert is to support the "design by > contract" programming style of Eiffel as espoused by Bertrand Meyer. I > don't suppose it makes much difference whether it is a function or a > callable for that - and when I first saw it I was appropriately confused > - but I only ever used it when I was absolutely certain the assertion > was bullet-proof. And it is a long time since I did that. I prefer > try-except nowadays. > Definitely use something other than assertions for that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 12/03/2021 4:31 pm, Chris Angelico wrote: On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson wrote: For me, try/except is for when something might reasonably "go wrong" in normal use, even niche normal use. Whereas assert is for things which should _never_ occur. Roughly, again for me, try/except if for catching misuse and assert is for catching misdesign/misimplementation. Something like that, yeah. An assertion failure represents a bug *in this code*, something that shouldn't ever happen. If it's possible to trigger the failure with some other piece of code (calling something with bad arguments, or whatever), then assert is the wrong tool for the job. Similarly, if you find yourself catching AssertionError anywhere outside of unit testing, something is horribly wrong somewhere :) I haven't been following this thread so please forgive me if this has been said ... My understanding of the reason for assert is to support the "design by contract" programming style of Eiffel as espoused by Bertrand Meyer. I don't suppose it makes much difference whether it is a function or a callable for that - and when I first saw it I was appropriately confused - but I only ever used it when I was absolutely certain the assertion was bullet-proof. And it is a long time since I did that. I prefer try-except nowadays. Mike ChrisA -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Just ask and I'll send it to you. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson wrote: > For me, try/except is for when something might reasonably "go wrong" in > normal use, even niche normal use. Whereas assert is for things which > should _never_ occur. Roughly, again for me, try/except if for catching > misuse and assert is for catching misdesign/misimplementation. Something like that, yeah. An assertion failure represents a bug *in this code*, something that shouldn't ever happen. If it's possible to trigger the failure with some other piece of code (calling something with bad arguments, or whatever), then assert is the wrong tool for the job. Similarly, if you find yourself catching AssertionError anywhere outside of unit testing, something is horribly wrong somewhere :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 12Mar2021 12:53, DL Neil wrote:
>On 12/03/2021 11.27, Chris Angelico wrote:
>> On Fri, Mar 12, 2021 at 9:10 AM Ethan Furman wrote:
>>> On 3/11/21 1:45 PM, dn via Python-list wrote:
Is assert so much faster/cheaper than try...except...raise?
>>>
>>> Infinitely faster when they are not there. ;-)
[...]
>> There are many hybrids available too though. For instance:
>>
>> if __debug__ or args.verify:
>> def verify(thing):
>> ...
>> raise Whatever
>> else:
>> def verify(thing): pass
>>
>> Yes, you pay the price of a function call even if you're not verifying
>> the full structural integrity. But that's a lot cheaper than the full
>> check.
>>
>> Advantage here is that you can use -O to suppress, or you can control
>> it with an arg, or whatever.
>>
>> If you're doing the same check in lots of places, and it's costly,
>> assertions aren't really a great fit.
>
>Perhaps I misunderstood (and haven't gone back to check - mea culpa),
>but the impression-gained was that -O many not be used, even "in
>production", for some reason?
News to me. Perhaps that was someone's scenario.
To me, asserts have 2 primary features: (a) they're easy to write (and
read) versus "if some_test: raise SomeException("blah blah...")" and (b)
they are outright _absent_ from the code when run with -O.
_Provided_ the code called from the assert has no side effects, dropping
the asserts should always make for identical -O behaviour vs no -O.
Chris' example above walks the middle ground providing something richer
that a plain assert while still (almost) vanishing with -O (and no
args.verify mode switch).
>Perhaps because I've not come from a language where assert played any/a
>major rôle, but am still hoping for some discussion/understanding as to
>why/when assert might be better than try...except in every/particular
>situations...
I find assert visually low impact. Try/except is quite wordy and brings
more indentation.
One has to keep in mind the use case.
For me, try/except is for when something might reasonably "go wrong" in
normal use, even niche normal use. Whereas assert is for things which
should _never_ occur. Roughly, again for me, try/except if for catching
misuse and assert is for catching misdesign/misimplementation.
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Compare word to word files
Il 11/03/2021 16:08, Dennis Lee Bieber ha scritto: On Thu, 11 Mar 2021 08:07:40 +0100, jak declaimed the following: Il 11/03/2021 05:28, CLYMATIC GAMING ha scritto: Hello , I want to compare word to word files please he me! copy and paset this string onto Google page: how to find difference between 2 files in Python ...and press "Google Search" button. Presuming the OP means plain text files and not M$ Word documents. If the search engine results do not satisfy him, he will change the search string. Optionally, you can prepare for him a list of search strings for all cases, who knows, maybe he means word as two bytes at time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 12/03/2021 11.27, Chris Angelico wrote: > On Fri, Mar 12, 2021 at 9:10 AM Ethan Furman wrote: >> >> On 3/11/21 1:45 PM, dn via Python-list wrote: >> >>> Is assert so much faster/cheaper than try...except...raise? >> >> Infinitely faster when they are not there. ;-) >> >> Basically, you are looking at two different philosophies: >> >> - Always double check, get good error message when something fails >> >> vs >> >> - check during testing and QA, turn off double-checks for production for >> best performance possible. >> > > There are many hybrids available too though. For instance: > > if __debug__ or args.verify: > def verify(thing): > ... > raise Whatever > else: > def verify(thing): pass > > Yes, you pay the price of a function call even if you're not verifying > the full structural integrity. But that's a lot cheaper than the full > check. > > Advantage here is that you can use -O to suppress, or you can control > it with an arg, or whatever. > > If you're doing the same check in lots of places, and it's costly, > assertions aren't really a great fit. Perhaps I misunderstood (and haven't gone back to check - mea culpa), but the impression-gained was that -O many not be used, even "in production", for some reason? Perhaps because I've not come from a language where assert played any/a major rôle, but am still hoping for some discussion/understanding as to why/when assert might be better than try...except in every/particular situations... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Friday Finking: following, weirdness with list()
The in-person version of 'Friday Finking' has been set-aside by COVID-precautions. Here's hoping the questions asked below will stimulate some thinking, or mild entertainment... On 02/03/2021 03.10, Grant Edwards wrote: > On 2021-03-01, Greg Ewing wrote: >> On 28/02/21 1:17 pm, Cameron Simpson wrote: >>> [its length in bytes] is presented via the object's __len__ method, >> >>> BUT... It also has a __iter__ value, which like any Box iterates over >>> the subboxes. >> >> You're misusing __len__ here. If an object is iterable and >> also has a __len__, its __len__ should return the number of >> items you would get if you iterated over it. Anything else >> is confusing and can lead to trouble, as you found here. > > That was certainly my reaction. Can you imagine the confusion if len() > of a list returned the number of bytes required for srorage insttead > of the number of elements? Why? Isn't one of the 'fun' things about modern* languages is the "over-loading" of operators/operations? * ie newer than FORTRAN-IV or COBOL (or my grey hair) Thus we have: 2 + 3# int( 5 ) and "2" + "3"# "23" ...and we are quite comfortable with the dissonant 'sameness' and 'difference'. If we can "over-load" __add__(), why not __len__()? That said, it is confusing: what does len() mean? Are we talking about the number of elements in a collection, or something else? What do the docs say? https://docs.python.org/3/library/functions.html#len talks of "the length (the number of items) of an object". In the OP, what are the "items" in this object/"subbox"? https://docs.python.org/3/reference/datamodel.html covers object.__len__(self) saying "Called to implement the built-in function len(). Should return the length of the object, an integer >= 0." without actually determining what "length of the object" may actually mean in any or every context. Here's another example/application: If we were playing with our own custom-class to work with vectors, should __len__() be coded to report (through len()) the number of dimensions considered in the vector: v = Vector( 1, 2, 3, 4 ) len( v )# 4 ...or should "len" stand for the "magnitude" of the vector, ie a distance of 5.5 (rounded)? Horses for courses? In the case of (Unicode) strings len() reports in characters, yet lists are sized in numbers of elements, etc. Each according to what we might call the 'unit' which should be counted. The implicit 'confusion' (and flexibility) of over-loading precedes (and to a degree, causes) "imagine the confusion if len() of a list returned the number of bytes required". That said, shouldn't we agreeing with the statement? Should one (sort of) class/file-structure demand that all other custom-, library-, and 'built-in'-classes report in bytes? (but is that being proposed/demanded?) The lengths of files are reported by the computer's ls-command/file-manager in [M/K]-bytes! This subject matter is a binary file/container format (MP4). Am working on a similar container format at the moment, where the length of sub-components may be reported in bytes (if not delineated by 'markers'). So, there are many reasons why "bytes" is a 'good' measure of length - in this context. Is it "misusing __len__" in a class/object designed to manipulate such files? Hope not! (or I'm 'in trouble' - again...) -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Fri, Mar 12, 2021 at 9:10 AM Ethan Furman wrote: > > On 3/11/21 1:45 PM, dn via Python-list wrote: > > > Is assert so much faster/cheaper than try...except...raise? > > Infinitely faster when they are not there. ;-) > > Basically, you are looking at two different philosophies: > > - Always double check, get good error message when something fails > > vs > > - check during testing and QA, turn off double-checks for production for best > performance possible. > There are many hybrids available too though. For instance: if __debug__ or args.verify: def verify(thing): ... raise Whatever else: def verify(thing): pass Yes, you pay the price of a function call even if you're not verifying the full structural integrity. But that's a lot cheaper than the full check. Advantage here is that you can use -O to suppress, or you can control it with an arg, or whatever. If you're doing the same check in lots of places, and it's costly, assertions aren't really a great fit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 3/11/21 1:45 PM, dn via Python-list wrote: Is assert so much faster/cheaper than try...except...raise? Infinitely faster when they are not there. ;-) Basically, you are looking at two different philosophies: - Always double check, get good error message when something fails vs - check during testing and QA, turn off double-checks for production for best performance possible. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 12/03/2021 10.26, Cameron Simpson wrote: > On 12Mar2021 05:31, Chris Angelico wrote: >> On Fri, Mar 12, 2021 at 3:37 AM Serhiy Storchaka wrote: >>> assert(expensive_computation()) >> >> Do you have any asserts like that, or is that a purely theoretical >> complaint? I have never once seen anything that costly - usually it'll >> be something like checking a length (and this isn't C's strlen, since >> Python can get lengths of all built-in types quickly), or some simple >> checks. > > That's very much in the eye of the beholder. Usually my asserts are > pretty cheap. But there are two scenarios where they accrue significant > cost. > > Scenario 1 is where I'm maintaining some data structure, possibly with > fiddly corner cases. That associated class may have a self_check method > to verify integrity, and that can land in an assertion. Potentially > quite expensive. > > Scenario 2 is the performance critical function which nonetheless is > complicated (or just... long). I've written a few of these and littering > the code with asserts becomes necessary to check correctness, > particularly if you're modifying it. Not everything lends itself to unit > tests - we often want to be assured of things in the middle of a > process. > > In scenario 2, each assert is pretty cheap, but their cumulative effect > has a significant performance impact. Being able to turn them off > altogether is a distinct real world win. > > (To those crying "break it up", sometimes that is hard because of the > embodied state, and sometimes that is unwanted because of the > performance impact (function calls aren't free and neither is the > packaging-into-parameters needed to turn an operation into a function > call); for 99% of code both of these are cheap enough, but in this niche > they're a problem. Having read this, and @Chris' points, am wondering if I'm missing a/the point:- (Scenarios 1 and 2, plus leaving the asserts to run in case of 'accidents' during production-execution) When testing the integrity of some collection of data, why use assert over raising a descriptive and class-identified exception? Both can be trapped by 'higher-level' code. Both can provide text-planations. Is assert so much faster/cheaper than try...except...raise? -- -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On Fri, Mar 12, 2021 at 8:20 AM Serhiy Storchaka wrote: > > 01.03.21 23:59, Cameron Simpson пише: > > On 28Feb2021 23:47, Alan Gauld wrote: > >> On 28/02/2021 00:17, Cameron Simpson wrote: > >>> BUT... It also has a __iter__ value, which like any Box iterates over > >>> the subboxes. For MDAT that is implemented like this: > >>> > >>> def __iter__(self): > >>> yield from () > >> > >> Sorry, a bit OT but I'm curious. I haven't seen > >> this before: > >> > >> yield from () > >> > >> What is it doing? > >> What do the () represent in this context? > > > > It's an empty tuple. The yield from iterates over the tuple, yielding > > zero times. There are shorter ways to write that (eg outright omitting > > the yield), except when you're writing a generator function with only a > > single yield statement - then you need something like that to make it a > > generator. > > I was wondering what from following variants is more efficient: > > def gen1(): > yield from () > > def gen2(): > return > yield > > def gen3(): > return iter(()) > > > $ python3.9 -m timeit -s 'def g(): yield from ()' 'list(g())' > 100 loops, best of 5: 266 nsec per loop > $ python3.9 -m timeit -s 'def g():' -s ' return' -s ' yield' 'list(g())' > 100 loops, best of 5: 219 nsec per loop > $ python3.9 -m timeit -s 'def g(): return iter(())' 'list(g())' > 200 loops, best of 5: 192 nsec per loop > They're not identical. The first two are, I believe, equivalent (and you could add "if False: yield" as another comparison if you care), but the third one isn't a generator. So if all you need is an iterator, sure, but gen3 actually isn't doing as much as the other two are. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 12Mar2021 05:31, Chris Angelico wrote: >On Fri, Mar 12, 2021 at 3:37 AM Serhiy Storchaka wrote: >> assert(expensive_computation()) > >Do you have any asserts like that, or is that a purely theoretical >complaint? I have never once seen anything that costly - usually it'll >be something like checking a length (and this isn't C's strlen, since >Python can get lengths of all built-in types quickly), or some simple >checks. That's very much in the eye of the beholder. Usually my asserts are pretty cheap. But there are two scenarios where they accrue significant cost. Scenario 1 is where I'm maintaining some data structure, possibly with fiddly corner cases. That associated class may have a self_check method to verify integrity, and that can land in an assertion. Potentially quite expensive. Scenario 2 is the performance critical function which nonetheless is complicated (or just... long). I've written a few of these and littering the code with asserts becomes necessary to check correctness, particularly if you're modifying it. Not everything lends itself to unit tests - we often want to be assured of things in the middle of a process. In scenario 2, each assert is pretty cheap, but their cumulative effect has a significant performance impact. Being able to turn them off altogether is a distinct real world win. (To those crying "break it up", sometimes that is hard because of the embodied state, and sometimes that is unwanted because of the performance impact (function calls aren't free and neither is the packaging-into-parameters needed to turn an operation into a function call); for 99% of code both of these are cheap enough, but in this niche they're a problem. >Having assert be a function would not make it much harder to get rid >of. It would just make it harder to get the text. Hah. I repeat my mention of the ycecream package - very neat! Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
11.03.21 20:31, Chris Angelico пише: >> assert(expensive_computation()) > > Do you have any asserts like that, or is that a purely theoretical > complaint? I have never once seen anything that costly - usually it'll > be something like checking a length (and this isn't C's strlen, since > Python can get lengths of all built-in types quickly), or some simple > checks. I have a lot of asserts when use other programming languages. Even simple bound check for index can be too expensive for optimized build. It is less common in Python because it is less common to use -O option in Python. If most users do not bother to use -O option, you do not want to make your library slower for them by adding runtime self-checks. It is not possible to enable optimization on per-package level. -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
01.03.21 23:59, Cameron Simpson пише: > On 28Feb2021 23:47, Alan Gauld wrote: >> On 28/02/2021 00:17, Cameron Simpson wrote: >>> BUT... It also has a __iter__ value, which like any Box iterates over >>> the subboxes. For MDAT that is implemented like this: >>> >>> def __iter__(self): >>> yield from () >> >> Sorry, a bit OT but I'm curious. I haven't seen >> this before: >> >> yield from () >> >> What is it doing? >> What do the () represent in this context? > > It's an empty tuple. The yield from iterates over the tuple, yielding > zero times. There are shorter ways to write that (eg outright omitting > the yield), except when you're writing a generator function with only a > single yield statement - then you need something like that to make it a > generator. I was wondering what from following variants is more efficient: def gen1(): yield from () def gen2(): return yield def gen3(): return iter(()) $ python3.9 -m timeit -s 'def g(): yield from ()' 'list(g())' 100 loops, best of 5: 266 nsec per loop $ python3.9 -m timeit -s 'def g():' -s ' return' -s ' yield' 'list(g())' 100 loops, best of 5: 219 nsec per loop $ python3.9 -m timeit -s 'def g(): return iter(())' 'list(g())' 200 loops, best of 5: 192 nsec per loop -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Fri, Mar 12, 2021 at 3:37 AM Serhiy Storchaka wrote: > > 03.03.21 01:24, Chris Angelico пише: > > On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list > > wrote: > >> > >> Am 02.03.2021 um 23:09 schrieb Stestagg: > >>> Ignoring the question about this feature being particularly useful, it > >> > >> It is useful because "assert" is primarily (if not purely and > >> exclusive) a debugging tool during development and testing. > >> > >> In production code you don't want any asserts, but logging. Having > >> "assert" being a function would make it much harder to get rid of it > >> in production code. > >> > > > > Really? > > > > if PRODUCTION: > > def assert(*a, **kw): pass > > > > would work if it were a function :) > > assert(expensive_computation()) > Do you have any asserts like that, or is that a purely theoretical complaint? I have never once seen anything that costly - usually it'll be something like checking a length (and this isn't C's strlen, since Python can get lengths of all built-in types quickly), or some simple checks. Having assert be a function would not make it much harder to get rid of. It would just make it harder to get the text. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application problems
On 11/03/2021 15:06, Anssi Saari wrote:
Thomas Jollans writes:
On 10/03/2021 21:50, Mats Wichmann wrote:
For the first one, don't feel too bad, this ("opening the normal
python") seems to be biting a lot of people recently
I wonder why. Python's installation process isn't any different from
most other Windows software released the past 25-ish years. Is it
possible that Windows 10's search feature sometimes makes poor
choices, and typing "python" just brings up the wrong thing?
I'm thinking maybe it's people who've never installed anything? Since
for Facebook or whatever you only need a browser...
Plus now there's the Microsoft Store for a lot of things, yeah
--
https://mail.python.org/mailman/listinfo/python-list
Re: Application problems
> On 10 Mar 2021, at 22:14, Thomas Jollans wrote:
>
> On 10/03/2021 21:50, Mats Wichmann wrote:
>>
>> For the first one, don't feel too bad, this ("opening the normal python")
>> seems to be biting a lot of people recently
>
>
> I wonder why. Python's installation process isn't any different from most
> other Windows software released the past 25-ish years. Is it possible that
> Windows 10's search feature sometimes makes poor choices, and typing
> "python" just brings up the wrong thing?
>
> (I just tested it on a clean VM and that's not what happens, but maybe for
> some people? I dunno
I think it is as simple as the python installer does not have the string
“setup” in the name.
I raise a bpo that is getting worked to change this hopefully for 3.10 maybe
3.11.
Barry
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
03.03.21 01:24, Chris Angelico пише: > On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list > wrote: >> >> Am 02.03.2021 um 23:09 schrieb Stestagg: >>> Ignoring the question about this feature being particularly useful, it >> >> It is useful because "assert" is primarily (if not purely and >> exclusive) a debugging tool during development and testing. >> >> In production code you don't want any asserts, but logging. Having >> "assert" being a function would make it much harder to get rid of it >> in production code. >> > > Really? > > if PRODUCTION: > def assert(*a, **kw): pass > > would work if it were a function :) assert(expensive_computation()) -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding Python installation issue
Hi, On Thu, Mar 11, 2021 at 8:57 AM APURVA DHOK wrote: > > Hi, I am Apurva > I am facing a problem with the Python installation. After installing any > Python version with(32 bit/64bit) on windows the script folder in python is > empty please help me to get pip.exe and easy_install.exe Which python did you install? Which version? You have Windows 10 or smth else? Thank you. > > Thanks & Regards > Apurva Dhok > 9145619646 > Pune, Maharashtra, India > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
IDLE python
I have tried to startup my IDLE python severally but it keeps giving the following message: IDLE’s subprocess didn’t make connection. See the ‘Startup Failure’ section of the IDLE doc online at https://docs.python.org/3/library/idle.html#startup-failure. I have gone to the page and followed all the procedures listed there but there is still no change. I need help on this Sent from Mail for Windows 10 -- https://mail.python.org/mailman/listinfo/python-list
Regarding Python installation issue
Hi, I am Apurva I am facing a problem with the Python installation. After installing any Python version with(32 bit/64bit) on windows the script folder in python is empty please help me to get pip.exe and easy_install.exe Thanks & Regards Apurva Dhok 9145619646 Pune, Maharashtra, India -- https://mail.python.org/mailman/listinfo/python-list
Re: Application problems
Thomas Jollans writes:
> On 10/03/2021 21:50, Mats Wichmann wrote:
>>
>> For the first one, don't feel too bad, this ("opening the normal
>> python") seems to be biting a lot of people recently
>
>
> I wonder why. Python's installation process isn't any different from
> most other Windows software released the past 25-ish years. Is it
> possible that Windows 10's search feature sometimes makes poor
> choices, and typing "python" just brings up the wrong thing?
I'm thinking maybe it's people who've never installed anything? Since
for Facebook or whatever you only need a browser...
--
https://mail.python.org/mailman/listinfo/python-list
Re: REPL peculiarity
On 11/03/2021 11:01, Rob Cliffe via Python-list wrote: > This is a valid Python program: > > def f(): pass > print(f) > > But at the REPL: > > >>> def f(): pass > ... print(f) > File "", line 2 > print(f) > ^ > SyntaxError: invalid syntax > > It doesn't seem to matter what the second line is. In the REPL you have > to leave a blank line after the "def" line. Why? I guess just because that's how the interpreter is written. It looks for a blank line to terminate the function definition. It does the same with multi-line definitions too. I agree it would be possible in the case of single line definitions to forego the blank line but it doesn't. It does remind you that you need another line since it shows the secondary prompt ... instead of the primary >>> -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Compare word to word files
Hello , I want to compare word to word files please he me! -- https://mail.python.org/mailman/listinfo/python-list
Re: REPL peculiarity
On 3/11/2021 6:01 AM, Rob Cliffe via Python-list wrote: This is a valid Python program: def f(): pass print(f) But at the REPL: >>> def f(): pass ... print(f) File "", line 2 print(f) ^ SyntaxError: invalid syntax It doesn't seem to matter what the second line is. In the REPL you have to leave a blank line after the "def" line. Why? REPL executes *one* statement at a time. It has always required a blank to end a compound statement because ending with a dedented second statement violates that. Something like >>> def f(): ... a = 3 is more typical. A dedented statement looks like a buggy continuation line. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Application problems
On 3/10/2021 2:25 PM, Yoosuf Oluwatosin via Python-list wrote: I have downloaded python 3.9.2 on my hp laptop with windows 10 and tried opening both the normal python and the idle python on my pc but the norml keeps opening the modify, repair and uninstall page while the idle keeps giving a startup error. How did you try to start IDLE and what 'startup error' did you see. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
REPL peculiarity
This is a valid Python program: def f(): pass print(f) But at the REPL: >>> def f(): pass ... print(f) File "", line 2 print(f) ^ SyntaxError: invalid syntax It doesn't seem to matter what the second line is. In the REPL you have to leave a blank line after the "def" line. Why? Tested am using Python 3.8.3 and 2.7.18. Rob Cliffe -- https://mail.python.org/mailman/listinfo/python-list
