Mailman 3 September 2004 - Python-Dev

A cute new way to get an infinite loop
by Tim Peters 27 Sep '04

27 Sep '04

>>> x = [1] >>> x.extend(-y for y in x)

18 35

RE: [Python-Dev] A cute new way to get an infinite loop
by Batista, Facundo 27 Sep '04

27 Sep '04

[Raymond Hettinger] #- Looks good. Reads well. Solves the problem. The timings are still #- fast. The test suite runs w/o exception. These should be remembered like "The 5 conditions for a good patch" (or something). . Facundo

1 0

Fwd: [Python-Dev] a simpler way to invoke pydoc, pdb, unittest, etc
by Alex A. Naanou 27 Sep '04

27 Sep '04

oops... forgot to CC the messages to python-dev ^_^ ---------- Forwarded message ---------- From: Alex A. Naanou <alex.nanou(a)gmail.com> Date: Mon, 27 Sep 2004 17:11:45 +0400 Subject: Re: [Python-Dev] a simpler way to invoke pydoc, pdb, unittest, etc To: jim(a)zope.com On Mon, 27 Sep 2004 05:32:24 -0400, Jim Fulton <jim(a)zope.com> wrote: > Anthony Baxter wrote: > > > >> +1 on the -m command-line variation, with the following change: > >> > >> I'd like Python to import the module and then run it's main function. > >> > >> I've been meaning to suggest smething like this myself. > > > > > > I'd prefer it import the module, with __name__ == "__main__", > > because it's compatible with what we do now for a module that's > > also a script. But I like the idea, nonetheless. > > > > Question: should python -m foo.bar.baz work? I'd say "yes". > > Me too. Count me in too! ..though I must say I am against the variant with the main function, as there is an accepted and widely used mechanism in python already (__name__ == '__main__'), so why add another one or make the existing mechanism more complex... -- Alex. -- Alex.

1 0

Fwd: [Python-Dev] a simpler way to invoke pydoc, pdb, unittest, etc
by Alex A. Naanou 27 Sep '04

27 Sep '04

---------- Forwarded message ---------- From: Alex A. Naanou <alex.nanou(a)gmail.com> Date: Mon, 27 Sep 2004 17:18:20 +0400 Subject: Re: [Python-Dev] a simpler way to invoke pydoc, pdb, unittest, etc To: dima(a)hlabs.spb.ru On Mon, 27 Sep 2004 14:12:32 +0000, Dmitry Vasiliev <lists(a)hlabs.spb.ru> wrote: > Ilya Sandler wrote: > > A problem: > > > > a number of standard python modules come with a command line interfaces, > > e.g. pydoc.py, pdb.py , unittest.py, timeit.py, uu.py > > But it appears that there is no convenient out-of-the-box way to invoke > > these tools from command line... > > > > Basically one either has to write wrappers or to > > invoke them like this: python /usr/lib/python2.3/pdb.py > > > > Neither approach is convenient... > > > > Am I missing something obvious? If not, then would the following make > > sense? > > > > When a script specified from command line is not found and the script name > > does not end with py, treat the script as a module name and execute > > that module as __main__ > > > > So > > python pdb > > would be equivalent to > > python /usr/lib/python2.3/pdb.py > > > > A possible variation of the same idea would be to have an explicit > > command line option -m (or -M). More typing, but less magic... > > There is already has been some discussion about importing from command line: > http://mail.python.org/pipermail/python-dev/2003-December/041240.html > > I suggested the following: > > 1. python -p package > > Equivalent to: > > import package > > 2. python -p package.zip > > Equivalent to: > > import sys > sys.path.insert(0, "package.zip") > import package > this might not be good (IMHO), as: 1) this makes an implicit import (from the point of view of the code... (imports from outside the code that the code uses))... 2) does does not solve the problem at hand, as when a module is imported its __name__ is no longer "__main__" thus its commandline handler will not start... -- Alex. -- Alex.

1 0

Py_NewInterpreter and PyGILState API
by Christoph Wiedemann 27 Sep '04

27 Sep '04

Hello, first of all my apologies for sending this message to python-dev, but i tried comp.lang.pthon and python-help and didn't get helpful answers. My problem is, that Py_NewInterpreter and the in 2.3 introduced PyGILState API doesn't play nice with each other, especially in multithreaded embedding applications. I think, this is because PyGILState functions assume, there is exactly one PyThreadState instance per thread, and this is violated when using Py_NewInterpreter, which creates a new PyThreadState instance. I've tried to use state = PyGILState_Ensure(); PyThreadState_Get()->interp = interpreterIWantToUse; /* code using Python API */ PyGILState_Release(state); which seems to work, if called from one thread only, but this fails, if used by multiple threads with a "Fatal Python error: PyThreadState_Delete: invalid tstate." Now, most of you would say: "Don't use PyGILState API, use the 2.2 way of dealing with thread states". Unfortunately, i want to use PyQt, which uses the PyGILState API, and i found, that it's not easy (or even impossible?) to mix PyGILState calls with PyEval_SaveThread / PyEval_RestoreThread. I'm lost with this and would appreciate any help. I'm using Python 2.3 on linux x86. Christoph

1 0

Re: python/dist/src/Lib httplib.py,1.88,1.89
by Fredrik Lundh 26 Sep '04

26 Sep '04

> +++ httplib.py 14 Sep 2004 17:55:21 -0000 1.89 > @@ -525,7 +525,8 @@ > def _set_hostport(self, host, port): > if port is None: > i = host.rfind(':') > - if i >= 0: > + j = host.rfind(']') # ipv6 addresses have [...] > + if i > j: one-line alternative: i = host.find(":", host.rfind("]")) </F>

1 0

python.sty conflict with \newcommand\url
by Neal D. Becker 24 Sep '04

24 Sep '04

I hope this is the correct place to post this question. I'm trying to use python.sty to write some doc for my modules. If I try to use \hyperref package, I get this: (/usr/share/texmf/tex/latex/html/url.sty ! LaTeX Error: Command \url already defined. Or name \end... illegal, see p.192 of the manual. This is what python.sty says: % Use this def/redef approach for \url{} since hyperref defined this already, % but only if we actually used hyperref: \ifpdf \newcommand{\url}[1]{{% The comment suggest a workaround for hyperref, but it doesn't look like the code actually matches the comment. Any ideas?

1 0

Methods identity...?
by Dmitry Vasiliev 24 Sep '04

24 Sep '04

Is this intended? Seems like a bug... (Python 2.1.3, 2.2.2, 2.3.4, 2.4a3, both old- and new- style classes.) >>> class Test(object): ... def test(self): pass ... >>> Test.test is Test.test False >>> t = Test() >>> t.test is t.test False -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru

3 2

RE: [Python-Dev] Re: A cute new way to get an infinite loop
by Delaney, Timothy C (Timothy) 24 Sep '04

24 Sep '04

Terry Reedy wrote: > So, are things like this a programming bug, interpreter bug, or > language definition bug? or just a 'gotcha'? Gotcha. In pretty much every language, you have to be careful about modifying what you're iterating over. I don't see that Python should be any different ;) However, Tim's example is a bit less obvious that you are modifying the thing you're iterating over ... Hence the "cuteness" IMO. Tim Delaney

1 0

Re: [Python-checkins] python/dist/src/Objects floatobject.c, 2.132, 2.133
by Armin Rigo 23 Sep '04

23 Sep '04

Hello Tim, Your float.richcompare patch, trying to map the C semantics at the Python level, introduces artificial results when comparing NaN's with longs: >>> float('nan') > 0 False >>> float('nan') > 0L True I am not aware of all the problems and various platforms, but clearly in the patch 'vsign' by itself doesn't make much sense if 'v' is a NaN. Wouldn't all compilers and platforms compare NaNs "strangely", for some detectable definition of "stange"? Something along the lines of: #define Py_IS_NAN(v) (!Py_IS_INFINITY(v) && \ ( ((v) < 0.0 && (v) > 0.0) || \ !((v) < 1.0 || (v) > -1.0) ) Armin

2 1