Yes, four spaces in accordance with the convention.
And, yes, long lines with code are problem for me as well, so I always
try to avoid them.
I will try to pay some more attention to the deep nesting though,
because usually I can follow the code, but it is not the case with other
people it seems. Actually, in my code I put the first loop mainly to
check for empty list in the input, so it is a bit unnecessary and can be
avoided.
On 3.6.2015 г. 23:30 ч., Les Smithson wrote:
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
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]
> > >
> > > --
> > > 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.
