I'm not sure why he chose 1000

The description specifically says: Input range: ord_max <= 1000

I just figured that out while re-reading both anter69 and the other user's (who used a list) solutions. I guess this is just a trade-off between memory and time complexity. I'd not thought of taking it to an arbitrary number like 1000 (is that considered best practice?), although here it is practical and makes sense. Somehow, I can almost never think of creating a too large iterable.

if you fork and run it you'll see it runs under 3 seconds.

How did this pass the longer tests? That sum and str are too heavy operations and for me they did not pass. I had to completely change the algorithm to make it pass. :(

Yes you can. In such case Python internally uses float representation of a given int to compare the values so you don't have to worry about type conversion.

In Python it doesn't work that way for all type pairs e.g. str with int (or float). One of the languages which allows such comparisions (int with str) is JavaScript and it sometimes end up with surprising logical bugs.

I tried to avoid double listing thinking about the time efficiency which I am not sure about. Can you tell me the time-efficiency of this vs my solution, please?

any love for this translation?

but can we compare int to float (by the way i am begginer)

The return line is smart!

Description says: "An occurrence of 'and' and/or 'but' only counts when it is at least one space separated" but apparently the pyhton fixed tests expect otherwise:

'and' should equal 'and apparently'

That's effing brilliant!!

interested how I got this? see the fork for a detailed walkthrough

well.. python's modules is cheating.

omg

impressive solution

Thanks, fixed