You said:
Using a trailing comma after a print is routine and not at all obscure.
Just because people do it, doesn't mean I would call it a good practice. It
might be expected if you are steeped in the nuances of a particular language.
But, it isn't ordinarily obvious. I have often said the the use of the word
"code" is misleading, in that it suggests that the logic for a particular
solution canbe be obscure. Some people even pride themselves over how clever
and compact, even hard to puzzle out, their "code" is. And, if you can't
understand it, then maybe you're just not smart enough. But, over the years, I
have come to appreciate the ease of maintainability. Stuff should be apparent,
and not clever and hidden.
There are several things in Python that are clever and codey. You'd think you
were writing in AWK or something. There are constructs that do lots of things
in a single line. And, people are attracted to the apparent compactness. But,
to figure out what the line does, you can't just breeze past it, you generally
need to stare at it a while. Complex comprehensions are a great example.
But, often, when you dig into a piece of logic to fine-tune it, you might not
be expert in the particular language. So, a simple comment, if this technique
is to be used, would help point out the subtle underlying behavior that the
true language expert would find second nature.
-----Original Message-----
From: pythonvis-bounce@xxxxxxxxxxxxx [mailto:pythonvis-bounce@xxxxxxxxxxxxx] On
Behalf Of Les Smithson
Sent: Wednesday, June 03, 2015 1:29 PM
To: pythonvis@xxxxxxxxxxxxx
Subject: [pythonvis] Re: Short projet
Hi: I'd like to disagree with a few of your points:
Using a trailing comma after a print is routine and not at all obscure.
Ditto the break statement. Its routinely used to break from loops and does not
imply an error.
PEP8 says that indents should always be 4 spaces.
I do agree with your comments about deep nesting though. Its hard enough to
follow if you're sighted, let alone blind.
Jim Snowbarger writes:
Thank you for this. As near as I can tell, this meets the original
requirements.
You were seeking feedback, so here are a few personal observations, many
just a matter of opinion and preference. But, for what it’s worth… > > >
> I learned a few things from this. I didn’t realize that putting a comma
after the print statement would prevent moving to the next line, but would
instead insert a space, and stay on the same line. So, the space separation
seems to be provided simply by the fact that python is inserting a space on
it’s own. Is that right?
It works, but seems a little less desireable, and less than explicit, to
have the code depend on an obscure behavior like that.
And, I was surprised by the printing of the backspace to retract a
character. I didn’t realize it would do that. That is a little messy, even
though it apparently works. It would be better behaved code if it didn’t
employ this method to correct for itself. That is, in general, it is better
for code to always do the right thing, than it is for it to knowingly do the
wrong thing, however temporarily, and then take a step to correct for it.
But, I’m sure you already knew that.
Yep, I think you could condense that to one loop pretty easily, since both
loops have the same conditional, except that the inner loop is routinely
escaped using the break statement.
Usually, people will use something like break to handle some strange
exception, not typical behavior.
This works correctly, but, as you say, could be refined.
In reading this code, there are cases where two blocks end at the same
point. So, you will see two outdents. This code does it correctly. But, I
sometimes find it a little disconcerting to keep track of.
Sighted people probably love you for indenting 4 spaces. Being a braille
user, I prefer two. But, using 4 has the unintended consequence of
discouraging deep nesting. People often say that, if your functions are
deeply nested, it is a sign that the function should be decomposed, and
broken into multiple functions to handle some of the inner portions of the
logic.
That problem doesn’t necessarily pertain to this code.
But, even so, since statements are still running off the end of the display,
I still lean toward 2 spaces. Just my personal opinion about that.
I have attached an edited version of this code, where I show a technique
that I use to keep myself straight. By inserting, #endif, or something
similar, I remind myself that this isn’t an indentation mistake, but was
intentional.
It’s just a habit of my own that I offer in case you find it useful.
It sure helps me keep track of things.
I did not edit it for this, but I also am getting in the habit of putting a
comment block at the start of each function, to clearly describe the inputs
and the returned values.
You can figure all that out by reading the code. But, the intent of the
comment is to prevent you from having to slog through it all , just to
figure out how to use it.
Usually, that takes the form of a couple lines, > > #inputs: list and
briefly describe each input, one per line.
#returns: list and briefly describe each returned value, one per line.
Maybe this should be enclosed in the triple quotes, so it can be learned
with the help statement.
DocString?
Anyway, thanks very much for this. It seems to be functionally correct.
But, in recognition of the fact that most problems have an infinite number
of solutions, which makes me feel better in light of the apparent fact that
some probmes have no solution at all, it would be interesting to be able to
score a solution not just on whether it meets an input/output requirement,
but on it’s efficiency as well.
In general, my priorities would be:
1. Proper behavior
2. Readability and maintainability.
3. Efficiency.
So, does anybody know right off the top how to acquire high-resolution time
from the operating system? It would be cool to be able to stress test
various solutions, and see how long each takes.
From: pythonvis-bounce@xxxxxxxxxxxxx [mailto:pythonvis-bounce@xxxxxxxxxxxxx]
On Behalf Of Dzhovani > Sent: Wednesday, June 03, 2015 12:35 AM > To:
pythonvis@xxxxxxxxxxxxx > Subject: [pythonvis] Re: Short projet > > > >
Hi,
I'm not sure that it is the best solution, so any critisism will be highly
appreciated. The code is attached, but I'm pasting it below as well:
def presentNums(seq):
seq.reverse() # reverse the list for faster pop operation later
while len(seq) > 0:
line = [] # creates the line to be printed and sets it to be empty
at the beginning of the iterate
length = 0 # the supposed length of the printed line
prolong =0 # prolong will be a variable to hold how longer the line
will become. it adds one for the space in between
while len(seq) > 0:
if seq[-1] < 10:
prolong = 2
elif seq[-1] < 100:
prolong = 3
else:
prolong = 4
length += prolong
if length <= 33:
line.append(seq.pop())
else:
break # leaves the inner loop
for each in line:
print each,
print "\b" # after the line is printed, it removes the last space
from the line
seq = [1, 2, 3, 4, 56, 76, 100, 99, 56, 29, 82,93, 74, 48, 95, 43, 25, 36,
71, 100, 100, 100, 100, 13, 100,37, 86, 100, 100] > print "start function"
presentNums(seq)
On 2.6.2015 г. 17:33 ч., derek riemer wrote:
Oddly enough, I needed a variant this function that splits a 1 dimentional
string into a 2 dimentional array of row length 10 yesterday and wrote it.
but I will hold off posting it in case anyone wishes to write it.
On 5/31/2015 7:58 PM, Jim Snowbarger wrote:
Anybody want to take a crack at this one?
Write a function that takes a list, of indefinite size. The list elements
consist of numbers, in the range of 1 to 100, but you have no idea how many
list elements there will be. Typical list But, as a sample, lengths might
be 50 elements at most.
Process the list, and print the output in a series of lines that do not
exceed 32 characters each.
Numbers on each line should be separated by a single space, and a number
should not span multiple lines.
Because the numbers are in the range of 1 through 100, some numbers take
fewer spaces than others, That is, the number 1 should be written as “1”
not “001” , nor be space padded, such as “ 1”. Think of packing numbers
together in the interests of conserving braille display real estate.
If anybody takes it on, let me know.
_____
<http://www.avast.com/>
В писмото няма вируси или малуер, защото avast! Антивирус
<http://www.avast.com/> защитата е активна.
x[DELETED ATTACHMENT shortproject_snowman.py, plain text]
