[Python-Dev] Download URL typo
Hiho, in case noone didn't notice yet: the "Windows MSI Installer" link at http://www.python.org/download/releases/2.5/ points to Python 2.4! Regards, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP: __source__ proposal
Hi! I think you were the omitting the more interesting closure examples (namely with free variables inside the closure's source): def foo(): pass def bar(x): def fiep(): return x() return fiep what's bar(foo).__source__? Generally, I'm opposed to the feature -- I don't think it provides a real advantage giving it's limitations (doesn't work for import'ed modules, classes + methods != module, etc.). Cheers, Michael On Fri, 3 Dec 2004 11:54:25 +0200 (EET), Stelios Xanthakis <[EMAIL PROTECTED]> wrote: > > Hi all. > > Now that 2.4 is out and everything maybe it's > about time to start discussing the "use the > __source__ Luke" feature which IMO will really > boost python into a new domain of exciting > possibilities. > > I've prepared a pre-PEP which is not very good > but it is a base. > > In short, the feature is good and it enables > editing of python code at runtime instead of > the runfile-exit-edit-run-exit-edit-run cycle. > > We have the following possibilities as to whether > __source__ data is marshalled and the feature is > always enabled. > > [1] Command line switch and not marshalled > [2] Always on and not marshalled > [3] Always on and marshalled > > There is also [4] which doesn't make much sense. > > If I was BDFL I'd go for [1] so whoever wants it > can enable it and whoever doesn't can't complain, > and they'll all leave me alone. > Phillip J. Eby expressed some concerns that the > modules that depend on __source__ will eventually > take over and it will become a standard. > > Anyway, the PEP is attached. > You can mail me with votes on the feature and if you > want on your preferred option from 1,2,3. > If I get votes I'll post the results later. > > If this is accepted I'll try to come up with a good > patch vs 2.4 > > Thanks, > > St. > > ---ATTACHED PYTHON ENHANCEMENT PROPOSAL--- > PEP: XXX > Title: The __source__ attribute > Version: $Revision: 1.10 $ > Last-Modified: $Date: 2003/09/22 04:51:49 $ > Author: Stelios Xanthakis > Status: Draft > Type: Standards Track > Content-Type: text/plain > Created: 19-Nov-2004 > Python-Version: 2.4.1 > Post-History: > > Abstract > > This PEP suggests the implementation of __source__ attribute for > functions and classes. The attribute is a read-only string which > is generated by the parser and is a copy of the original source > code of the function/class (including comments, indentation and > whitespace). > > Motivation > > It is generally a tempting idea to use python as an interface to > a program. The developers can implement all the functionality > and instead of designing a user interface, provide a python > interpreter to their users. Take for example one of the existing > web browsers: they have everything that would be needed to write > a script which downloads pages automatically or premutates the > letters of web pages before they are displayed, but it is not > possible for the user to do these things because the interface > of these applications is static. > > A much more powerful approach would be an interface which is > dynamically constructed by the user to meet the user's needs. > The most common development cycle of python programs is: > write .py file - execute .py file - exit - enhance .py file - > execute .py file - etc. With the implementation of the __source__ > attribute though the development/modification of python code > can happen at run-time. Functions and classes can be defined, > modified or enhanced while the python shell is running and > all the changes can be saved by saving the __source__ attribute > of globals before termination. Moreover, in such a system > it is possible to modify the "code modification routines" and > eventually we have a self-modifying interface. Using a > program also means improving its usability. > > The current solution of using 'inspect' to get the source > code of functions is not adequate because it doesn't work > for code defined with "exec" and it doesn't have the source > of functions/classes defined in the interactive mode. Generally, > a "file" is something too abstract. What is more real is the > data received by the python parser and that is what is stored > in __source__. > > Specification > > The __source__ attribute is a read-only attribute of functions > and classes. Its type is string or None. In the case of None > it means that the source was not available. > > The indentation of the code block is the original identation > obeying nested definitions. For example: > > >>> class A: > ... def foo (self): > ... print """Santa-Clauss > ... is coming to town""" > >>> def spam (): > ... def closure (): > ... pass > ... return closure > >>> print A.
Re: [Python-Dev] 2.4 news reaches interesting places
If I parse you correctly, this would be great. - Michael On Thu, 09 Dec 2004 16:37:59 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote: > > > >On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote: > > > > > The only thing that will fix the PR issue is to have a Python compiler > > > distributed as part of the language. It doesn't matter if it doesn't > > > support the full generality of Python, or even if it doesn't speed many > > > operations up much. The only real requirements are that it can be used to > > > produce "native" executables, and that it be an official part of the > > > language, not a separately-distributed tool like Psyco or Pyrex. Then, it > > > will perhaps be a sufficient "security blanket" to stop people FUDding > > > about it. > > > >I am aware that Pyrex is still in flux, so perhaps it is too soon to > >propose this even for 2.5, but I think it's worth bringing up anyway: I > >would like Pyrex to be distributed with the Python core. I agree that > >it should be modified to produce full .exe files and not just .dlls on > >Windows, but many potential users *are* seriously concerned about > >efficiency and not just simplifying distribution. > > +1 on all the stuff you said, with one minor exception. Pyrex-the-language > is often unpythonically ugly and verbose at present. If Python had an > official syntax for optional static type declaration, Pyrex's syntax could > be aligned with that, and that would at least eliminate most of the inline > 'cdef' ugliness, leaving only C type declarations and Python property > declarations as the main syntax issues to be resolved. (Maybe by using > something like the 'ctypes' API, and having the compiler recognize that > API, such that C is directly callable from Python anyway, so compiling or > interpreting Python makes no difference to ability to access C... but I > digress.) > > Of course, this would take some effort from the core developers, especially > Guido, to consider the various syntax needs and formulate official > solutions. But if it were done, the Python-vs.-Pyrex distinction could > fade away altogether, replaced with the meme, "just add type declarations > to slow parts, and tell Python you want the module compiled to C." > > IOW, if Pyrex is merely the name of a compiler, not a separate language, > then our master plan for world domination is complete. :) > > > > ___ > Python-Dev mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] re: 2.4 news reaches interesting places
On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter <[EMAIL PROTECTED]> wrote: > [...] Possible slogan for Python: "Fast enough, and better in many ways". > [...] Let's make it faster first :-) Cheers, Michael ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Son of PEP 246, redux
> instead interfaces can be defined in terms of individual operations, and > those operations can be initially defined by an abstract base, concrete > class, or an "interface" object. I think this is quite problematic in the sense that it will force many dummy interfaces to be created. At least without type inference, this is a no-no. Consider: In order to type a function like: def f(x): # ... x.foo() # ... ...so that type violations can be detected before the real action takes place, you would need to create a dummy interface as in: interface XAsFUsesIt: def foo(): pass def f(x : XAsFUsesIt): # ... ...or you would want type inference (which at compile time types x as "a thing which has a 'nullary' foo() function) and a type system like System CT. Former appears cumbersome (as it should really be done for every function), latter too NIMPY-ish . What am I missing? Sleepingly yours, Michael On Wed, 12 Jan 2005 23:48:47 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote: > >Regardless, > >getting back to the main goal I had when writing PEP 246 -- your > >alternative proposal still doesn't seem to provide a mechanism for > >component developers to have a dialogue with one another to connect > >components without involving the application programmer. > > Eh? You still have adapt(); you still have adapters. The only difference > is that I've specified a way to not need "interfaces" - instead interfaces > can be defined in terms of individual operations, and those operations can > be initially defined by an abstract base, concrete class, or an "interface" > object. Oh, and you don't have to write adapter *classes* - you write > adapting *methods* for individual operations. This can be done by the > original author of a class or by a third party -- just like with PEP 246. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Son of PEP 246, redux
On Thu, 13 Jan 2005 01:04:01 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:01 AM 1/13/05 -0500, Michael Walter wrote: > >What am I missing? > > The fact that this is a type-declaration issue, and has nothing to do with > *how* types are checked. I was talking about how you declare such types, sir :] (see the interface pseudo code sample -- maybe my reference to type inference lead you to think the opposite.) > In other words, compared to the previous state of things, this should > actually require *fewer* interfaces to accomplish the same use cases, and > it doesn't require Python to have a built-in notion of "interface", because > the primitive notion is an operation, not an interface. Yepyep, but *how* you declare types now? Can you quickly type the function def f(x): x.read()? without needing an interface interface x_of_f: def read(): pass or a decorator like @foo(x.read)? I've no idea what you mean, really :o) Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Son of PEP 246, redux
Ahhh, there we go, so "file" is type you declare. All I was asking for, I thought you were thinking in a different/"more sophisticated" direction (because what "f" actually wants is not a file, but a "thing which has a read() like file" -- I thought one would like to manifest that in the type instead of implicitely by the code). Your concept is cool, tho :-) Michael On Thu, 13 Jan 2005 08:52:21 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:18 PM 1/13/05 +1000, Nick Coghlan wrote: > >Michael Walter wrote: > >>Yepyep, but *how* you declare types now? Can you quickly type the function > >>def f(x): x.read()? without needing an interface interface x_of_f: def > >>read(): pass or a decorator like @foo(x.read)? I've no idea what you > >>mean, really :o) > > > >Why would something like > > > > def f(x): > > x.read() > > > >do any type checking at all? > > It wouldn't. The idea is to make this: > > def f(x:file): > x.read() > > automatically find a method declared '@implements(file.read,X)' where X is > in x.__class__.__mro__ (or the equivalent of MRO if x.__class__ is classic). > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
But... only as an additional option, not as a replacement, right? Michael On Sat, 19 Feb 2005 03:01:14 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > This is something I've typed way too many times: > > > > > > Py> class C(): > > > File "", line 1 > > > class C(): > > > ^ > > > SyntaxError: invalid syntax > > > > > > It's the asymmetry with functions that gets to me - defining a > > > function with no arguments still requires parentheses in the > > > definition statement, but defining a class with no bases requires the > > > parentheses to be omitted. > > > > Seconded. It's always irked me enough that it's the only ``apology'' > > for Python syntax you'll see in the Nutshell -- top of p. 71, "The > > syntax of the class statement has a small, tricky difference from that > > of the def statement" etc. > > +1 For me, this would come-up when experimenting with mixins. Adding and > removing a mixin usually entailed a corresponding > change to the parentheses. > > > Raymond > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
That is like Lisp's +, must be good :P Michael On Sun, 13 Mar 2005 08:38:42 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > There are a few design choices we could have made for sum(); in > particular, for non-empty sequences we could not have used the > identity element (the optional second argument). As it is, we get > unjustified but understandable complaints that sum() "only supports > numbers". An alternative design could have returned: > > - the identity (defaulting to 0) if the sequence is empty > - the first and only element if the sequence only has one element > - (...(((A + B) + C) + D) + ...) if the sequence has more than one element > > This has surprises too (in particular of returning 0 when invoked > without overriding the identity argument for a seqence of addable > non-numbers) but works without using the second argument for a larger > set of inputs I believe it is often used in such a way that the input > is known to be non-empty). > > I'd be happy to be pointed to a past discussion where this was > considered and rejected with a good reason; then I can post that to > the blog (where the deficiency in sum() is being berated a bit > excessively). > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Tue, 15 Mar 2005 07:47:20 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > But I'm not so sure now. Thinking ahead to generic types, I'd like the > full signature to be: > > def sum(seq: sequence[T], initial: T = 0) -> T. Would this _syntax_ work with generic types: def sum(seq: sequence[T], initial: T = T()) -> T. Cheers, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Wed, 16 Mar 2005 08:28:22 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > Thinking ahead to generic types, I'd like the full signature to be: > > > > > > def sum(seq: sequence[T], initial: T = 0) -> T. > > > > Would this _syntax_ work with generic types: > > > > def sum(seq: sequence[T], initial: T = T()) -> T. > > Maybe, but it would preclude union types; continuing with the (bad) > example of strings, what should one choose for T when seq == ['a', > u'b']? The general case is a sequence of objects of different types > that are mutually addable. This can be made to work with the > (hypothetical) type system by using unions, but you can't > instantiate an instance of a union without being more specific. Continuing that hypothetical thought, it would be perfectly acceptable to make require an argument for union types T. Maybe T() should only be valid for non-union types. Several questions like "when should T() be evaluated" [1], "how can we avoid ': T = T()' leading to a type error" and "how about optional parameters in front of ': T = T()'" just popped up in my mind. Michael [1] Thanks, John! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rationale for sum()'s design?
On Thu, 17 Mar 2005 14:34:23 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote: > Not to mention that if the seq is empty, there's no > way of knowing what T to instantiate... You just use the same T as inferred for seq : sequence[T] . Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On 4/19/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > RSMotD (random stupid musing of the day): so I wonder if the decorator > > syntax couldn't be extended for this kind of thing. > > > > @acquire(myLock): > > code > > code > > code > > Would it be useful for anything other than mutex-locking? And wouldn't > it be better to make a function of the block wrapped in a > block-decorator and then use a normal decorator? Yes. Check how blocks in Smalltalk and Ruby are used for starters. Regards, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: switch statement
On 4/21/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Michael Chermside wrote: > > Now the pattern matching is more interesting, but again, I'd need to > > see a proposed syntax for Python before I could begin to consider it. > > If I understand it properly, pattern matching in Haskell relies > > primarily on Haskell's excellent typing system, which is absent in > > Python. > > There's no real need for special syntax in Python - an appropriate tuple > subclass will do the trick quite nicely: You are missing the more interesting part of pattern matching, namely that it is used for deconstructing values/binding subvalues. Ex.: case lalala of Foo f -> f Bar (Baz brz) _ meep -> (brz, meep) or Python-ish: match doThis() with: Foo as f: return f (_,* as bar,_): return bar Baz(boink as brzzz, meep=10): return brzzz "* as bar" is Not Very Nice (tm) :/ Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defmacro (was: Anonymous blocks)
A couple of examples out of my tired head (solely from a user perspective) :-)
Embedding domain specific language (ex.: state machine):
stateful Person:
state Calm(initial=True):
def react(event):
self.chill_pill.take()
ignore(event)
state Furious:
def react(event):
self.say("Macros are the evil :)")
react(event) # xD
p = Person()
p.become(Furious)
p.react(42)
---
Embedding domain specific language (ex.: markup language):
# no, i haven't thought about whether the presented syntax as such is
unambiguous
# enough to make sense
def hello_world():
:
:
: "Tralalalala"
:
for g in uiods:
: uido2str(g)
---
Embedding domain-specific language (ex.: badly-designed database table):
deftable Player:
id: primary_key(integer) # does this feel backward?
handle: string
fans: m2n_assoc(Fan)
---
Control constructs:
forever:
print "tralalala"
unless you.are(LUCKY):
print "a"
I'm not sure whether this the Python you want it to become, so in a
certain sense I feel kind of counterproductive now (sublanguage design
is hard at 11 PM, which might actually prove someone's point that the
language designer shouldn't allow people to do such things. I'm sure
other people are more mature or at least less tired than me, though,
so I beg to differ :-),
Michael
On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It seems that what you call macros is really an unlimited
> preprocessor. I'm even less interested in that topic than in macros,
> and I haven't seen anything here to change my mind.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defmacro (was: Anonymous blocks)
On 4/26/05, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote: > IMVHO, macros are readability assassins. The power (for any developer) > to introduce new syntax is *not* a desirable feature, but something > to be avoided. And that alone should be a stronger argument than > a hundred use cases. Personally, I believe that EDSLs can improve usability of a library. I've been following this list for quite a while, and trying to see what lengths (hacks) people go (use) to implement "sexy" syntax can give you quite an idea that custom syntax matters. And surely all of these tricks (hacks) are way harder to use than a EDSL would be. Regards, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: switch statement
On 4/28/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > > "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: > > Guido> You mean like this? > > if x > 0: > ...normal case... > elif y > 0: > abnormal case... > else: > ...edge case... > > The salient example! If it's no accident that those conditions are > mutually exclusive and exhaustive, doesn't that code require at least > a comment saying so, and maybe even an assertion to that effect? I usually do: if ...: return ... if ...: return ... assert ... return ... Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Tutor] nice()
It doesn't seem to me that math.nice has an obvious meaning. Regards, Michael On 2/14/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote: > > >> However I do dislike the name nice() - there is already a nice() in the > > >> os module with a fairly well understood function. But I'm sure some > > > > > Presumably it would be located somewhere like the math module. > > > > For sure, but let's avoid as many name clashes as we can. > > Python is very good at managing namespaces but there are still a > > lot of folks who favour the > > > > from x import * > > > > mode of working. > > Yes, and there are people who insist on drinking and driving, that > doesn't mean cars should be designed with that as a motivating > assumption. There are just too many places where you are going to get > name clashes, where something which is _obvious_ in one context will > have a different ( and _obvious_ ) meaning in another. Lets just keep > the namespaces clean, and not worry about inter-module conflicts. > > -- > Crutcher Dunnavant <[EMAIL PROTECTED]> > littlelanguages.com > monket.samedi-studios.com > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (-1)**(1/2)==1?
>>> 1/2 0 >>> (-1) ** (1./2) Traceback (most recent call last): File "", line 1, in ? ValueError: negative number cannot be raised to a fractional power Regards, Michael On 2/20/06, Jonathan Barbero <[EMAIL PROTECTED]> wrote: > Hello! > My name is Jonathan, i´m new with Python. > >I try this in the command line: > >>>> (-1)**(1/2) > 1 > >This is wrong, i think it must throw an exception. > What do you think? > > Bye. > Jonathan. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Maybe "switch" became a keyword with the patch.. Regards, Michael On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Thomas Lee wrote: > > Hi all, > > > > As the subject of this e-mail says, the attached patch adds a "switch" > > statement to the Python language. > > > > However, I've been reading through PEP 275 and it seems that the PEP > > calls for a new opcode - SWITCH - to be added to support the new > > construct. > > > > I got a bit lost as to why the SWITCH opcode is necessary for the > > implementation of the PEP. The reasoning seems to be > > improving performance, but I'm not sure how a new opcode could improve > > performance. > > > > Anybody care to take the time to explain this to me, perhaps within the > > context of my patch? > > Could you upload your patch to SourceForge ? Then I could add > it to the PEP. > > Thomas wrote a patch which implemented the switch statement > using an opcode. The reason was probably that switch works > a lot like e.g. the for-loop which also opens a new block. > > Could you explain how your patch works ? > > BTW, I think this part doesn't belong into the patch: > > > Index: Lib/distutils/extension.py > > === > > --- Lib/distutils/extension.py(revision 46818) > > +++ Lib/distutils/extension.py(working copy) > > @@ -185,31 +185,31 @@ > > continue > > > > suffix = os.path.splitext(word)[1] > > -switch = word[0:2] ; value = word[2:] > > +switch_word = word[0:2] ; value = word[2:] > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jun 12 2006) > >>> Python/Zope Consulting and Support ...http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > 2006-07-03: EuroPython 2006, CERN, Switzerland 20 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
How about simply "with block" or "guarded scope" or something like that? Michael On 7/3/05, Ron Adam <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > > On the other hand 'enter and exit' rolls off the tongue > > significantly better than 'enter and leave' > > My only concern is enter and exit may be too general. They are > frequently used in other places, although __enter__ and __exit__ are > less common, so maybe it's a non issue. > > The terms __begin__ and __end__, are nearly as general, but they stress > better that there are three parts, a beginning, middle and ending. > > > > All of which just leads me to the conclusion that English is a screwy > > language, and I already knew that ;) > > I nowe that tue, but fixxing it issint backward compattibbal. ;-) > > > > Anyway, I stuck with 'exit' for this - I prefer slightly awkard > > phrasing in the explanation to awkwardness in the pairing of the names. > > > After reading Michael Hudsun's post: > > >>I used a with statement to establish and dis-establish an error > >>handler -- would you call that a resource? > > He has a good point, maybe we are confusing what a with-block does, with > how it can be used. > > So something along the lines of ... > > """ > With-Mangager Blocks > > A With-Manager Block is used to combine related initiation and > finalization routines from a Manager object with a local block of code. > Python will attempt to execute the finalization routine even if an error > occurs which makes With-Manager Blocks useful for writing algorithms > which require dependable closure or release of an acquired resource > after the code block is executed. > > etc... """ > > > That's a nice start on the docs Nick. > > Cheers, > Ron > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
Hmm: "Guarding a scope with a decimal.Context() object ." What do you think? (I'm not sure myself, but we even got a "with" in there :-) Michael On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Michael Walter] > > How about simply "with block" or "guarded scope" or something like > that? > > How would you use that to describe decimal.Context() objects after Nick > adds the __enter__ and __exit__ magic methods? We want something as > direct as, "xrange objects are iterable". > > > Raymond > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
Hmm, I think I'm seeing mostly the (guarded) entry/exit part of "guard" metaphor, but I see what you mean (not allowing "entry", so to say, right?). Not sure. Michael On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > "Guarding a scope with a decimal.Context() object ." > > Doesn't "guard" suggestion conditional execution? > > > Raymond > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
Oh, I remember. Agreed, it is most probably a bad choice then. One part of my brain likes: "By wrapping a block in/with[*] a decimal.Context, " "xml.Tags used to wrap a block will print '' before the block is entered, and '' after execution has left." What do you think? [*] I'm not sure what's the correct English version, sorry.. if it is "with", it migh be a nice way to place a hyperlink to the language reference. On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I'm referring to the specific meaning of "guard" in a computer science > context: > > http://www.computer-dictionary-online.org/guard.htm?q=guard > > From David Gries, The Science of Programming, if statement contains two > entities of the form B --> S wehere B is a Boolean expression and S a > command. B --> S is called a guarded command. > > I believe that terminology is rooted in Dijkstra's language of guarded > commands (used to express and facilitate program proofs). They are > essentially the same as conditionally executed statements but may be > executed non-deterministically: > > http://cs-exhibitions.uni-klu.ac.at/contentGuardedCommand.php > > Also, I believe the pattern matching part of Prolog clauses are called > guards; however, the conditional execution is deterministic (the first > match is the one that fires) and potentially recursive. > > This terminology is used consistently among various functional > programming languages. From, > http://www.cs.ecu.edu/~karl/astarte/glossary.html , "A guard in a case > is the condition that is being tested. For example, in case a => b, > expression a is the guard." > > In predicate calculus, the phrase, "strengthening the guard" has a > specific meaning with the "guard" part being consistent with the above. > One example: > >http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf > > IOW, guard is a specific term, not an amorphous metaphor that can be > accurately applied to the enter/exit or enter/leave pair. > > > Raymond > > > > > > > -Original Message- > > From: Michael Walter [mailto:[EMAIL PROTECTED] > > Sent: Sunday, July 03, 2005 10:28 PM > > To: Raymond Hettinger > > Cc: [EMAIL PROTECTED]; python-dev@python.org > > Subject: Re: [Python-Dev] Terminology for PEP 343 > > > > Hmm, I think I'm seeing mostly the (guarded) entry/exit part of > > "guard" metaphor, but I see what you mean (not allowing "entry", so to > > say, right?). Not sure. > > > > Michael > > > > On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > > "Guarding a scope with a decimal.Context() object effect>." > > > > > > Doesn't "guard" suggestion conditional execution? > > > > > > > > > Raymond > > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency
FWIW, the Perl 6 community is also investigating STM, so it appears to be a worthwhile idea for an impure, multi-paradigm language as well. Regards, Michael On 9/29/05, Bruce Eckel <[EMAIL PROTECTED]> wrote: > This paper looks very interesting and promises some good ideas. It > also looks like it will require time and effort to digest. > > I've only read the first few pages, but one thing that does leap out > is at the beginning of section 3, they say: > > "... a purely-declarative language is a perfect setting for > transactional memory." > > What's not clear to me from this is whether STM will work in a > non-declarative language like Python. > > Thursday, September 29, 2005, 8:12:23 AM, Michael Hudson wrote: > > > Bruce Eckel <[EMAIL PROTECTED]> writes: > > >> I'd like to restart this discussion; I didn't mean to put forth active > >> objects as "the" solution, only that it seems to be one of the better, > >> more OO solutions that I've seen so far. > >> > >> What I'd really like to figure out is the "pythonic" solution for > >> concurrency. Guido and I got as far as agreeing that it wasn't > >> threads. > >> > >> Here are my own criteria for what such a solution would look like: > > > Just because I've been mentioning it everywhere else since I read it, > > have you seen this paper: > > > http://research.microsoft.com/Users/simonpj/papers/stm/ > > > ? I don't know how applicable it would be to Python but it's well > > worth the time it takes to read. > > > Cheers, > > mwh > > > > Bruce Eckelhttp://www.BruceEckel.com mailto:[EMAIL PROTECTED] > Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e" > Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel > Subscribe to my newsletter: > http://www.mindview.net/Newsletter > My schedule can be found at: > http://www.mindview.net/Calendar > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory management in the AST parser & compiler
The behavior of libiberty's alloca() replacement might be interesting as well: http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-alloca-59 Regards, Michael On 11/18/05, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote: > > > Portability may also be an issue to take into consideration: > > Of course -- but so is anno domini... the eskimo.com FAQ is (C) 1995, > and the neohapsis.com page just points to the eskimo.com one: > > > http://www.eskimo.com/~scs/C-faq/q7.32.html > > http://archives.neohapsis.com/archives/postfix/2001-05/1305.html > > In 2006, I'm not sure the need to avoid alloca is anywhere as > strong. Sure, it could be wrapped into a LOCALLOC macro (with a > companion LOCFREE one), the macro expanding to alloca/nothing on > systems which do have alloca and to malloc/free elsewhere -- this > would keep the sources just as cluttered, but still speed things up > where feasible. E.g., on my iBook, a silly benchmark just freeing > and allocating 80,000 hunks of 1000 bytes takes 13ms with alloca, 57 > without... > > > Alex > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
