Re: [Python-Dev] Open CPython VM for type information
Brett Cannon schrieb: > > > On 12/12/06, *Kay Schluehr* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Dear Python developers, > > while the JVM is opened to support dynamically typed languages [1] I > wonder if the CPyVM could not show more openness to statically typed > languages? Hereby I don't think that much about arbitrary > languages for > the CPyVM but sublanguages like RPython which are "static enough" > to be > compilable into extension modules [2]. > > However creating C extension modules from Python code is not > really the > standard way I do think Python source should be handled. Instead I > think > about a more direct VM support like the JVM does, that provides > opcodes > like iload, fstore etc. Besides this I don't expect one canonical > approach for these type information to be feeded into the CPyVM. There > are type inferencer like rtyper for PyPy, Psycos continous bytecode > monitoring and also other approaches are possible that use type > feedback. Finally optional type declarations are also an issue; > however > I would like to see language design discussions being separated ( -> > Python 3000 ) and focus on general APIs for compiler extensions / > plugs > that deal with type information ( the architecture ) and VM > implementation issues. > > Thanks, Kay > > [1] http://jcp.org/en/jsr/detail?id=292 > [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html > > > The Python VM is not designed to be general-purpose, period. Nor does > anyone on python-dev, to my knowledge, have any interest in putting > the time and energy into making it general. I am quite happy with > letting the Parrot folk handle this goal. This means that the > maintenance cost of adding more opcodes is not worth it. > > But a bigger issue with me is the performance hit. Every opcode will > make the eval loop larger. And it is known that the eval loop is > rather finicky in terms of size and performance. While no hard > testing has been done, it has been assumed we have accidentally hit > the sweet spot in terms of CPU cache size. > > An important thing to keep in mind when comparing Python's VM to > Java's is that Java works (somewhat) for dynamic languages because > people are motivated enough to shoehorn languages into it by just > assuming everything is just an object and tossing out the type > checking inherent to Java. But Java has not, to my knowledge, grown > any great features yet to make dynamic languages work better. I know > about JSR 292, but that is not in yet and adding just one opcode is > not that expensive to the JVM. But compare the cost of adding a slew > of typed opcodes to Python compared to the JVM adding just one is not > really equal. > > In other words, I wouldn't count on this ever happening. =) The best > you could do is try to propose some direct mechanism for adding > support to the eval loop to dispatch to some function for unrecognized > opcodes, but I wouldn't count on that being accepted either. > > -Brett Brett, thanks for the short answer. Although it is negative regarding my attempt, it is also important to know which ideas are outlawed and where one steps into a no-go area concerning the evolving language standard and its main implementation. Regards ___ 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] Open CPython VM for type information
Dear Python developers, while the JVM is opened to support dynamically typed languages [1] I wonder if the CPyVM could not show more openness to statically typed languages? Hereby I don't think that much about arbitrary languages for the CPyVM but sublanguages like RPython which are "static enough" to be compilable into extension modules [2]. However creating C extension modules from Python code is not really the standard way I do think Python source should be handled. Instead I think about a more direct VM support like the JVM does, that provides opcodes like iload, fstore etc. Besides this I don't expect one canonical approach for these type information to be feeded into the CPyVM. There are type inferencer like rtyper for PyPy, Psycos continous bytecode monitoring and also other approaches are possible that use type feedback. Finally optional type declarations are also an issue; however I would like to see language design discussions being separated ( -> Python 3000 ) and focus on general APIs for compiler extensions / plugs that deal with type information ( the architecture ) and VM implementation issues. Thanks, Kay [1] http://jcp.org/en/jsr/detail?id=292 [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html ___ 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] Draft proposal: Implicit self in Python 3.0
Guido van Rossum wrote: > On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote: > >>Then simply reject the PEP and the discussion can be stopped on >>comp.lang.python too. > > > Only in the most severe cases does it make sense to create a PEP > specifically to be rejected. >>Or why do you think it should be discussed there >>again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on >>Artima )? > > > Perhaps because people don't understand it? They don't accept it even more than they don't understand it. This leads to repeated guesses that the object model might perhaps change in Py3K with respect to explicit self [1]. It's not all just an educational issue. If this is not a severe case where an autoritarian decision should be made and also be made visible at a central and recoverable place I don't know what? Regards Kay [1] See e.g. Bruce Eckels postings on this page: http://www.artima.com/forums/flat.jsp?forum=106&thread=141312&start=75&msRange=15 ___ 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] Draft proposal: Implicit self in Python 3.0
Guido van Rossum wrote: >>Yuk! This has been discussed again and again already. *Please* move >>this discussion to comp.lang.python. > > > Yes please. This won't change. Then simply reject the PEP and the discussion can be stopped on comp.lang.python too. Or why do you think it should be discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Regards ___ 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] Draft proposal: Implicit self in Python 3.0
Just one short comment of your ( well written ) rationale and PEP. Ruby might be hyped at the moment but at least in the german labour market and the biggest german freelancer mediation Ruby is quite inexistent. Even when the nerdish blogosphere is setting different priorities SAP and Intel made million $ investments in Zend Corp. and PHP but not in RoR. The slashdot sociology is not all important. If its just about rhetorical battles, hype and popularity Pythonistas would do a better service for themselves not to change Pythons object model but write a J2EE-like spec, standardize it and provide a reference implementation ( "THE agile alternative!... "). Kay ___ 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] Replacement for print in Python 3.0
Nick Coghlan wrote: > Greg Ewing wrote: > >>Guido van Rossum wrote: >> >> >>>So let's call it the "Swiss Army Knife >>>(...Not)" API design pattern. >> >> >>Aha! Maybe this is the long-lost 20th principle from >>the Zen of Python? > > > It also sounds like one of the reasons why the ultimates in programming swiss > army knives (that is, Lisp macros and Ruby blocks) are unlikely to make an > appearance in Python in their full, unconstrained 'glory'. . . In the context of my proposal it seems to imply some variation of Einsteins famous sentence: "Make everything as general as possible but not more general" or "Make everything as powerfull as possible but not more powerfull". The measure of possibility in this context may be serious community requirements. That's why I might have the impression that the language doesn't get any *deeper* but it is still very close to my actual work and highly usable. On the other hand I have to admit that I'm not really glad about 3 functions in favour for one statement. Introducing of a Writer object is just a different way of factoring and handling special cases and defaults. But I don't believe in an absolute truth about that. I'm not an OO stalinist. > There's an interesting comparison with UI design though - having a couple of > different tools in the interface with sensible default behaviour is generally > easier to use than a single tool where you have to tell it which behaviour > you > want all the time (or pick one as the default, and have to remember to tell > the application when you want the other behaviour). Hmm.. Guido cited strip, rstrip and lstrip for a good factoring into different functions. To me this is a limit case. It can become annoying soon and an API design antipattern. May I remember about C's vprintf, vfprintf, vsprintf, vsnprintf or the beauty of execl, execle, execlp, execlpe, execv, execve, execvp, execvpe? That's so grotesque that I feel deeply connected to Xah Lees crusade against UNIX in sudden moments ;) Kay ___ 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] Replacement for print in Python 3.0
Guido van Rossum wrote:
> I see two different ways to support the two most-called-for additional
> requirements: (a) an option to avoid the trailing newline, (b) an
> option to avoid the space between items.
>
> One way would be to give the print() call additional keyword
> arguments. For example, sep="//" would print double slashes between
> the items, and sep="" would concatenate the items directly. And
> end="\r\n" could be used to change the newline delimiter to CRLF,
> while end="" would mean to suppress the newline altogther.
>
> But to me that API becomes rather klunky; I'd rather have a separate
> function (printbare() or write()?) that just writes its arguments as
> strings to sys.stdout (or to the file given with a keyword argument)
> without intervening spaces or trailing newline.
I guess there are three options:
a) keyword arguments
b) distributing similar functionality over several functions
c) using an object for configuration
In case a) I miss some visual clue. That's mostly because an arbitrary
string is passed to print(). For this reason I like the current print
statement in it's simplicity.
b) maybe the least extendable solution but can be mixed with a) if
necessary.
c) is the most heavyweight solution, but can encapsulate options and is
reusable:
>>> Writer(sep="//").print("some","text")
some//text
or
writer = Writer(sep="//", file=sys.stderr)
writer.print("some","error-text")
writer.print("another","error text")
A bare print() can be considered as a call to some default_writer.
Substituting the default_writer by some custom Writer object may replace
the default configuration, which should be easily resetable:
>>> Writer.default_writer = Writer(sep="//")
>>> print("some","error-text")
some//error_text
>>> Writer.reset()
>>> print("some","error-text")
some error-text
I think that reduces the weight of the object solution and enables all
kind of configurations as user defined default. A lightweight print() is
still possible:
The print() function would be implemented like this:
def print(*args):
Writer.default_writer.print(*args)
I appreciate very much functions that are just shortcuts for certain
methods.
For consistency reasons the function write() may be a better name choice
then print(), but also a different name for Writer() would be an option
in case of c).
Kay
___
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] Python 3 design principles
Oren Tirosh wrote: > Python 3 will most probably make big changes in the internal > implementation and the C API. Perhaps it will even be generated from > PyPy. Don't you think the current Python 3 "visions" becomes rather pointless with the raise of PyPy and interpreter extensions that are developed polymorphically? If the distinction between a user defined package and a language extension becomes more or less irrelevant who needs a language design committee for it's control? If someone takes the Python core in order to implement static typing it might be happen and run in a separate object space. But than, I'm almost sure, it won't be an ill-defined concept like "optional static typing" but Hindley-Milnor ( or a generalization ) which restricts dynamicity but enables type safety and static control otherwise. The idea of forking a language with a new release and thereby deevaluating older code seems somewhat archaic to me. Or the other way round: archaic materials and media like papyrus and scripture enabled communication across centurys changing slightly evolutionary and continously. Form this point of view PL development is still in a state of modernistic, youthfull irresponsibility. > I don't think keeping the common subset will really stand in the way > of making big improvements. The proposed 3.x changes that break it > seem more like nitpicking to me than significant improvements. So it seems. Kay ___ 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] Remove str.find in 3.0?
Terry Reedy wrote:
>>I would object to the removal of str.find().
>
>
> So, I wonder, what is your favored alternative?
>
> A. Status quo: ignore the opportunity to streamline the language.
I actually don't see much benefits from the user perspective. The
discourse about Python3000 has shrunken from the expectation of the
"next big thing" into a depressive rhetorics of feature elimination.
The language doesn't seem to become deeper, smaller and more powerfull
but just smaller.
> B. Change the return type of .find to None.
>
> C. Remove .(r)index instead.
>
> D. Add more redundancy for those who do not like exceptions.
Why not turning index() into an iterator that yields indices
sucessively? From this generalized perspective we can try to reconstruct
behaviour of Python 2.X.
Sometimes I use a custom keep() function if I want to prevent defining a
block for catching StopIteration. The keep() function takes an iterator
and returns a default value in case of StopIteration:
def keep(iter, default=None):
try:
return iter.next()
except StopIteration:
return default
Together with an index iterator the user can mimic the behaviour he
wants. Instead of a ValueError a StopIteration exception can hold as
an "external" information ( other than a default value ):
>>> keep( "abcdabc".index("bc"), default=-1) # current behaviour of the
# find() function
>>> (idx for idx in "abcdabc".rindex("bc")) # generator expression
Since the find() method acts on a string literal it is not easy to
replace it syntactically. But why not add functions that can be hooked
into classes whose objects are represented by literals?
def find( string, substring):
return keep( string.index( substring), default=-1)
str.register(find)
>>> "abcdabc".find("bc")
1
Now find() can be stored in a pure Python module without maintaining it
on interpreter level ( same as with reduce, map and filter ).
Kay
___
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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Skip Montanaro wrote: > >> As I see it, a lambda is an anonymous function. An anonymous function > >> is a function without a name. We already have a syntax for a > >> function... why not use it. ie: > >> > >> f = filter(def (a): return a > 1, [1,2,3]) > > Kay> You mix expressions with statements. > > You could remove the "return" and restrict the body of the def to an > expression: > > f = filter(def (a): a > 1, [1,2,3]) > > That looks almost exactly like a lambda, but uses "def" and parenthesizes > the argument list. It seems to me that would remind people "this is a > function". Yes, but skipping the name of a function ( anonymizing it ) is not a strong reason to disallow statements in the anonymus function body. The crucial issue is the notation of callable expressions that are not statements but can be defined inside of other expressions ( e.g. inside a filter() call as in the example ). That's why I prefer notations that emphasize the expression character. Using the arrow notation ( (args) -> expr ) would be fine for me but I would not deselect Python in favor for Java if ( expr from (args) ) is used instead. To me it's a "judean popular front" vs "popular front of judea" kind of thing. Kay ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Reinhold Birkenfeld wrote: >> >>lambda x,y: x+y*y >>lambda x,y: y**2+x >> >> are essentialy the same functions with different implementations [1]. > > > Except that they are not. Think of __pow__, think of __add__ and __radd__. You know the difference between the concept of a function and it's infinitely many representations? That's why formal definitions exist. > > Reinhold > > Just for refresh: "Formally, a function f from a set X of input values to a set Y of possible output values (written as f : X -> Y) is a relation between X and Y which satisfies: 1. f is total, or entire: for all x in X, there exists a y in Y such that x f y (x is f-related to y), i.e. for each input value, there is at least one output value in Y. 2. f is many-to-one, or functional: if x f y and x f z, then y = z. i.e., many input values can be related to one output value, but one input value cannot be related to many output values. A more concise expression of the above definition is the following: a function from X to Y is a subset f of the cartesian product X × Y, such that for each x in X, there is a unique y in Y such that the ordered pair (x, y) is in f." http://en.wikipedia.org/wiki/Function_%28mathematics%29 Kay ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote:
> I don't get what the problem is with mixing statement and expression
> semantics... from a practial point of view, statements just offer a
> superset of expression functionality.
>
> If there really is a serious practical reason why they must be limited
> to expressions, why not just raise an exception or something if the
> "anonymous function" is too complicated...
>
> I did some fiddling and it seems lambda's can call methods and stuff
> that can have side effects, which kinda defeats what I thought was the
> point of "statements vs expressions"... I guess I just don't
> understand... maybe I'm just thick :-)
The whole point is that you are able to do all the basic control flow
operations like IF, FOR and WHILE using simple expressions ( like in
Pythons lambda ), the lambda statement itself and recursion. Therefore
lambda expressions constitute a Turing complete language and they also
do so in Python. Different to many FP languages lambda plays no central
role in Python because statements won't be reduced to lambda expressions
( or some kind of ). They are merely an add-on.
Reduction provides often the advantage to make expressions/statements
scriptable what they are not in Python. Python is strong in scripting
classes/objects ( a big plus of the language ) but you can't simply use
the language to prove that
lambda x,y: x+y*y
lambda x,y: y**2+x
are essentialy the same functions with different implementations [1]. I
think this is a severe lack of expressibility and has nothing to do with
the silly objection that one has to write one more line for a simple
callback - o.k. I admit that I'm lazy too ;)
Regards,
Kay
[1] Not without hacking the parse tree. Doing so one might finally end
up accessing the expression in a simple modifieable manner:
>>> (lambda x,y: x+y*y).expr
('+',(x,'*',(y,y)))
>>> (lambda x,y: y**2+x).expr
('+',(('**',(y,2)),x))
___
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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote: > I must admit I ended up deleting most of the "alternative to lambda" > threads after they flooded my in box. So it is with some dread I post > this, contributing to it... I must admit you are right. And I will stop defending my proposal because it seems to create nothing more than pointless polemics. Suggesting elements of FP to python-dev may have the same chances to be accepted than raising a Buddha statue in a catholic church. > As I see it, a lambda is an anonymous function. An anonymous function is > a function without a name. We already have a syntax for a function... > why not use it. ie: > > f = filter(def (a): return a > 1, [1,2,3]) You mix expressions with statements. This is a no-go in Python. Permitting those constructs is a radical language change not just a simple syntax replacement. Kay ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Josiah Carlson wrote: > Kay Schluehr <[EMAIL PROTECTED]> wrote: > > >> Maybe anonymus function closures should be pushed forward right now not only syntactically? Personally I could live with lambda or several >> of the alternative syntaxes listed on the wiki page. >> > > > > >> But asking for a favourite syntax I would skip the "def" keyword from your def-arrow syntax proposal and use: >> >>((a, b, c) -> f(a) + o(b) - o(c)) >> > > ... > > > >> The arrow is a straightforward punctuation for function definitions. Reusing existing keywords for different semantics seems to me as a kind of inbreeding. >> > > > That's starting to look like the pseudocode from old algorithms > textbooks, which is very similar to bad pseudocode from modern CS theory > papers. Punctuation as a replacement for words does not always win > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...) > > Writing functions as arrows is very convenient not only in CS but also in mathematics. Looking like pseudo-code was not one of Guidos Python regrets if I remember them correctly. > -1 on the syntax offering. > > > >> For pushing anymus functions forward I propose to enable explizit partial evaluation as a programming technique: >> > > > If I remember correctly, we've got rightcurry and leftcurry for that (or > rightpartial and leftpartial, or something). > > Currying usually does not perform a function evaluation in order to create another more special function. Partial evaluation is a dynamic programming and optimization technique. Psyco uses specialization and caching implicitely. I propose to use it explicitely but in a more restricted context. >> >>> ((x,y) -> (x+1)*y**2) >> ((x,y) -> (x+1)*y**2) >> >> >>> ((x,y) -> (x+1)*y**2)(x=5) >> ((y) -> 6*y**2) >> > > > I'll assume that you don't actually want it to rewrite the source, or > actually return the source representation of the anonymous function > (those are almost non-starters). > > Computer algebra systems store expressions in internal tree form, manipulate them efficiently and pretty-print them in textual or latex output on demand. There would be much more involved than a tree to tree translation starting with Pythons internal parse tree and an evaluator dedicated to it. > As for all anonymous functions allowing partial evaluation via keywords: > it would hide errors. Right now, if you forget an argument or add too > many arguments, you get a TypeError. Your proposal would make > forgetting an argument in certain ways return a partially evaluated > function. That's why I like to dump the function in a transparent mode. Personally I could dispense a little security in favor for cheap metainformation. Regards, Kay ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > Guido van Rossum wrote: > >>>Recommend accepting just the basic PEP which only targets simple, >>>obvious cases. The discussed extensions are unattractive and should be >>>skipped. >> >> >>-1. The "unary colon" looks unPythonic to me. >> > > > Step 1 would be to require parentheses around the whole thing (ala > generator expressions) to make it easier to see where the deferred > expression ends. > > But all my use cases that I can think off the top of my head involve > 'sorted', where it wouldn't help at all because of the need for an > argument. > > So I'd rather see a serious discussion regarding giving lambdas a more > Pythonic syntax in general, rather than one that only applied to the > 'no-argument' case [1] > > Cheers, > Nick. > > [1] http://wiki.python.org/moin/AlternateLambdaSyntax > The 'expression-before-args' version using just the 'from' keyword is > still my favourite. > Maybe anonymus function closures should be pushed forward right now not only syntactically? Personally I could live with lambda or several of the alternative syntaxes listed on the wiki page. But asking for a favourite syntax I would skip the "def" keyword from your def-arrow syntax proposal and use: ((a, b, c) -> f(a) + o(b) - o(c)) ((x) -> x * x) (() -> x) ((*a, **k) -> x.bar(*a, **k)) ( ((x=x, a=a, k=k) -> x(*a, **k)) for x, a, k in funcs_and_args_list) The arrow is a straightforward punctuation for function definitions. Reusing existing keywords for different semantics seems to me as a kind of inbreeding. For pushing anymus functions forward I propose to enable explizit partial evaluation as a programming technique: Example 1: >>> ((x,y) -> (x+1)*y**2) ((x,y) -> (x+1)*y**2) >>> ((x,y) -> (x+1)*y**2)(x=5) ((y) -> 6*y**2) Example 2: def f(x): return x**2 >>> ((x,y) -> f(x)+f(y))(x=2) ((y) -> 4 + f(y)) Example 3: >>> ((f,x,y) -> f(x)+f(y))(f=((x)-> x**2), y=3) ((x) -> ((x)-> x**2))(x)+9) The keyword style argument passing can be omitted in case of complete evaluation where pattern matching on the argument tuple is applied. Regards, Kay ___ 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
