Can confirm that caps lock on european keyboard behaves like permanently pressing shift key. This means caps lock and shift key at once negate each other.
The description should say "caps lock only matters to letters". From the tests we only know it doesn't apply to numbers but have to find out ourselves about special characters like comma or apostrophe.
Interestingly, the site groups code that imports outside the function with code that imports inside the function. Check the variations and you'll see. It just happened to choose the one with the import inside as the canonical version for some reason.
For the most part, you are right. PEP 8 recommends only importing at the top of a file. Doing otherwise makes debugging much harder. However, technically there might be very rare situations where you might want to import inside of a function -- if only that function ever needs that module, the function is rarely or never called, and you don't want to pollute the global namespace, or if you want to defer and handle ImportError exceptions on a case-by-case basis, or you want to do some sort of conditional import depending on the passed parameters. Some others say they use it to resolve circular dependency issues, but that can almost always be avoided with a little restructuring of the affected files without the overhead a local import would involve.
He traverses the entire array at most one time.
This solution is faster than your solution: random tests in 390ms vs 450ms.
Can confirm that caps lock on european keyboard behaves like permanently pressing shift key. This means caps lock and shift key at once negate each other.
The description should say "caps lock only matters to letters". From the tests we only know it doesn't apply to numbers but have to find out ourselves about special characters like comma or apostrophe.
isn't it already a list?
I laughed too hard at this my face hurts
Interestingly, the site groups code that imports outside the function with code that imports inside the function. Check the variations and you'll see. It just happened to choose the one with the import inside as the canonical version for some reason.
For the most part, you are right. PEP 8 recommends only importing at the top of a file. Doing otherwise makes debugging much harder. However, technically there might be very rare situations where you might want to import inside of a function -- if only that function ever needs that module, the function is rarely or never called, and you don't want to pollute the global namespace, or if you want to defer and handle ImportError exceptions on a case-by-case basis, or you want to do some sort of conditional import depending on the passed parameters. Some others say they use it to resolve circular dependency issues, but that can almost always be avoided with a little restructuring of the affected files without the overhead a local import would involve.
bad testing
No.
This comment is hidden because it contains spoiler information about the solution
This comment is hidden because it contains spoiler information about the solution
Duh
Just because I wanted to code golf it - aka having the shortest solution ;)
Here is the ungolfed version
I've used the fact you mentioned to golf this kata.
This solution is 300% faster than this one (5000 elements are generated with
[5]*3000)There is no specific instruction for Python. The description is (almost) language agnostic but it nevertheless says:
Maybe a pair is not exactly a tuple but you could (should?) have seen the Sample tests:
I don't consider that as an issue and I am very sorry for your first try though it wouldn't have given you more points:-)
Right. Sorry for this. I am still at learning stage.
What does it mean?
Loading more items...