But you are using 4 spaces for indent right?
The other thing you ought to get used to is the idea of an 80
character line length limit. I personally hate this, and it does make
it more work for a blind programmer. When I'm familiar with a piece of
code, I can often work out where I am by listening to just the first
few words of a line. When its split over several lines, it makes it
more work to cursor past that particular bit of code.
A small thing, but over time this adds up.
Dzhovani writes:
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 thatputting 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]
>
> --
> 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.
---
В писмото няма вируси или малуер, защото avast! Антивирус защитата е активна.
https://www.avast.com/antivirus
List web page is
//www.freelists.org/webpage/pythonvis
To unsubscribe, send email to
pythonvis-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject field.
