Mailman 3 March 2002 - Python-Dev

bool and Numeric
by Paul F Dubois 08 Mar '02

08 Mar '02

FYI: Numeric makes arrays of anything. Indeed, when given a list of items to use to construct an array, it falls back to "Object" as the typecode of the result if the items don't have compatible types. (I.e., Numeric.array([1,2.]) has typecode Numeric.Float, but Numeric.array([1, None]) would be typecode Numeric.PyObject. (The Numeric typecodes are a superset or the same as the ones in Python's array class, I think). If indeed PyInt_Check would identify a bool as an integer, we are either ok or we can be made ok as far as the constructor goes, in that Numeric.array([1,True]) will end up as typcode Numeric.Int; but so would Numeric.array([True,False]). And as I said, this is going to cause several new "well it is screwed up but take it or leave it" entries into the manual. E.g., x=Numeric.array([True,False]); print x[0] will end up printing 1, not True.

1 0

Bool type and arrays
by Paul F Dubois 08 Mar '02

08 Mar '02

Guido said not to "mix up" the question of bit arrays with the bool proposal, but really, they *are* mixed up. The minute there is a bool type in Python people will be able to make Numeric arrays (not to mention Python arrays) with elements of type "bool". They will then be annoyed to learn that they are making arrays of objects and the result is a big array, not a small array, and that they would have been better off with our byte integer arrays. Depending on the implementation, mixing in bool values in a list of integers might persuade Numeric's array constructor to make them all objects. In short, they are mixed up in the sense that this proposed intellectual nicety will cause us Nummies a lot of grief. Not that you aren't allowed to give us grief, like you did with the "true division", but I wanted people to know they would be inflicting pain. BTW: There is quite a bit of pent-up demand in the Numeric community for bit arrays. However, nobody knows how to do it since the internal Numpy structures use a byte as the atomic unit of addressing.

3 2

Re: PEP 285 again -- correction?
by Hans Nowak 08 Mar '02

08 Mar '02

Hum, as usual, I wasn't thinking... if bool is a subclass of int, then we should still be able to add booleans to ints, right? In that case, that code would not break. I was thinking of a strict Pascal-ish boolean. (You can imagine I was worried. ;-) <slaps forehead> I'll crawl back in my shell now, where I belong... :-( --Hans Nowak (vaporeon(a)wanadoo.nl) http://www.awaretek.com/nowak/

2 1

Modules/config.c on win32 (mingw port)
by Gerhard Häring 08 Mar '02

08 Mar '02

Hello all, I'm progressing with my mingw port. The current state is that I can build a Python DLL and EXE with only minimally babysitting the build process. This looks already pretty nice, doesn't it? Python 2.3a0 (#47, Mar 8 2002, 08:49:19) [GCC 2.95.3-6 (mingw special)] on mingw32_nt-5.11 Type "help", "copyright", "credits" or "license" for more information. >>> :-) The only "babysitting" needed is to add threadmodule.o, posixmodule.o and signalmodule.o to the MODULE_OBJS in the Makefile. Problem 1 is how to get rid of that? Anybody has an idea? Problem two is that even if I add these to the MODULE_OBJS, Modules/config.c isn't appropriately created. I currently haven't got any idea how to achieve this. To be honest, the part of the build process (Modules/makesetup and friends) which statically links modules to the Python interpreter puzzles me as a whole. It would be really nice if you could give me some tips. Gerhard

1 0

Modules/config.c on win32 (mingw port)
by Gerhard Häring 08 Mar '02

08 Mar '02

Hello all, I'm progressing with my mingw port. The current state is that I can build a Python DLL and EXE with only minimally babysitting the build process. This looks already pretty nice, doesn't it? Python 2.3a0 (#47, Mar 8 2002, 08:49:19) [GCC 2.95.3-6 (mingw special)] on mingw32_nt-5.11 Type "help", "copyright", "credits" or "license" for more information. >>> :-) The only "babysitting" needed is to add threadmodule.o, posixmodule.o and signalmodule.o to the MODULE_OBJS in the Makefile. Problem 1 is how to get rid of that? Anybody has an idea? Problem two is that even if I add these to the MODULE_OBJS, Modules/config.c isn't appropriately created. I currently haven't got any idea how to achieve this. To be honest, the part of the build process (Modules/makesetup and friends) which statically links modules to the Python interpreter puzzles me as a whole. It would be really nice if you could give me some tips. Gerhard

1 0

Re: [Python-Dev] For review: PEP 285: Adding a bool type
by David Abrahams 08 Mar '02

08 Mar '02

> > Do you propose to change the type of "x == y" et. al. from int --> bool? > > Yup. > > > Sounds good to me. > > I know. :-) > > > In general, I can change my doctests to use assert rather than looking > > for 1 or 0. > > Hm, assert is the wrong thing though, since it's optimized away in -O > mode. You may have to create your own function "check(x)" that does > nothing on true but raises an exception on false, or prints "Yes" or > "No", or something like that. Ick. Not that I run my doctests in -0 mode, though.

1 0

Please Vote -- Generator Comprehensions
by Raymond Hettinger 08 Mar '02

08 Mar '02

After about 30 reviewers, the comments on PEP 279, Enhanced Generators, have slowed to a trickle. The most universally liked part of the proposal is the addition of generator comprehensions. No negative feedback was received on generator comprehensions; however, one person wanted to go further and add restartability; also, there was a little heartburn about why the existing list comprehensions expose their looping variable. Before I send generator comprehension portion to Guido for pronouncement, I would like to get all of your votes +1 or -1 on just the part about Generator Comprehensions. Everyone, please vote +1 or -1. Thank you, Raymond Hettinger Here is the proposal in a nutshell: If a list comprehension starts with a 'yield' keyword, then express the comprehension with a generator. For example: g = [yield (len(line),line) for line in file if len(line)>5] print g.next() This would be implemented as if it had been written: def __tempGenComp(self): for line in file: if len(line) > 5: yield (len(line), line) g = __tempGenComp() print g.next() The full PEP is at http://python.sourceforge.net/peps/pep-0279.html. The PEP has a full discussion of the restartability issue, an analysis of why the loop variable should not be exposed, and thoughts on why the syntax is appropriate. It represents the collective wisdom of all the review comments submitted to-date.

14 14

Moving bugs and patches through the pipeline more quickly
by Skip Montanaro 08 Mar '02

08 Mar '02

I'm giving this message a new subject and redirecting it to python-dev, mostly to consider the last two paragraphs. It was originally part of a thread about raw_input() not flushing stdout before emitting its prompt in certain situations. JG == Jonathan Gardner, MH == Michael Hudson. JG> I will write another bug report about the unresponsiveness to bug JG> reports as well, as there are a lot of bugs that aren't even JG> addressed at sourceforge. MH> Oh, that will help, sure. Jonathan> It is a bug. There needs to be a fix for it. Do you need more Jonathan> volunteers? How do we get involved? Where do we sign up? What Jonathan> needs to be done? Maybe there needs to be more coordination Jonathan> and less coding at the top. Two things should help move things through the mill faster: * If you think you know how to fix the bug, submit a patch along with your bug report to SF. * Assign it to just about anybody so someone is notified. The exceptions here are that I don't think you should assign bugs to one of the PythonLabs Five (Guido, Tim, Barry, Jeremy, Fred). Let one of the other developers decide if it warrants their attention. As the Python user base grows I think we do need a way to expand the developer pool without a lot of effort because the amount of feedback is always going to be proportional to the number of users. It's not immediately obvious to me how this should happen. The first expansion from the original five to roughly the current crop of developers wasn't terribly difficult, because for the most part Guido et al either knew them personally or had a long enough exposure to them on the net to feel confident they would make positive contributions. The overall community is large enough now that not all potentially good developers become visible easily. Requiring a somewhat rigorous vetting process will consume more time for the current developers and distract people from time working on the code base. On the other hand, not requiring any vetting is likely to allow the occasional donkey into the corral with the horses. There are people here with experience in other large(r) open source projects (Perl, Apache, Mozilla). How do they handle this problem? -- Skip Montanaro (skip(a)pobox.com - http://www.mojam.com/)

13 30

Re: [Python-Dev] pydoc 1.58 - added repr_str
by Michael Hudson 08 Mar '02

08 Mar '02

Skip Montanaro <skip(a)pobox.com> writes: > I just checked in pydoc.py 1.58. The change of type("").__name__ > from "string" to "str" between Python 2.1 and 2.2 busted the special > method lookup in pydoc.HTMLRepr and pydoc.TextRepr. This belongs in > 2.2.1. Noted. > SF seems at least mildly busted at the moment. Yes. Cheers, M. -- 48. The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

1 0

FW: PEP Parade
by Tim Peters 08 Mar '02

08 Mar '02

-----Original Message----- From: Tim Peters [mailto:tim@zope.com] Sent: Friday, March 08, 2002 1:05 AM To: python-announce(a)python.org; Python list Subject: PEP Parade Quoting Guido's new "Parade of the PEPs" essay at http://www.python.org/doc/essays/pepparade.html """ To start off Developer's Day at the Python10 conference I gave a keynote ending in what I dubbed "the parade of the PEPs". It was a brief overview of all open PEPs, where I gave my highly personal and subjective opinion for each PEP. Later, I realized that this might have been of interest to other developers. I didn't take notes at the conference, so below is a different set of comments that I created from scratch during a single two-hour sitting on March 7, 2002. """ Since Guido's "highly personal and subjective opinions" are nevertheless destined to circumscribe every waking moment of your Python life, everyone interested in Python development should give it a good read. It's also linked to from the PEP Index page at SourceForge: http://python.sf.net/peps/ Note that Guido wants to keep 2.3 free of new core language features. You can deduce that from reading the essay, or-- like me --you can just believe it because it's true <wink>. There's a huge backlog of good ideas for improving the internals and libraries, and I wouldn't be surprised to see the focus remain there for 2.4 too.

2 1