🌐 Mailman 3 August 2004 - Python-list - python.org

(no subject)
by michael.gregorius＠indunorm.de Aug. 6, 2004

Aug. 6, 2004

------------------ Virus Warning Message (on pbzc1n2.it.phoenix.wuerth.com) Found virus WORM_MYDOOM.M in file instruction.pif The uncleanable file instruction.pif is moved to /etc/iscan/virus/virVZK9X1. --------------------------------------------------------- The original message was included as attachment ------------------ Virus Warning Message (on pbzc1n2.it.phoenix.wuerth.com) instruction.pif is removed from here because it contains a virus. ---------------------------------------------------------

1 0

tweaking @decorator syntax
by sandskyfly＠hotmail.com Aug. 6, 2004

Aug. 6, 2004

If we are going to be stuck with @decorators for 2.4, then how about using blocks and indentation to elminate repetition and increase readability: Example 1 --------- class Klass: def __init__(self, name): self.name = name @staticmethod def statmethod1(x): return x def statmethod2(y): return y @classmethod def classmethod1(cls): return cls def classmethod2(cls): return cls @funcattrs(name='GvR', language='python') @log(file='func.log') def sayhello(self): print 'hello python world' def saygoodbye(self): print 'goodby python world' Example 2 --------- class Klass: def __init__(self, name): self.name = name @staticmethod: def statmethod1(x): return x def statmethod2(y): return y @classmethod: def classmethod1(cls): return cls def classmethod2(cls): return cls @funcattrs(name='GvR', language='python'), log(file='func.log'): def sayhello(self): print 'hello python world' def saygoodbye(self): print 'goodby python world' Perhaps, you can eliminate the '@' alltogether: Example 3 --------- class Klass: def __init__(self, name): self.name = name staticmethod: def statmethod1(x): return x def statmethod2(y): return y classmethod: def classmethod1(cls): return cls def classmethod2(cls): return cls funcattrs(name='GvR', language='python'), log(file='func.log'): def sayhello(self): print 'hello python world' def saygoodbye(self): print 'goodby python world' Sandy

5 6

RE: Poll - Vote here for "list-after-def" (was Decorator syntax)
by Delaney, Timothy C (Timothy) Aug. 6, 2004

Aug. 6, 2004

Anthony Baxter wrote: > The solution, if you don't like the syntax, is not voting. It's to > propose an argument that Guido will accept, in favour of your > preferred option. I see this less as a vote, and more an attempt to reach a community consensus - or at least a large enough one to lend weight to the many arguments that have already been presented. I will live with pie-syntax, but I won't be overly happy with it. I would much prefer that list-after-def be accepted. Tim Delaney

2 1

Re: Prothon is switching to the .NET platform
by Guido van Rossum Aug. 6, 2004

Aug. 6, 2004

Hi Mark, It was a pleasure to meet you at VanPy, and I was sorry that I had to leave in the middle of your talk (I had a plane to catch and David had scared me about delays). I was pleasantly surprised in hearing your architecture for the Prothon engine -- it sounded like a fresh look at implementing a runtime for a Python-like language, and several features (like the locking strategy) sounded like I should be paying attention to them for the Python 3000 interpreter. So now I'm a bit disappointed to hear that you're giving all that up and switching to the CLR. I understand your desire to have a large library available (though most of that library will be class-based, which may require you to bring classes back in through the back door). But in practical terms, it makes Prothon a lot less accessible in the years to come. I recall that installing .NET on Windows took me half a day. Maybe it's gotten better, but I sure can't believe they've shrunk it. Mono gives you theoretical support on Linux, but it's even more of a questionable proposition to actually run it (and its set of supported runtime libraries has only a small intersection with what's available in .NET). Basically, telling people "here's my language, it's a 2 MB download, and oh, BTW, you also need to install the 200 MB runtime over there" isn't exactly encouraging people to play with your language. Even for apps written in Java this is a significant barrier -- I have several copies of Java on my hard drive because every significant application written in Java ends up needing a different JVM version. And the JVM I downloaded last year is probably too old to run this year's crop of bleeding edge Java apps. Availability of the CLR is a lot less than Java. I'm also surprised because you admit to being a poor language designer (although you picked a great example :-). I assumed this to mean that you're having more fun implementing the runtime. But if you're not doing it for the language design, and now you're giving up on the runtime, what's left? Hoping your website was hacked or it was practical joke, --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Proposed improved decorator syntax
by barnesc＠engr.orst.edu Aug. 6, 2004

Aug. 6, 2004

I'm revising my vote. Thanks for the responses. I vote against: class foo: @synchronized @types("o,i,i") @author('Chris King') def introduceNewFeature(self, someArgument, anotherArgument): pass # whatever Pros: - Allows arbitrary functions to be applied as decorators. Cons: - Places decorator metadata before the function (in contrast with docstrings). - Hides function name. - @ symbols are ugly. - @ symbols are a particular hack for creating function metadata. - More such hacks may be needed in the future. - @ can be used to store metadata, but in a convoluted way: @name('Value') works, if function 'name' is defined (imports must be used for large projects); however the metadata name actually stored may be different than 'name' (ie no symmetry, no ease of use). - @ will be used for metadata, if no other solution is provided. Recognize that we're *really* trying to create function metadata. A more flexible solution is to make a metadata dictionary be part of function and class definitions. Then 'decorator' simply becomes one name among many different metadata names. I vote for: --------------------------------------------------------------------- Proposed Syntax --------------------------------------------------------------------- class foo: def introduceNewFeature(self, someArgument, anotherArgument): .decorate = [synchronized] .accepts = (int, int) .author = 'Chris King' pass # whatever Use introduceNewFeature.__meta__ to access the metadata dict. The .accepts meta-datum calls isinstance() for each argument. Use 'object' for arguments that can be any type. Pros: - Readable. - No ugly @ symbols. - Metadata is placed after the function name. - .decorate is semantically superior to @. - Similar to existing Python syntax (equals sign and dots). - Allows metadata to be created and read (symmetrically, easily). - Allows arbitrary functions to be applied as decorators. - Code is ordered correctly (function declaration before docstring and metadata). Cons: - Name conflicts between builtin metadata names (eg 'decorate') and user metadata names (eg 'decorate'). Solutions to Name Conflicts: - Name conflicts are a small problem if the set of Python special metadata names is kept small and well documented (eg '.decorate' and '.accepts' can be documented as 'metadata keywords', to be avoided). - The paranoid can prefix metadata names with underscores. - Alternatively, .__decorate__ and .__accepts__ can be used. - Alternatively, {'decorate': [synchronized], 'accepts': (int, int)} can be used as the first line of metadata, which is interpreted as a 'Python special metadata dict'. --------------------------------------------------------------------- Conclusion --------------------------------------------------------------------- Either attack the full problem of metadata, or don't. @ is a hack. @ looks ugly. @ is a particular solution for the general problem domain of metadata. @ is not clear to the uninitiated. @ is counter-intuitively present before the docstring. @name('Value') is can be used to store metadata, but lacks ease of use and symmetry. Finally, @ does not appear to follow the tradition of Python. It is a very specialized extension statement, and at least deserves a descriptive identifier in the code like 'decorate'. Please don't stay silent on this issue. Speak out! We should really have a public vote. I doubt the @ sign will be approved if 99% of Python users oppose it. - Connelly

3 3

Re: Confused about pep 318
by aahz＠pythoncraft.com Aug. 6, 2004

Aug. 6, 2004

In article <mailman.1241.1091758030.5135.python-list(a)python.org>, Anthony Baxter <anthonybaxter(a)gmail.com> wrote: >On Thu, 5 Aug 2004 13:36:23 -0500, Edward K. Ream <edreamleo(a)charter.net> wrote: >> >> To repeat: given that pep 318 is grossly misleading, I contend that >> no proper discussion of it has ever taken place. Sorry, but if you >> actively mislead the public, then the public _does_ have a right to >> complain. The web is a huge place. Expecting people to track it >> without proper notice of what is being discussed is patently unfair. > >"Actively mislead the public"? What the hell is that supposed to mean? >Look, you keep insinuating that there was some sort of evil plot to >slip this into Python. I can assure you that this is NOT true, and I'm >getting more than a little bit fed up with this argument. I'm not reading Edward as claiming the existence of an evil plot. OTOH, "actively mislead" is certainly an overstatement, *except* WRT the claim you're making that there was public discussion of the @ syntax going into Python. I think Edward's got a fair point there. Also, there has historically been an expectation that PEPs will be posted to comp.lang.python in their final draft form; while I agree with you that python-dev is a public forum, I think the outrage expressed by those who believed that they didn't *NEED* to monitor python-dev is entirely understandable. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy(a)lion.austin.ibm.com

2 1

Re: PEP-0318
by Skip Montanaro Aug. 6, 2004

Aug. 6, 2004

Anthony> ... here's what I managed [to edit in PEP 318] before a tidal Anthony> wave of crap flowed in... I checked in Anthony's changes to PEP 318 (sent in private email) with very few modifications. I simply didn't have enough time to do more this evening. I didn't even have the time to read back through the entire document. Anybody else who feels like taking a whack at it, feel free. I'll be out of Internet reach over the weekend, so it's unlikely I'll be able to do anything more with it until next week. Context diffs against v 1.15 would be best on the off-chance I get inputs from multiple people. A SourceForge patch would be the best place to stick such things so other people can see where your changes are. Note that I'm not really interested in thirty-leven new syntax proposals. What would be helpful are pointers to other documents and concise summaries of some of the discussions on c.l.py and python-dev. Incorporation of all or part of http://www.python.org/moin/PythonDecorators into the PEP would also be appreciated. Try to write objectively. A PEP isn't Usenet. <wink> Note how I'm being optimistic that multiple people will contribute. Lots of people have worn out their keyboards on this subject, so I know the energy is out there. It just needs to be focused a bit. Thx, Skip

1 0

BayPIGgies: August 12, 7:30pm
by Aahz Aug. 6, 2004

Aug. 6, 2004

The next meeting of BayPIGgies will be Thurs August 12 at 7:30pm. It will feature general discussion of programming and debugging GUI applications (Qt, Tkinter, wxPython, etc). BayPIGgies meetings are in Stanford, California. For more information and directions, see http://www.baypiggies.net/ Before the meeting, some people meet at 6pm for dinner in downtown Palo Alto. Ducky Sherwood is handling that; please send RSVPs to ducky(a)osafoundation.org Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: The September 9 meeting agenda has not been set. Please send e-mail to baypiggies(a)baypiggies.net if you want to make a presentation. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy(a)lion.austin.ibm.com

1 0

RE: Poll - Vote here for "list-after-def" (was Decorator syntax)
by Delaney, Timothy C (Timothy) Aug. 6, 2004

Aug. 6, 2004

You missed mine ;) +1 Tim Delaney

1 0

Confused about pep 318
by Edward K. Ream Aug. 6, 2004

Aug. 6, 2004

Hello all, First of all, my present state of mind re pep 318 is one of sheepish confusion. I suspect pep 318 will not affect Leo significantly, but I am most surprised that an apparently controversial feature is being added without a notice, say, in comp.lang.python.announce. I say sheepish, because everyone knows that one should make sure new proposals don't bite you. Still, I would have thought that there were other ways of keeping abreast of potentially major changes to Python besides reading py-dev... The following are some comments to recent posts on py-dev. I hope to convey by these remarks my sense of bewilderment. > There is little point in going over all the same arguments again and again. For this alpha release, no amount of arguing will change what has been committed. You really have to organize a public outcry if you want the syntax changed before 2.4. [Martin v. Löwis] I'd like to defer the question of a "public outcry" until later, hopefully much later. But I have no idea what the proposed syntax is(!!) In particular, there is no mention of '@' directly on the page http://www.python.org/peps/pep-0318.html Is there a summary of recent work? An announcement? Some indication of consensus? > > In general, I predict most Python code will continue to be blissfully unadorned with decorators. > Right. Outside the test suite, there are very few uses of classmethod, staticmethod and property in the standard library. GvR Hmm... I see nowhere in pep 318 any mention that the pep will affect the following section of the Reference manual: http://docs.python.org/ref/delimiters.html [quote] The following printing ASCII characters are not used in Python. Their occurrence outside string literals and comments is an unconditional error: @ $ ? [end quote] I would regard any change to this paragraph as a major change to Python, in spite of its innocent appearance. Indeed, this paragraph is an excellent "line in the sand" for other tools. To repeat, I suspect adding @ would not affect Leo significantly in any direct way, and a workaround would probably exist even if it did. However, this proposal probably would affect the noweb markup language on which Leo is (loosely) based. See http://www.eecs.harvard.edu/~nr/noweb/ BTW, a long while back I suggested that there was no reason for the parser to need colons after "if" statements, etc. The response was: true, but allowing colons to be elided would impact existing tools. So I gave up. Am I the first to suggest that allowing '@' characters in valid Python programs outside string literals and comments might negatively impact existing tools? > Sigh. This discussion is going around in pointless circles; we're *months* past that point. You're wasting your time (and mine). [GvR] I confess that I don't understand this remark at all. How has it happened that so many people are confused about this proposal? And if everything is so clear, why isn't the clarity reflected in pep 318 itself? http://www.python.org/peps/pep-0318.html talks about - Background - Design goals - Proposed syntax (no mention of @!) - Alternative proposals etc. Excuse me, but if everything is now set in stone, then this is an extraordinarily misleading document. > Sorry. I think you'd be wise to consider the months without consensus as evidence of a problem. [Jim Fulton] This is my present opinion as well. Summary I wish to disavow any knowledge, or any interest in, the wider issues of whether pep 318 is a good idea or not. My concern is exclusively with the following two issues: 1. IMO, allowing '@' in valid Python programs (outside string literals or comments) is a major change to the language that has significant potential to disrupt already existing tools. At the very least, some discussion of http://docs.python.org/ref/delimiters.html should be in pep 318. 2. pep 318 apparently does not reflect the present state of affairs, and afaik there has been no announcement of proposed changes on comp.lang.python.announce. This is disturbing. If anyone could clarify the present status of pep 318 I would be most grateful. I would prefer not to be told to read all the py-dev archives. If everything is now clear, where can I find out about it? Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

3 3