The current `gcd` definition is almost accidental, in that it just happens to be what's convenient for use in normalisation in the Fraction type.  If people are using it as a standalone implementation of gcd, independent of the fractions module, then defining the result to be always nonnegative is probably a little less surprising than the current behaviour.

BTW, I don't think there's a universally agreed definition for the extension of the gcd to negative numbers (and I certainly wouldn't take Rosen's book as authoritative: did you notice the bit where he talks about 35-bit machines being common?), so I don't regard the fraction module definition as wrong, per se.  But I do agree that the behaviour you propose would be less surprising.

One other thought: if we're really intending for gcd to be used independently of the fractions module, perhaps it should be exposed as math.gcd.  (That would also give the opportunity for an optimised C version.)