Split string in half and change case accordingly
up vote
11
down vote
favorite
I found the following challenge online:
Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.
eg:
foobar == fooBAR
If it is an odd number then 'round' it up to find which letters to uppercase.
That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:
def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf
but that seems repetitive and inefficient.
What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.
python strings programming-challenge
add a comment |
up vote
11
down vote
favorite
I found the following challenge online:
Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.
eg:
foobar == fooBAR
If it is an odd number then 'round' it up to find which letters to uppercase.
That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:
def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf
but that seems repetitive and inefficient.
What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.
python strings programming-challenge
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12
add a comment |
up vote
11
down vote
favorite
up vote
11
down vote
favorite
I found the following challenge online:
Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.
eg:
foobar == fooBAR
If it is an odd number then 'round' it up to find which letters to uppercase.
That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:
def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf
but that seems repetitive and inefficient.
What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.
python strings programming-challenge
I found the following challenge online:
Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.
eg:
foobar == fooBAR
If it is an odd number then 'round' it up to find which letters to uppercase.
That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:
def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf
but that seems repetitive and inefficient.
What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.
python strings programming-challenge
python strings programming-challenge
edited Apr 15 '15 at 5:36
200_success
127k15149412
127k15149412
asked Apr 15 '15 at 3:48
Seth
158312
158312
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12
add a comment |
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12
add a comment |
2 Answers
2
active
oldest
votes
up vote
15
down vote
accepted
Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.
def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf
At that point, it becomes small enough to not need the temp variables:
def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()
print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))
http://ideone.com/CqUdl5
Note the use of the integer divide which is suitable for both python 2.x and 3.
It might be/certainly is over expressive but i'd be tempted to return""
onmid==0
to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simplemid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meantlen(silly) == 0
?
– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
I'm just mentioning it for completeness, but personally I find- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36
add a comment |
up vote
0
down vote
If it were me I'd just go for brevity and ensure the function name is expressive:
def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])
EDIT:
I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:
def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change(len(input_string) + 1)/ 2
topivot_index
and perhaps move"".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
|
show 5 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
accepted
Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.
def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf
At that point, it becomes small enough to not need the temp variables:
def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()
print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))
http://ideone.com/CqUdl5
Note the use of the integer divide which is suitable for both python 2.x and 3.
It might be/certainly is over expressive but i'd be tempted to return""
onmid==0
to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simplemid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meantlen(silly) == 0
?
– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
I'm just mentioning it for completeness, but personally I find- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36
add a comment |
up vote
15
down vote
accepted
Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.
def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf
At that point, it becomes small enough to not need the temp variables:
def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()
print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))
http://ideone.com/CqUdl5
Note the use of the integer divide which is suitable for both python 2.x and 3.
It might be/certainly is over expressive but i'd be tempted to return""
onmid==0
to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simplemid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meantlen(silly) == 0
?
– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
I'm just mentioning it for completeness, but personally I find- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36
add a comment |
up vote
15
down vote
accepted
up vote
15
down vote
accepted
Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.
def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf
At that point, it becomes small enough to not need the temp variables:
def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()
print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))
http://ideone.com/CqUdl5
Note the use of the integer divide which is suitable for both python 2.x and 3.
Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.
def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf
At that point, it becomes small enough to not need the temp variables:
def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()
print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))
http://ideone.com/CqUdl5
Note the use of the integer divide which is suitable for both python 2.x and 3.
answered Apr 15 '15 at 4:06
rolfl♦
90.6k13190394
90.6k13190394
It might be/certainly is over expressive but i'd be tempted to return""
onmid==0
to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simplemid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meantlen(silly) == 0
?
– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
I'm just mentioning it for completeness, but personally I find- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36
add a comment |
It might be/certainly is over expressive but i'd be tempted to return""
onmid==0
to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simplemid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meantlen(silly) == 0
?
– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
I'm just mentioning it for completeness, but personally I find- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36
It might be/certainly is over expressive but i'd be tempted to return
""
on mid==0
to be explicit.– Aiden Bell
Apr 15 '15 at 21:11
It might be/certainly is over expressive but i'd be tempted to return
""
on mid==0
to be explicit.– Aiden Bell
Apr 15 '15 at 21:11
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simple
mid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0
?– rolfl♦
Apr 15 '15 at 21:15
@AidenBell - it certainly could be more efficient for sillily small sillies, but the simple
mid==0
would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0
?– rolfl♦
Apr 15 '15 at 21:15
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27
1
1
I'm just mentioning it for completeness, but personally I find
- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.– Veedrac
Apr 21 '15 at 7:36
I'm just mentioning it for completeness, but personally I find
- (-x // y)
should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.– Veedrac
Apr 21 '15 at 7:36
add a comment |
up vote
0
down vote
If it were me I'd just go for brevity and ensure the function name is expressive:
def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])
EDIT:
I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:
def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change(len(input_string) + 1)/ 2
topivot_index
and perhaps move"".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
|
show 5 more comments
up vote
0
down vote
If it were me I'd just go for brevity and ensure the function name is expressive:
def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])
EDIT:
I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:
def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change(len(input_string) + 1)/ 2
topivot_index
and perhaps move"".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
|
show 5 more comments
up vote
0
down vote
up vote
0
down vote
If it were me I'd just go for brevity and ensure the function name is expressive:
def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])
EDIT:
I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:
def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)
If it were me I'd just go for brevity and ensure the function name is expressive:
def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])
EDIT:
I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:
def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)
edited Apr 17 '15 at 5:18
answered Apr 15 '15 at 4:12
Scott Lobdell
1452
1452
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change(len(input_string) + 1)/ 2
topivot_index
and perhaps move"".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
|
show 5 more comments
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change(len(input_string) + 1)/ 2
topivot_index
and perhaps move"".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
2
2
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change
(len(input_string) + 1)/ 2
to pivot_index
and perhaps move "".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.– Scott Lobdell
Apr 16 '15 at 19:40
If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change
(len(input_string) + 1)/ 2
to pivot_index
and perhaps move "".join(string_as_list)
to its own line but otherwise this seems like a straightforward list comprehension to me.– Scott Lobdell
Apr 16 '15 at 19:40
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02
1
1
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04
1
1
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55
|
show 5 more comments
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f86933%2fsplit-string-in-half-and-change-case-accordingly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12