Mailman 3 January 2001 - Python-Dev

Makefile changes
by Neil Schemenauer Jan. 26, 2001

Jan. 26, 2001

I've checked in my new makefile. Hopefully everything goes well. The following files are no longer used so please don't patch them: Grammar/Makefile.in Include/Makefile Lib/Makefile Modules/Makefile.pre.in Objects/Makefile.in Parser/Makefile.in Python/Makefile.in Makefile.in They will be removed in a few days assuming all goes well. You should re-run configure to use the new makefile. I would appreciate it if people using platforms other than Linux and GNU make could give me some feedback on the build process. Does configure and make work okay? Does "make test" and "make install" work? Thanks. Neil

4 6

[PEP 232] Syntactic support for function attributes strawman.
by Michael Hudson Jan. 26, 2001

Jan. 26, 2001

Following discussion on c.l.py I've just submitted: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 which implements a syntax for adding function attributes inline: >>> def f(a) having (publish=1): ... print 1 ... >>> f.publish 1 It uses an "import-as" like strategy to avoid makeing "having" a keyword (which interacts a bit badly with error reporting, as it happens). Obviously, it would be easy to change "having" to a different word. Another idea I had was: >>> def f(a) having (.publish=1): ... print 1 ... >>> f.publish 1 to emphasize the attributeness of what's going on, but I didn't like this as much in practice (I always forgot the period!). Emile van Sebille also suggested >>> d = {'a':1} >>> def f(a) having (**d): ... print 1 ... >>> f.a 1 which I haven't implemented, because I didn't really like it, but I thought I'd mention. I'll do test suites and documentation in time, but I thought I'd call in here to check the idea wasn't DOA. What do you all think? Cheers, M. -- surely, somewhere, somehow, in the history of computing, at least one manual has been written that you could at least remotely attempt to consider possibly glancing at. -- Adam Rixey

3 2

Windows compile broken
by Tim Peters Jan. 26, 2001

Jan. 26, 2001

Linking... Creating library ./python21.lib and object ./python21.exp ceval.obj : error LNK2001: unresolved external symbol _PyCell_Set ceval.obj : error LNK2001: unresolved external symbol _PyCell_Get frameobject.obj : error LNK2001: unresolved external symbol _PyCell_New ./python21.dll : fatal error LNK1120: 3 unresolved externals Error executing link.exe. Sorry if this has already been discussed. I don't see mention of it in the Python-Dev archive, and my email is almost worse than useless (random delays of minutes to days, due to what appears to be the simultaneous worldwide wedging of every email server servicing every email account I have).

5 9

Re: [Python-checkins] CVS: python/dist/src/Include modsupport.h,2.35,2.36
by Thomas Wouters Jan. 25, 2001

Jan. 25, 2001

On Thu, Jan 25, 2001 at 02:13:36PM -0800, Fred L. Drake wrote: > The addition of new parameters to functions in the Python/C API requires > that PYTHON_API_VERSION be incremented. When we update the API version, isn't it time to clean up the TP_HASFEATURE stuff ? Since we updated the API, all the current slots should be there, right ? -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

Re: [Python-checkins] CVS: python/dist/src/Include cellobject.h,NONE,2.1 Python.h,2.30,2.31
by Neil Schemenauer Jan. 25, 2001

Jan. 25, 2001

On Thu, Jan 25, 2001 at 12:04:16PM -0800, Jeremy Hylton wrote: > A cell contains a reference to a single PyObject. It could be > implemented as a mutable, one-element sequence, but the separate type > has less overhead. Can this object be involved in reference cycles? If so, it should probably have the GC methods added to it. Neil

2 1

jeremy@alum.mit.edu
by Martin v. Loewis Jan. 25, 2001

Jan. 25, 2001

> It would be great if the Makefile captured all the dependencies. That would be great, yes. However, setup.py should probably also consider dependencies. > Could we just use makedepend? Not sure. Certainly not in the build process. I dislike distributions which, as the first thing, perform dependency generation. Dependencies change less often than the actual source, so it is should be sufficient to update them manually. Furthermore, generated files as part of the CVS repository fail to work properly unless everybody uses the exact same generator. For autoconf alone, that's a problem because of multiple autoconf versions. I don't know how many different makedepend versions are in use. Regards, Martin

2 1

Re: [Python-Dev] Fw: random.py gives wrong results (+ a solution)
by Tim Peters Jan. 25, 2001

Jan. 25, 2001

[/F, fwds a c.l.py claim that random.betavariate is dead wrong] Not to worry; I had already entered that into the SF bug database and assigned it to me (hmm: why would you send it to Python-Dev instead of putting it in the database?). I suspect he's correct, and, more importantly, so does Ivan Frohne. We'll settle it before 2.1a2, but perhaps not today. Alas, I have no idea where the original code came from ("Guido" isn't a useful answer -- he was just converting somebody else's C++ code to Python).

1 0

checkins done for PEP 227
by Jeremy Hylton Jan. 25, 2001

Jan. 25, 2001

It looks like python-dev is very slow, so you'll see my original warning well after the checkins occurred. Oh, well. They're done. Jeremy

1 0

PEP 227 checkins to follow
by Jeremy Hylton Jan. 25, 2001

Jan. 25, 2001

I am about to check in the changes that implemention PEP 227. There are many changes, which I will make via separate commits. You might want to wait until the checkins are done to do an update. I'll send a note when I'm done. I also wanted to mention that the PEP has fallen a little out of date. There are a few wrinkles that it doesn't deal with, e.g. def f(x): def g(y): return x + y del x return g For now, this raises a SyntaxError. I'll flesh out the PEP to reflect the current implemention and spec out some of the less obvious cases. I'd welcome any comments on the code itself. I know there are a number of rough edges and also, most likely, a bunch of memory leaks. I'll be working to clean things up before 2.1a2, but wanted to get the code into CVS ASAP. Jeremy

1 0

Fw: random.py gives wrong results (+ a solution)
by Fredrik Lundh Jan. 25, 2001

Jan. 25, 2001

I'm pretty sure Tim's seen this already, but just in case... ----- Original Message ----- From: "Ivan Frohne" <frohne(a)gci.net> Newsgroups: comp.lang.python Sent: Thursday, January 25, 2001 5:20 PM Subject: Re: random.py gives wrong results (+ a solution) > > "Janne Sinkkonen" <janne(a)oops.nnets.fi> wrote in message > news:m3u26oy1rw.fsf@kinos.nnets.fi... > > > > At least in Python 2.0 and earlier, the samples returned by the > > function betavariate() of random.py are not from a beta distribution > > although the function name misleadingly suggests so. > > > > The following would give beta-distributed samples: > > > > def betavariate(alpha, beta): > > y = gammavariate(alpha,1) > > if y==0: return 0.0 > > else: return y/(y+gammavariate(beta,1)) > > > > This is from matlab. A comment in the original matlab code refers to > > Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A > > (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian > > data analysis, p. 481, which I have checked and found to agree with > > the code above. > > > I'm convinced that Janne Sinkkonen is right: The beta distribution > generator in module random.py does not return Beta-distributed > random numbers. Janne's suggested fix should work just fine. > > Here's my guess on how and why this bug bit -- it won't be of interest to > most but > this subject is so obscure sometimes that there needs to be a detailed > analysis. > > The probability density function of the gamma distribution with (positive) > parameters > A and B is usually written > > g(x; A, B) = (x**(A-1) * exp(x/B)) / (Gamma(A) * B**A), where x, A, and > B > 0. > > Here Gamma(A) is the gamma function -- for A a positive integer, Gamma(A) is > the > factorial of A - 1, Gamma(A) = (A-1)!. In fact, this is the definition used > by the authors of random.py in defining gammavariate(alpha, beta), the gamma > distribution random number generator. > > Now it happens that a gamma-distributed random variable with parameters A = > 1 and > B has the (much simpler) exponential distribution with density function > > g(x; 1, B) = exp(-x/B) / B. > > Keep that in mind. > > The reference "Discrete Event Simulation in ," by Kevin Watkins > (McGraw-Hill, 1993) > was consulted by the random.py authors. But this reference defines the > gamma probability distribution a little differently, as > > g1(x; A, B) = (B**A * x**(A-1) * exp(B*x)) / Gamma(A), where x, A, B > > 0. > > (See p. 85). On page 87, Watkins states (incorrectly) that if grv(A, B) is > a function which > returns a gamma random variable with parameters A and B (using his > definition on p. 85), > then the function > > brv(A, B) = grv(1, 1/B) / ( grv(1, 1/B) + grv(1, A) ) [ not > true!] > > will return a random variable which has the beta distribution with > parameters A and B. > > Believing Watkins to be correct, the random.py authors remembered that a > gamma > random variable with parameter A = 1 is just an exponential random variable > and > further simplified their beta generator to > > brv(A, B) = erv(1/B) / (erv(1/B) + erv(A)), where erv(K) is a random > variable > > having the exponential distribution with > > parameter K. > > The corrected equation for a beta random variable, using Watkins' definition > of the > gamma density, is > > brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), > > which translates to > > brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) > > using the more common gamma density definition (the one used in random.py). > Many standard statistical references give this equation -- two are > "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, > 1986, > p. 432, and "Monte Carlo Concepts, Algorithms and Applications," by > George S. Fishman, Springer, 1996, p. 200. > > --Ivan Frohne > > > > > >>> > > > >

1 0