Mailman 3 August 2004 - Python-Dev

PEP 318: Suggest we drop it
by Kevin J. Butler Aug. 19, 2004

Aug. 19, 2004

- There is no universally liked syntax (or even a universally _tolerable_ syntax) - decorators will incosistently retain or drop docstrings (this may even be the most appropriate thing to do) - a "decorated" function may have an arbitrarily distant relationship with the function as implemented in the def statement (this is a killer) - if you want to decorate a single function two separate ways, you're back to 2.3 syntax - say, one that logs, checks parameters, etc., and the "internal" optimal version. None of the decorator syntaxes facilitate this. Because of all these issues, I think we should drop PEP 318. The 2.3 form seems more reasonable all the time: def __func( self ): pass spanishInquisition = mydecorator( __func ) spanishInquisition.__doc__= """Something unexpected""" parrot = otherdecorator( __func ) parrot.__doc__ = """And now for something completely different""" Are any of the syntaxes enough better to justify the irritation or divisiveness of including it? Syntactic sugar causes cancer of the semicolon, indeed... kb

4 3

RE: [Python-Dev] Unifying Long Integers and Integers: baseint
by Michael Chermside Aug. 19, 2004

Aug. 19, 2004

> > > > if the only reason for it is to use isinstance? > > > > > > So that an extension author *could* write an int-like type deriving > > > from it? > > > > But didn't you just say that people shouldn't be > > deriving their own int-like types from baseinteger? > > Indeed, in general they shouldn't. But for specialized purposes it > might be needed (that's why I emphasized *could*). I call YAGNI. We're talking about creating the class baseinteger which might be useful ONLY for people creating new kinds of integers in Python which will NOT extend int or long but WILL need to be treated just like integers. Who is really likely to do that? And if in the process we introduce a new class which won't be needed in the long run (ie Python 3000 has just one type, called "int" and has no need for baseinteger). So I maintain that it's not needed (and is, in fact, confusing to users) unless someone has a real use case. -- Michael Chermside

2 1

RE: [Python-Dev] PEP 318: Can't we all just get along?
by Delaney, Timothy C (Timothy) Aug. 19, 2004

Aug. 19, 2004

Guido van Rossum wrote: > Is anybody seriously trying to come up with a single alternative > decorator proposal that most folks "out there" can support, to be > presented to me (with implementation, please!) in time for 2.4b1? I'm afraid that absolutely zero consensus is emerging :( I've withdrawn myself entirely from the discussions as they've proven completely useless. Last time I saw behaviour like this was PEP 308. Hmm - PEP 308 - controversial syntax. PEP 318 - controversial syntax. PEP 328 - somewhat controversial syntax (I still don't overly like it). Anyone want to guess what PEP 338 will be like? ;) Tim Delaney

5 4

Considering decorator syntax on an individual feature basis
by Martin Zarate Aug. 19, 2004

Aug. 19, 2004

Issues with decorator syntax. I think we can all agree that the decorator argument is now wholly a matter of aesthetic taste, with the brief exception of namespace-based stuff that got argued when I suggested to use a block instead. The problem is that we keep jumping from the beginning of the argument to the end - we keep saying "what syntax do we want" rather than "which syntactic features do we want". The features in question, which should be decided individually rather than as a whole: - decorator before/within/after def. Guido is obviously a fan of the "before" approach, and I agree. The "after" to me is just ugly, and the "within" (on the same line, I mean) is impractical for some of the lengthier uses people describe for decorators, although I think that it is the most "pythonic" in general appearance. - special character/keyword/no new symbol. Guido prefers the @ character (I dislike it - it looks meaningless, and it breaks existing tools - I find it unpythonic). The "no new symbol" approach (such as the "list before def", or decorator-after-def-before-name) is often difficult to parse and, while elegant looking, can make it visually difficult to distinguish the decorators (and hard to grep). As such, I prefer the new keyword statement approach - it is more verbose, but I like it. - decorator on one/many line(s) The approach described by the paired-block syntax, and the @ syntax both assume that users want to include only one decorator per line. Personally, I am inclined to follow something like the new import statment wherein the user can have a comma-delimited list of decorators and can span the list across lines if they so choose. - one symbol per decorator vs. one symbol for all decorators The @ approach has one symbol for each decorator. The block approach has one symbol that encompasses all decorators. If a single symbol is used, then one must consider whether that symbol occurs on the same line as the decorators or not. If not, then the symbol must be brief to avoid letting its repetition be clumsy. Personally, I prefer a single use of the symbol, but its really personal taste. - indent def/not indent def If the decorator is before the def, this must be considered. Indenting the def is very Pythonic, as it shows the heirarchial relationship visually... but it also seems an unnecessary indendation in this case, as there is no other case where an indentation occurs for the benefit of a single statement. I think if each of these issues could be resolved and agreed to individually, then a consensis would be far more apparent as to the ideal solution, or at least some of the myriad solutions could be filtered out. I think the Python community has mostly settled on a "before def" approach, and I think that most agree that the @ character is very ugly, but some are coming around (mostly out of exhaustion though, it sounds). So if we can agree on the latter considerations. Personally, my favourite would be a single-line but continuable statement (like the "import" statement) which causes the assignment that occurs on the following line be wrapped by its mentioned objects. Use a nice keyword like deco or remake (or even just "be"). Possibly indent the def one level to show the relationship of the import statement and to allow for def assignments to look good when used with the statement. The fact is that there is no Pythonic precedence here - we're talking about a statement that holds one other statement and has N parameters. Whenever Python has had to break into new ground with statements, its been a bit of a mess (take lambda for example). Oh, and in defense of "be" as a statement - how's this? be staticmethod, returning(int), taking(int, bool, bool) def foo: pass or be ( staticmethod, synchronised): foo = lambda: none but that's just my tastes. Oh well, I'm violating my own rule, jumping ahead with a full syntax when we can't even find consensus on the parts of it.

3 2

refcounts.dat
by Thomas Heller Aug. 19, 2004

Aug. 19, 2004

Is the Doc/api/refcounts.dat file no longer maintained? The last commit was on 2002/10/04. How does the C api manual the refcount info? Thanks, Thomas

2 1

Weird errors when adding a new built-in type
by Geoffrey Biggs Aug. 19, 2004

Aug. 19, 2004

Evening all, This is my first time posting to the dev list so, as the email instructed, I'll introduce myself. My name is Geoffrey Biggs and I'm a PhD student at the University of Auckland in New Zealand working on some specialised programming language concepts. I'm implementing my ideas in Python to prove they work (or don't work, as the case may be). Apologies in advance for posting something to the python-dev list that isn't directly about improving the standard Python, but I figured this is the place where the people who know what I'm asking about and might know the answer would best be found and it doesn't seem to fit in python-help's description. I'm trying to add a new built-in number data type to Python with its own syntax, so I'm working directly with the interpreter rather than creating my own extension module (side note: I've appended something extra to the version thing in the Makefile - I doubt this is relevant to the problem but it's probably best you have all the info). The complex data type is similar to what I'm trying to do so I've been following that as an example. I've successfully extended the tokenizer and the parsenumber() function in compile.c to do what I want and written the data type in my two new files Objects/mynewobject.c and Include/mynewobject.h. I've included mynewobject.h in Python.h and added the two files to the Makefile. However, when I tried to run the code by typing in the syntax to produce my data type, Python suffers a segmentation fault. I traced this to an attempt to get the hash of a null pointer when adding the new instance of my type after parsenumber() was called. For completeness, here's the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08080e9a in PyObject_Hash (v=0x81486c0) at Objects/object.c:1162 1162 if (tp->tp_hash != NULL) (gdb) bt #0 0x08080e9a in PyObject_Hash (v=0x81486c0) at Objects/object.c:1162 #1 0x0808e199 in tuplehash (v=0x40324574) at Objects/tupleobject.c:244 #2 0x08080eae in PyObject_Hash (v=0x40324574) at Objects/object.c:1163 #3 0x0807b46c in PyDict_GetItem (op=0x40319c14, key=0x40324574) at Objects/dictobject.c:492 #4 0x080c72c7 in com_add (c=0xbfffed60, list=0x40326114, dict=0x40319c14, v=0x40326290) at Python/compile.c:975 #5 0x080c74ac in com_addconst (c=0xbfffed60, v=0x40326290) at Python/compile.c:1001 #6 0x080c90e3 in com_atom (c=0xbfffed60, n=0x4028d500) at Python/compile.c:1689 The crash appears to be caused because while v exists, v's members are all 0 and so tp becomes 0 and you get a NULL pointer exception. As far as I can tell, this v is the second object in the tuple created in com_add() and is supposed to be the type of the object being added to the dictionary in a tuple. Not knowing why it was coming out as zero, I did some more poking around (been doing a lot of that over the past 5 days...) and found that there is a file called bltinmodule.c with a bunch of lines, one of which mentions the complex data type that I am using as a guide: SETBUILTIN("complex", &PyComplex_Type); So I made one of these for mynewobject and added it. I figured from this bit of code that the reason I was getting NULL pointer exceptions was because my type hadn't been initialised in some way and that this would do it. But here's the problem: despite trying for longer than I've slept in the past week, I can't get it to compile. It always produces the following error (after the linker step that produces the python executable completes): case $MAKEFLAGS in \ *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Wall -Wstrict-prototypes -D__SAMMY_EXT__' ./python -E ./setup.py -q build;; \ *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Wall -Wstrict-prototypes -D__SAMMY_EXT__' ./python -E ./setup.py build;; \ esac make: *** [sharedmods] Error 139 Running the python executable doesn't work either, it starts and then segfaults immediatly with the backtrace indicating it dies trying to build the os module (which probably didn't get built). I haven't been able to figure out why this is happening. If I comment out the SETBUILTIN line I added it will compile fine but then I go back to the first problem. The only thing I found in google with this error was someone who was having trouble with a raw python source, and in that case it was a problem trying to build the ssl extension. I have structured my object identically to the complex object, which works. So the question (finally) is, what's broken? What have I missed? My best guess is only that I've broken the interpreter somehow by missing something with my object implementation and this is affecting that step of the make process. (This mess is all happening on Linux tillinshir 2.6.7-gentoo-r11-gb #1 Wed Aug 4 11:13:14 NZST 2004 i686 mobile AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux, if that matters.) Thanks in advance, Geoff Biggs

2 1

Byte string class hierarchy
by Jack Jansen Aug. 19, 2004

Aug. 19, 2004

I may have missed a crucial bit of the discussion, having been away, so if this is completely besides the point let me know. But my feeling is that the crucial bit is the type inheritance graph of all the byte and string types. And I wonder whether the following graph would help us solve most problems (aside from introducing one new one, that may be a showstopper): genericbytes mutablebytes bytes genericstring string unicode The basic type for all bytes, buffers and strings is genericbytes. This abstract base type is neither mutable nor immutable, and has the interface that all of the types would share. Mutablebytes adds slice assignment and such. Bytes, on the other hand, adds hashing. genericstring is the magic stuff that's there already that makes unicode and string interoperable for hashing and dict keys and such. Casting to a basetype is always free and doesn't copy anything, i.e. the bits stay the same. 'foo' in sourcecode is a string, and if you cast it to bytes you'll just get the bits, which is pretty much the same as what you get now. If you really want to make sure you get an 8-bit ascii representation even if you run in an interpreter built with UCS4 as the default character set you must use bytes('foo'.encode('ascii')). Casting to a subtype may cause a copy, but does not modify the bits. Casting sideways copies, and may modify the bits too, the current unicode encode/decode stuff. These 2 rules mean that unicode('foo') is something different from unicode(bytes('foo')), and probably illegal to boot, but I don't think that's too much of a problem: you shouldn't explicitly cast to bytes() unless you really want uninterpreted bits. Operations like concatenation return the most specialised class. Mutablebytes is the only problem case here, we should probably forbid concatenating these with the others. The alternatives (return mutablebytes, return the other one, return the type of the first operand) all seem somewhat random. Read() is guaranteed only to return genericbytes, but if you open a file in textmode they'll returns strings, and we should add the ability to open files for unicode and probably mutablebytes too. I'm not sure about socket.recv() and such, but something similar probably holds. Readline() really shouldn't be allowed on files open in binary mode, but that may be a bit too much. Write and friends accept genericbytes, and binary files will just dump the bits. Files open in text mode may convert unicode and string objects between representations. The bad news (aside from any glaring holes I may have overseen in the above: shoot away!) is that I don't know what to do for hash on bytes objects. On the one hand I would like hash('foo') == hash(bytes('foo')). But that leads to also wanting hash(u'foo') == hash(bytes(u'foo')), and we can't really have that because hash('foo') == hash(u'foo') is needed to make string/unicode interoperability for dictionaries work. Note that for the value 'foo' this isn't a problem, but for 'föö' (thats F O-UMLAUT O-UMLAUT) it is. So it seems that making hash('foo') != hash(bytes('foo')) is the only reasonable solution (and probably also a good idea with the future in mind: explicit is better than implicit so just put a cast there if you want the binary bits to be interpreted as an ASCII or Unicode string!) it will probably break existing code. -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

6 8

RE: [Python-Dev] PEP 318: Can't we all just get along?
by Robert Brewer Aug. 19, 2004

Aug. 19, 2004

Guido: > Is anybody seriously trying to come up with a single alternative > decorator proposal that most folks "out there" can support, to be > presented to me (with implementation, please!) in time for 2.4b1? Greg: > From the posts I've seen here, the only alternatives that have > considerable popular support are ones that you've already > rejected. So I suspect nobody really feels it's worth trying. Andrew (replying on c.l.p. for some odd reason): > To expand on that just a bit: the two alternatives that were most > generally favoured (in Doug Holton's estimate) were the > "list-after-def" (C1 in the wiki), and the "pie decorator at top of > function body" (E1 in the wiki), both of which Guido rejected. > In the poll that Doug ran, E1 had a slight margin over C1: > http://mail.python.org/pipermail/python-list/2004-August/233479.html > > However, C1 has an implementation, while E1 doesn't. (Aside: how > difficult would it be to create an implementation of E1?) Seems to me it's put up or shut up time, where "put up" means "implement". Of those proposals which have an implementation: A1: Currently in 2.4a. B: Guido prefers A1 over B. I haven't seen anyone advocating B, actually. C1: Guido rejected. J2: Guido rejected because of new keyword, but then "softened" his position. So if you can immediately reject J2, Guido, I'd say there are no candidates for an alternate. Otherwise, I'd be happy to drum up more support for J2 and get a complete proposal to you (something more than a pro/con list). Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

RE: [Python-Dev] PEP 318: Can't we all just get along?
by Delaney, Timothy C (Timothy) Aug. 19, 2004

Aug. 19, 2004

Guido van Rossum wrote: >> From the posts I've seen here, the only alternatives that have >> considerable popular support are ones that you've already >> rejected. So I suspect nobody really feels it's worth trying. > > Well, do people generally buy those rejections, or is their consensus > that I'm mistaken? I don't know about consensus, but there are a considerable number of people who think you're mistaken (it's gotten pretty heated over on c.l.py at times). Personally, I think you're mistaken about decorators being hidden in list-after-def, and problems with large, multi-line decorators - I think such problems would be few and far between. I also think that decorators are *not* the most important part of a function's signature - even classmethod - but should be *part* of a function's signature. Tim Delaney

1 0

PEP 318: Can't we all just get along?
by Kevin D.Smith Aug. 18, 2004

Aug. 18, 2004

For what it's worth, I wrote the original PEP 318. I probably wasn't qualified, but I just wanted a nice simple way to declare class methods without having to repeat the function name. After submitting it to BDFL for approval, more work was needed and the discussion of PEP 318 on python-dev increased rapidly. It was evident that I was in over my head, so I asked more someone more experienced to take over. I guess others had bigger plans for my proposal that I had planned. It has turned into the "solution" to many problems: type checking (both arguments and returned values), metaclasses, metadata, interfaces, function attributes, etc.). Unfortunately, in the process, this simple request for syntactical sugar has turned into a monstrosity. In my opinion, none of the proposed syntaxes really seem Pythonic. This PEP just seems to be trying to solve too many problems. Bear with me, but I'd like to propose one more syntax that is simple, easy for newbies to understand, and nowhere near as powerful as the current PEP's syntax. However, it doesn't add incoherent, arbitrary syntax either. def classmethod foo(x, y, z): pass That's it. One "decorator" that is a callable object that takes a method as it's only argument. No expressions, lists, tuples, etc. Just one callable object. Ok, if you absolutely must have more than one. def classmethod synchronized foo(x, y, z): pass Once again, no expressions. I know that this isn't going to solve everyone's type-checking, metadata, and function attribute problems, but let's face it, using this PEP for all of those things just creates ugly syntax. There must be more Pythonic ways to do those things in their own PEPs. Kevin Smith Kevin.Smith(a)sas.com

1 0