code review

[Chris Angelico]

Hopefully you're storing password hashes, not encrypted passwords
(which can all too easily be DEcrypted), and the length of the hash is
not dependent on the length of the password. But yes, there are
certainly practical concerns here.

With a hash length of N bits, there's not much use accepting passwords
longer than about N/4 or N/2 bytes. (It would be N/8 except that most
people don't invent passwords that use the entire available alphabet.
And of course, this ignores issues of encodings, but I'm pretty sure
all current crypto hashes work with bytes not characters anyway.) But
please, don't limit password lengths too much. Make your password
system XKCD 936 compliant:

http://xkcd.com/936/

Permit long passwords consisting of nothing but lowercase letters.
They really aren't as insecure as some people think!

ChrisA

 

[Chris Angelico]

86 kg is not a weight, it's a mass. So it doesn't depend on the local
gravity situation.

Indeed it is, as he says. But I believe he may be right in that
'stone' is a unit of weight. Hard to be sure, though, given that it's
not an SI unit (for instance, the Wikipedia article text refers to
weight, but its picture shows a man measuring mass).

ChrisA

 

[kushal.kumaran+python]

On Fri, 29 Jun 2012 09:03:22 -0600, Littlefield, Tyler wrote:

On 6/29/2012 1:31 AM, Steven D'Aprano wrote:
On Thu, 28 Jun 2012 20:58:15 -0700, alex23 wrote:



They're annoying when the maximum length is unreasonably small, but
you have to have a maximum length to close off one DoS attack vector.
Without a limit, if a "user" presents a 1 GB password, then guess
what? Your system has to hash that GB of data before it can reject
it. And if you're serious about security then it will be a
cryptographic hash, and that means slow.

Well, if you waited until you had the password (however long) in a variable before you applied your maximum limits, the DoS ship has probably sailed already.

 

[Chris Angelico]

Well, if you waited until you had the password (however long) in a variable before you applied your maximum limits, the DoS ship has probably sailed already.

Only because data transfer is usually more expensive than hashing. But
I'd say that'll always be true.

ChrisA

 

[Simon Cropper]

Only because data transfer is usually more expensive than hashing. But
I'd say that'll always be true.

ChrisA

Some questions to Tyler Littlefield, who started this thread.

Q1 -- Did you get any constructive feedback on your code?

Q2 -- Did you feel that the process of submitting your code for review
met your expectation?

Q3 -- Would you recommend others doing this either on this forum or
other fora?

It appears to me - third party watching the ongoing dialog - that the
tread has gone right off topic (some time ago) and someone should really
start a new thread under a new title/subject. Most of what I have read
does not appear to be discussing your code or how you could improve your
code.

Following the last few posts, I was wondering whether some other
off-list dialog is going on or whether I am missing something.

 

[Littlefield, Tyler]

Some questions to Tyler Littlefield, who started this thread.

Q1 -- Did you get any constructive feedback on your code?

I did get some, which I appreciated. someone mentioned using PyLint.
From reading, I found it was really really pedantic, so I used PyFlakes
instead.

Q2 -- Did you feel that the process of submitting your code for review
met your expectation?

There wasn't much more to review, so yes. The info I got was helpful and
farther than it was before I started.

Q3 -- Would you recommend others doing this either on this forum or
other fora?

It appears to me - third party watching the ongoing dialog - that the
tread has gone right off topic (some time ago) and someone should
really start a new thread under a new title/subject. Most of what I
have read does not appear to be discussing your code or how you could
improve your code.

I basically just stopped after a while. It got into a my language is
better than your language, so I didn't see much constructive info. I've
started reading from the bottom though, where it looks like it's back,
and I do appreciate the rest of the info given, as well. Thanks again
for the feedback.

Following the last few posts, I was wondering whether some other
off-list dialog is going on or whether I am missing something.

--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

 

[alex23]

I basically just stopped after a while. It got into a my language is
better than your language, so I didn't see much constructive info.

To be fair, it's more "my vision of the language is better than
yours" But yes, it should've been forked into a separate thread
ages okay.

It did get me wondering, though, if there's much in the way of support
for code review in repository sites like github? Being able to
aggregate comments around the actual code itself could be really
handy.

 

[rusi]

To be fair, it's more "my vision of the language is better than
yours" But yes, it should've been forked into a separate thread
ages okay.

A program is a product of a person's creativity as is a programming
language.
They have an analogous relation as say a sculpture to chisels.
This thread is a good example of how longwindedness of a discussion
correlates with its uselessness.
However the reverse error is more insidious: programs are made by
humans and should be critiqued, whereas programming languages (in
particular python) is sacrosanct and cannot be questioned.

Too often I find that responders on this list treat as personal
affront anyone who questions python whereas the most appropriate
response would be: Nice idea but too invasive for serious
consideration.

[I am saying this in general and not for this thread:Whats wrong with
a < b < c is quite beyond me!]

 

[Mark Lawrence]

Indeed it is, as he says. But I believe he may be right in that
'stone' is a unit of weight. Hard to be sure, though, given that it's
not an SI unit (for instance, the Wikipedia article text refers to
weight, but its picture shows a man measuring mass).

ChrisA

Stone is a unit of weight (Brits know important things like this). And
with the consistency that the English language is reknowned for the
plural is, yes you've guessed it, stone

 

[Paul Rudin]

I weigh 13st 8lb - does this make me redundant?

It might mean that you have some redundant weight

 

[Mark Lawrence]

It might mean that you have some redundant weight

True indeed, although my beer free diet of the last 10 days (yes, 10
whole days) has at least got it down from 14 stone 2 pounds.

 

[John O'Hagan]

I did get some, which I appreciated. someone mentioned using PyLint.
From reading, I found it was really really pedantic, so I used PyFlakes
instead.

There wasn't much more to review, so yes. The info I got was helpful and
farther than it was before I started.

I basically just stopped after a while. It got into a my language is
better than your language, so I didn't see much constructive info. I've
started reading from the bottom though, where it looks like it's back,
and I do appreciate the rest of the info given, as well. Thanks again
for the feedback.

As one of the perpetrators, I did apologise for being OT within the body of my
replies to OT posts, but I see the irony. I guess I just thought somebody else
would do it eventually. I hereby apologise for not taking the correct action,
and vow to do so in future: to change the subject line regardless of who
initially went OT, starting now.

Regards,

 

[Simon Cropper]

As one of the perpetrators, I did apologise for being OT within the body of my
replies to OT posts, but I see the irony. I guess I just thought somebody else
would do it eventually. I hereby apologise for not taking the correct action,
and vow to do so in future: to change the subject line regardless of who
initially went OT, starting now.

Regards,

thanks

bet this kills the conservation though...

Simon

 

[Chris Angelico]

bet this kills the conservation though...

Probably. Until someone trolls the list again and sets us all going...

I'm another of the worst perps, so in the words of Pooh-Bah, "I desire
to associate myself with that expression of regret".

It was a pretty good discussion actually. The only real problem was
the subject line.

ChrisA

 

[Mark Lawrence]

Probably. Until someone trolls the list again and sets us all going...

I'm another of the worst perps, so in the words of Pooh-Bah, "I desire
to associate myself with that expression of regret".

It was a pretty good discussion actually. The only real problem was
the subject line.

ChrisA

As far as I'm concerned nothing is OT here unless it is blatant trolling
or spamming. It makes for a far more interesting read than the groups
that have a policy of "if it's not in the standard, we won't discuss
it". The set of languages that start with the third letter of the
English language springs instantly to my mind.

Agreed that the subject line should be changed.

 

[lars van gemerden]

It's not a matter of "I wouldn't have understood what the author was
trying to do" (with a small caveat), it's a matter of "I'd have assumed
that the author didn't understand the language semantics."

I'm pretty sure it goes contrary to *every other programming language
I've ever used* (and a couple that I haven't).

I understand why Python does it, and it certainly is nice in that it
matches typical mathematical notation, but the surprise quotient is
*very* high in the PL world IMO.

Evan

Avoiding suprises would mean we cannot improve languages, just reshuffle features?

Cheers, Lars

 

[lars van gemerden]

It's not a matter of "I wouldn't have understood what the author was
trying to do" (with a small caveat), it's a matter of "I'd have assumed
that the author didn't understand the language semantics."

I'm pretty sure it goes contrary to *every other programming language
I've ever used* (and a couple that I haven't).

I understand why Python does it, and it certainly is nice in that it
matches typical mathematical notation, but the surprise quotient is
*very* high in the PL world IMO.

Evan

Avoiding suprises would mean we cannot improve languages, just reshuffle features?

Cheers, Lars

 

[Steven D'Aprano]

Avoiding suprises would mean we cannot improve languages, just reshuffle
features?

No, of course not.

But there have been hundreds of programming languages, including many
different programming paradigms (procedural, imperative, object oriented,
stack-based, functional, logic, aspect, event-driven, natural language,
and many others), and tens of millions of person-days worth of experience
in programming. It's not 1960 any more, in general terms we mostly have a
good idea of what works and what doesn't. (Sadly, when I say "we" I mean
collectively. Many language designers, and programmers, don't have the
foggiest clue as to what makes a good clean design. Hence C++ and PHP.)

The days when you could expect a brilliant new programming paradigm to
lead to a massive improvement in programmer productivity, like going from
assembly code to Fortran, are long gone. Now we look for incremental
improvements. (Although of course there is always a chance that some yet
unthought of new paradigm will revolutionise computer programming -- but
I wouldn't bet on it.)

When you're dealing with a well-designed, mature language like Python,
you are even more limited. There's only so many changes you can make
without turning it into a completely different language. And if you care
about backward compatibility and wish to avoid breaking existing
programs, there are even fewer changes that can be considered.

Many good programming features must be avoided, not because they are bad,
but because they don't match the rest of the language. Even though Python
copies features from many different paradigms and languages, there is a
mostly unified style of good Python code and any feature that doesn't
match that style should be left out. There's few things worse than a
language with random features just bolted on.

 

[Albert van der Horst]

Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay give
chained comparisons the standard meaning. It is, or was, a feature
request for Boo, but I can't tell whether it has been implemented or not.

Algol 68 does not. It has promoted operator symbols to first
class citizens. In that context chained comparison operators
cannot be made to work.
Both Mathematica and Perl are ad-hoc-ish languages. I would
hate Python go that way.

From now on, for each operator I would have to remember wether it
is a supposedly comparison operator or not.

Comparison operations on booleans make sense.
I remember a FORTRAN compiler complaining about me
comparing LOGICALS. The lack of abstraction!

C-like semantics are next to useless, except perhaps for obfuscation:

http://stackoverflow.com/questions/4089284/why-does-0-5-3-return-true/

And surprising:

http://answers.yahoo.com/question/index?qid=20090923172909AA4O9Hx

C-like semantics are a clear case of purity of implementation overruling
functional usefulness.

The worst of is, of course, = for assignment instead of := .
This is a convention that Python follows, to my dismay.

Groetjes Albert

 

[Steven D'Aprano]

Algol 68 does not. It has promoted operator symbols to first class
citizens. In that context chained comparison operators cannot be made to
work.
Both Mathematica and Perl are ad-hoc-ish languages. I would hate Python
go that way.

Perl 5 does not have chained comparisons. Perl 6, which is more designed
and less ad-hoc, does.

From now on, for each operator I would have to remember wether it is a
supposedly comparison operator or not.

Are you often in the habit of using operators *without* remembering what
they do? <wink>

I can't speak for you, but it isn't often that I've found myself not
remembering whether the less-than operator < means "compare two values"
or "multiply two values".

Comparison operations on booleans make sense.

Actually, no. Is True less than False, or is it greater? In boolean
algebra, the question has no answer. It is only an implementation detail
of Python that chooses False < True.

Of course, equality and inequality make sense for all values. But the
other comparison operators, < <= >= > only make sense for values which
are ordered, like real numbers (but not complex numbers), strings, and
similar, or for set comparisons (subset and superset). Arbitrary types
may not define comparison operators.

I remember a FORTRAN
compiler complaining about me comparing LOGICALS. The lack of
abstraction!

The opposite: LOGICALS are abstract values which do not define greater
than or less than.

The worst of is, of course, = for assignment instead of := . This is a
convention that Python follows, to my dismay.

*shrug*

The worst is to use = for both equality and assignment, like some BASICs.
At least Python does not allow assignment as an expression, so you can't
make the typical C error of:

if x = y: do_something() # oops meant x == y