While implementing a Least-Common-Multiple function (LCM), I noticed that although python has a Greatest-Common-Divisor (GCD) function in the fractions module, the LCM, its counterpart is not there.

I've attached a patch which implements and tests LCM in the fractions module. 

It would really need documentation, but maybe GCD and LCD should be moved to the math module first ?

To get the boundary cases correct, you need a special case for lcm(0, 0), which should be 0.

Did you have any particular use-cases in mind for this?  It may make sense to allow multiple arguments:  e.g., lcm(4, 5, 6) -> 60.

Overall, I'm -0 on this addition: I don't think it comes up often enough to make it worth adding, and when it does come up it's easy to create the lcm from the gcd (just as your patch does).

I've handled a patch, and extended both lcm and gcd to take an arbitrary number of arguments -- via functools.reduce, as they are both multiplicative (in the first argument).

Also handled the zero case , so lcm(0,0) = 0 = gcd(0,0)

Use-case-wise, I do a reasonable amount of number-theoretic work and lcm and gcd are always popping up.  If gcd is defined, it's nice to find lcm too.  

For those less well versed in number-theory, the implementation of lcm is not so obvious, and many end up going down a tedious prime factorisation route -- if they get that far.

But is it all worth it in the fractions module ?  They should really be in the math module.

I am -0 (or more negative) for the same reason. The need for lcm is very rare. I think the gcd doc should give the lcm formula, with perhaps an index entry. The gcd doc might also mention that gcd is associative: gcd(a,b,c) = gcd(gcd(a,b),c).

The math module is nearly all float math. The integer only math.factorial(n) is relatively recent. Gcd in in fractions because we do not have an imath module and because the only use of gcd in the stdlib is for reducing fractions.

I'm going to reject this for the reasons already given above.  It's easy to write your own (lightweight, inefficient) lcm and multi-argument gcd if you need them.  For more serious work, you probably want to avoid Python's gcd anyway---it's horribly inefficient, and there are 3rd party solutions for specialised number-theoretic work (e.g., SymPy, SAGE, gmpy2).

See renewed discussion in #39479, which may lead to math.lcm being added in 3.9.