Hi all,
I'm the first to admit that the coma-backSpace solution is clumsy.
Actually, I used it because the join method wasn't working straight
away. However, I digged a bit into the matter and almost immediately
stumbled upon alternative solution
print ' '.join(map(str, line))
Now, whether it should be printed or pushed in to another array, it
doesn't matter before the specification is detailized and it can be
easily adjusted after that. I did the printing just because it is easier
to test that way.
Regarding the spacing and indentation, I'm using Jaws and it announces
the indentation in spaces, that is the way I have set edSharp. It is
rather comfortable for me and works much better than the braces in other
languages. If someone feels it wrong, he or she can run a simple
replacement of two spaces for one or 4 for 2 and the problem will be
solved. I am keeping it the recommended way, because I expect to work
with sighted people and as far as it is not problem for me, I prefer to
practice style that will ease my work with them.
Regards,
Dzhovani
On 3.6.2015 г. 22:36 ч., Les Smithson wrote:
What makes this a bad practice? Its use is documented, its useful and
has no unexpected side effects, and common usage counts for a lot.
AFAIK, PEP8 does not object to its use.
Jim Snowbarger writes:
>
> 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 acomma 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]
>
> --
> Les Smithson
> List web page is
> //www.freelists.org/webpage/pythonvis
>
> To unsubscribe, send email to
> pythonvis-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject field.
>
>
>
> List web page is
> //www.freelists.org/webpage/pythonvis
>
> To unsubscribe, send email to
> pythonvis-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject field.
