From szport at gmail.com  Sat Nov  1 15:07:59 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Sat, 1 Nov 2008 17:07:59 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>
Message-ID: <e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>

Python Object Notation (PyON<http://code.google.com/p/pyon/wiki/GettingStarted>
)

Python 2.6/3.0 now has a module ast. This opens up new opportunities. One of
them is the possibility of introducing human readable/writable literal
object notation, based on the syntax of the python language.

I would like to know what do you think about this?

Best regards,
Zaur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081101/f9a58809/attachment.html>

From tjreedy at udel.edu  Sat Nov  1 18:09:31 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 01 Nov 2008 13:09:31 -0400
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>
	<e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>
Message-ID: <gei2g9$vnp$1@ger.gmane.org>

Zaur Shibzoukhov wrote:
> Python Object Notation (PyON 
> <http://code.google.com/p/pyon/wiki/GettingStarted>)
> 
> Python 2.6/3.0 now has a module ast. This opens up new opportunities. 
> One of them is the possibility of introducing human readable/writable 
> literal object notation, based on the syntax of the python language.

Other than syntax details, how is PyON different from json, yaml (3rd 
party module), and anything else?

I see at bottom time comparison with pickle and json, but only that.

> I would like to know what do you think about this?

Grammar:   <kw> := <name> = <pyon_expr>, ..., <name> = <pyon_expr>
There is no rule for pyon_expr.  Did you just mean <expr>?

...   y=IF(
...     flag,
...     A1(kind='A1'),
...     A2(kind='A2')
...   )

Where does IF come from?

   * extension objects didn't take in mind.
needs to be rewritten



From arnodel at googlemail.com  Sat Nov  1 20:22:00 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Sat, 1 Nov 2008 19:22:00 +0000
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <gei2g9$vnp$1@ger.gmane.org>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>
	<e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>
	<gei2g9$vnp$1@ger.gmane.org>
Message-ID: <9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>


On 1 Nov 2008, at 17:09, Terry Reedy wrote:

> Zaur Shibzoukhov wrote:
>> Python Object Notation (PyON <http://code.google.com/p/pyon/wiki/GettingStarted 
>> >)
>> Python 2.6/3.0 now has a module ast. This opens up new  
>> opportunities. One of them is the possibility of introducing human  
>> readable/writable literal object notation, based on the syntax of  
>> the python language.
>
> Other than syntax details, how is PyON different from json, yaml  
> (3rd party module), and anything else?

Looking at the page, it seems to me that it aims to:

* be able to give a string representation of any(*) object like pickle  
and unlike json
* produce human readable output like json and unlike pickle

(*) for a suitable definition of 'any', ideally the same as pickle I  
guess.

That would be good.  There are several examples of pyon.loads, but  
none of pyon.dumps, which would be interesting.

E.g. can pyon.dumps dump obj accurately for the following value of obj?

lst = [1, 2]
obj = [lst, lst]

I would expect pyon.dumps(obj) to give something like:
"""
sym0 = [1, 2]
obj = [sym0, sym0]
"""

-- 
Arnaud



From szport at gmail.com  Sat Nov  1 20:47:07 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Sat, 1 Nov 2008 22:47:07 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811011247h7dd43dd2y6d148cf3cad58281@mail.gmail.com>

Terry Reedy wrote:

> Other than syntax details, how is PyON different from json, yaml (3rd
> party module), and anything else?

I hope that PyON can be seen as native literal object notation for objects
in python language. Similar to what JSON is for JavaScript ;) JavaScript
hasn't classes, but python has that. So we could say that PyON in some way
extends JSON. I that it's better reflecting python's object model.

I'l try to explain this by example. Let

class Person(object):
pass

person = Person()
person.name = 'John'
person.age = 33

First, in PyON person represents as "Person(name='John', age=33)" and loads
return an instance of Person.
In JSON we need to represent person in a way similar to "{'class':'Person',
'name':'John', 'age':33}" and loads always return dict-like structure, not
instance of Person.

Second, object instance reconstruction from PyON string or AST performs
according to picklie protocol (3). This mean that if we define class that
implements right methods in accordance to pickle protocol then we can dumps
to PyON string and loads from that.

I didn't yet made comparison with yaml. I should do that too. Now I can only
say that yaml is much complicated notation (IMHO).

>>> Grammar: <kw> := <name> = <pyon_expr>, ..., <name> = <pyon_expr>
>>> There is no rule for pyon_expr. Did you just mean <expr>?
You right, thank you. This a tipo. I'l update the page.

> ... y=IF(
> ... flag,
> ... A1(kind='A1'),
> ... A2(kind='A2')
> ... )

This didn't covered by current rough gramma definition. I still do not know
if this must be a part of PyON.
The fact is that PyON can be extended to thing such as "object template" and
current implementation include some of such opportunities. One of this you
pointed out here. Here is another example:
       person = loads("Person(name=real_name, age=real_age)",
real_name='John', real_age=33)


Best regards,
Zaur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081101/5d806b9d/attachment.html>

From grosser.meister.morti at gmx.net  Sat Nov  1 20:49:48 2008
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Sat, 01 Nov 2008 20:49:48 +0100
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>	<e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>	<gei2g9$vnp$1@ger.gmane.org>
	<9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>
Message-ID: <490CB2DC.6060009@gmx.net>

Arnaud Delobelle schrieb:
> 
> E.g. can pyon.dumps dump obj accurately for the following value of obj?
> 
> lst = [1, 2]
> obj = [lst, lst]
> 
> I would expect pyon.dumps(obj) to give something like:
> """
> sym0 = [1, 2]
> obj = [sym0, sym0]
> """
> 

I wonder what it would yield in this case:
lst = ['foo']
lst.append(lst)


	-panzi


From denis.spir at free.fr  Sat Nov  1 21:09:15 2008
From: denis.spir at free.fr (spir)
Date: Sat, 01 Nov 2008 21:09:15 +0100
Subject: [Python-ideas] type/instance method syntax
Message-ID: <490CB76B.6020100@free.fr>

Hello,

[New to the list. I spent some time exploring the archives, still I'm 
not really sure of what kind of subjects fit here -- or not. If ever 
this post, or a further one, is out of topic, just tell me.
Also, I'm a self-trained amateur, and neither python nore english is my 
native language, thus I may use non-standard idioms. ;-)]

-1- real-life case (can safely be skipped)

I'm writing an application that should allow a user to chose between 
several wiki languages, including customized versions, on one side; and 
uses either a subset of xhtml, or simple plain text tables (simulation 
of DB import/export), as saving/exchange/standard format.
To do this, I have a whole lot of configurable "Symbol" sub-types, each 
representing a common language feature. (I imagine there are tons of 
more professional approaches, but this is not my point -- I do it for 
pleasure.) A list of symbols (instances), parsed from a source text, 
build an abstract, language-independant, image of the text. The types 
have to take the (wiki-side) configuration into account; I also wish 
this config to be "switchable" at run-time. An example use of this 
feature is to "transcode" a wiki source text into another wiki format.
The pattern of a symbol type is then:

class BlockFormat(Symbol):
    def config():
        <set type attributes>
    def __init__(self, source, ...):
        <read instance attributes from source doc>
    <read/write methods from/into known languages>

I /really/ expected this to work. config() obviously was, for me, a 
type/class method. I intended to call it and its sisters from a module 
top-level function:
def config():
    wiki_config.build(config_file_name)
    for symbol_type in symbol_types:
        symbol_type.config()

As a consequence, I happily discovered both classmethod() and 
@classmethod.(Actually, I hadn't programmed for a long time, had 
forgotten some idiomatic "details", and knew about nothing of python >= 
2.0, except for the overall new_style_classes pattern.)

-2- type/instance attribute pattern

(Below is called 'property' a non-callable object attribute, as opposed 
to 'method'. I do not know if a better, standard, term is used in the 
python community.)

                type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)+X       def f(self,args)

(where X means either classmethod() or @classmethod)

I wondered where the point is before writing down this table. Why (1) I 
intended my code to work as is (2) we need to add a line of code to 
define a class method.
In order to distinguish an instance property from a type one, the former 
is simply prefixed with 'self' -- or any placeholder for a potential 
instance name --, later with the actual instance's name. This pattern 
fully applies to method call. But is broken for method definition, for 
any reason I'm unable to guess. I think this explains why I wrote the 
code above.
Now, watching such a table, the additional instruction looks to my eyes 
like a workaround rather than a feature. Actually, the instance method 
definition syntax takes the place of
the one that may be expected for class methods instead. Lets imagine 
this slight change:

                type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)         def self.f(args)       <==

Doesn't this deliciously fit in the table? Not only the syntax for 
instance method definition matches the call syntax; but also the whole 
method pattern matches the one for properties.

-3- proposal

I am fully conscious that this syntax cannot be introduced: this would 
have as magic side-effect to transform all instance methods into class 
methods ;-)

I wonder if the following may be considered: Allow prefixing of class 
attributes (esp. methods) with the classe's name -- even in the classe's 
own scope:
class C(object):
    C.a = 1
    def C.f():
        <method body>
This syntax presently launches NameError and SyntaxError, which is 
correct as C is not yet defined, and the second syntax is unknown. 
But... it would allow a nicer syntax to define class method, and more: 
this syntax is precisely the one that will later be used to call the method.

An alternative may be to prefix a class method defintition with either 
'type' or 'class', used as a pseudo keyword:
class C(object):
    def type.f():
        <method body>

Denis




From bruce at leapyear.org  Sat Nov  1 21:29:23 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Sat, 1 Nov 2008 13:29:23 -0700
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>
	<e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>
	<gei2g9$vnp$1@ger.gmane.org>
	<9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>
Message-ID: <cf5b87740811011329j58565316x12f04fd70d37e23c@mail.gmail.com>

YAML does support type tagging (with ! and !!) so I think a good approach to
consider here would be defining a subset of YAML specifically for python
compatibility.

Furthermore, is there any reason this wouldn't be best integrated with
pickle? That is, when I pickle an object, I could specify that it be in
"Pyon" format (or maybe "Pyckle") and when I unpickle, it automatically
accepts any format?

--- Bruce

On Sat, Nov 1, 2008 at 12:22 PM, Arnaud Delobelle <arnodel at googlemail.com>wrote:

>
> Zaur Shibzoukhov wrote:
>>
>>> Python Object Notation (PyON <
>>> http://code.google.com/p/pyon/wiki/GettingStarted>)
>>>
>>> Looking at the page, it seems to me that it aims to:
>
> * be able to give a string representation of any(*) object like pickle and
> unlike json
> * produce human readable output like json and unlike pickle
>
> (*) for a suitable definition of 'any', ideally the same as pickle I guess.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081101/0162aac0/attachment.html>

From arnodel at googlemail.com  Sun Nov  2 14:03:45 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Sun, 2 Nov 2008 13:03:45 +0000
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <490CB2DC.6060009@gmx.net>
References: <e2a7590811010701l766c1534pabf52df038da2035@mail.gmail.com>	<e2a7590811010707ge8a7e38rcfd13b53ad3bfe50@mail.gmail.com>	<gei2g9$vnp$1@ger.gmane.org>
	<9B7CB50A-0788-45AD-9168-FA942AB79F10@googlemail.com>
	<490CB2DC.6060009@gmx.net>
Message-ID: <57D5411C-C49E-4468-93F7-E8E78180DEA5@googlemail.com>


On 1 Nov 2008, at 19:49, Mathias Panzenb?ck wrote:

> Arnaud Delobelle schrieb:
>>
>> E.g. can pyon.dumps dump obj accurately for the following value of  
>> obj?
>>
>> lst = [1, 2]
>> obj = [lst, lst]
>>
>> I would expect pyon.dumps(obj) to give something like:
>> """
>> sym0 = [1, 2]
>> obj = [sym0, sym0]
>> """
>>
>
> I wonder what it would yield in this case:
> lst = ['foo']
> lst.append(lst)
>


I guess it could be:
"""
sym0 = ['foo', sym0]
sym0
"""

I.e, one could allow 'assignments' to be made in any order as long as  
all names are eventually defined. E.g.

== pyon form ==
"""
a = [1, b]
b = [a, 2]
a, b
"""

Which would describe the following two objects:

== python form ==
a = [1, None]
b = [None, 2]
a[1] = b
b[0] = 1

The conversion between the two forms seems doable.  Or maybe the  
'python form' should be the 'pyon form', there would b a need for  
extending the syntax so that foo[bar] and foo.bar can appear on the  
left hand side of an assignment.

In that case your 'lst' above could be:
"""
sym0 = ['foo', None]
sym0[1] = sym0
sym0
"""

-- 
Arnaud



From denis.spir at free.fr  Sun Nov  2 15:40:06 2008
From: denis.spir at free.fr (spir)
Date: Sun, 02 Nov 2008 15:40:06 +0100
Subject: [Python-ideas] type/instance method syntax
In-Reply-To: <490CB76B.6020100@free.fr>
References: <490CB76B.6020100@free.fr>
Message-ID: <490DBBC6.9090309@free.fr>

Below a more compact reformulation and a different point of view on the same topic.

=== Summary ===

-0- Inside a type definition are decribed both the type and its potential 
instances; a syntactic rule is thus needed to distinguish type and instance 
attributes.
-1- A pattern is used to address that point: namely, the rule is to prefix 
instance attributes with an instance 'pseudonyme', for example "self.a" or 
"self.f(x)". Which is /very/ good: the pseudonyme simply takes the place of a 
not-yet-existing-object-name. Right? This pattern is consistent with overall 
python & OOP syntax, close to 'natural', used both for non-callable attributes 
and methods; except...
-2- For method definition, the following pattern is used: "def f(self,x)"; 
where "def self.f(x)" would be expected instead, accordind to -1-. Problem #1: 
as a simple pattern is broken, the code's clarity/legibility is suffers. Is 
there any advantage to balance that? Note: as the regular pattern does not seem 
to conflict with any other syntactic feature, can we consider allowing it?
-3- As a rather unfortunate side-effect, it happens that the pattern used to 
define instance methods is precisely the one that could be used for type 
methods. Problem #2:  how do we define them, then? The builtin instancemethod() 
introduced in python 2.2 is needed only because of this irregularity (**)(***). 
See below under "proposal" for alternatives.

(*) This does not apply when attributes are adressed from outside the type's 
scope, where ordinary object-name prefixing has to be used, as well as inside 
methods for type attributes.
(**) This applies, of course, to @classmethod.
(***) @staticmethod/staticmethod() instead really introduces a new kind of 
object. As a syntactic feature, its sense is to let python 'know' it. From PEP 
318: "[Decorators] are storing additional information on a function object." 
What is the additional information for a type method? A syntax notation 
conflict with instance methods. A type method is an ordinary method that we 
simply could not write down before.
PEP 318: Decorators for Functions and Methods 
http://www.python.org/doc/2.4.4/whatsnew/node6.html

=== alternative approach ===

In http://www.python.org/dev/peps/pep-0318/, decorators are also called 
'transformators': they return a transformed version of the argument. Decorators 
can be built-in or user-defined. They allow special versions of a main type of 
objects -- presently functions or methods. This is in a way similar to sub-typing:
method
     standard/default
     static
     further built-in sub-type
     user-defined sub-type
In the case of the standard sub-type, the @standard decorator would be the 
(mathematical) identity function that returns its parameter unchanged. Which is 
pointless, needs not beeing implemented, so that the standard sub-type is the 
default one, i.e. identical to the super-type. Right?
An ordinary type method is a method of the standard type. There needs no 
decorator for it. As types are object, they can hold methods (even functions 
can...).  We may consider type methods as special because, due to the syntactic 
conflict described above, there was previously no way to express them. 
Additionally, as classes are mainly regarded as 'real' object generators, they 
are rather seen as static, so that class methods do not belong to everyday 
programming. Still, type methods are standard objects: their syntax should be 
standard.

Denis

PS: Do you know about a site, list, forum about programming language design?
(Answer in private message, please.)


Hello,

[New to the list. I spent some time exploring the archives, still I'm not 
really sure of what kind of subjects fit here -- or not. If ever this post, or 
a further one, is out of topic, just tell me.
Also, I'm a self-trained amateur, and neither python nore english is my native 
language, thus I may use non-standard idioms. ;-)]

-1- real-life case (can safely be skipped)

I'm writing an application that should allow a user to chose between several 
wiki languages, including customized versions, on one side; and uses either a 
subset of xhtml, or simple plain text tables (simulation of DB import/export), 
as saving/exchange/standard format.
To do this, I have a whole lot of configurable "Symbol" sub-types, each 
representing a common language feature. (I imagine there are tons of more 
professional approaches, but this is not my point -- I do it for pleasure.) A 
list of symbols (instances), parsed from a source text, build an abstract, 
language-independant, image of the text. The types have to take the (wiki-side) 
configuration into account; I also wish this config to be "switchable" at 
run-time. An example use of this feature is to "transcode" a wiki source text 
into another wiki format.
The pattern of a symbol type is then:

class BlockFormat(Symbol):
     def config():
         <set type attributes>
     def __init__(self, source, ...):
         <read instance attributes from source doc>
     <read/write methods from/into known languages>

I /really/ expected this to work. config() obviously was, for me, a type/class 
method. I intended to call it and its sisters from a module top-level function:
def config():
     wiki_config.build(config_file_name)
     for symbol_type in symbol_types:
         symbol_type.config()

As a consequence, I happily discovered both classmethod() and 
@classmethod.(Actually, I hadn't programmed for a long time, had forgotten some 
idiomatic "details", and knew about nothing of python >= 2.0, except for the 
overall new_style_classes pattern.)

-2- type/instance attribute pattern

(Below is called 'property' a non-callable object attribute, as opposed to 
'method'. I do not know if a better, standard, term is used in the python 
community.)

                 type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)+X       def f(self,args)

(where X means either classmethod() or @classmethod)

I wondered where the point is before writing down this table. Why (1) I 
intended my code to work as is (2) we need to add a line of code to define a 
class method.
In order to distinguish an instance property from a type one, the former is 
simply prefixed with 'self' -- or any placeholder for a potential instance name 
--, later with the actual instance's name. This pattern fully applies to method 
call. But is broken for method definition, for any reason I'm unable to guess. 
I think this explains why I wrote the code above.
Now, watching such a table, the additional instruction looks to my eyes like a 
workaround rather than a feature. Actually, the instance method definition 
syntax takes the place of
the one that may be expected for class methods instead. Lets imagine this 
slight change:

                 type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)         def self.f(args)       <==

Doesn't this deliciously fit in the table? Not only the syntax for instance 
method definition matches the call syntax; but also the whole method pattern 
matches the one for properties.

-3- proposal(s)

I am fully conscious that this syntax cannot be introduced: this would have as 
magic side-effect to transform all instance methods into class methods ;-)

I wonder if the following may be considered: Allow prefixing of class 
attributes (esp. methods) with the classe's name -- even in the classe's own scope:
class C(object):
     C.a = 1
     def C.f():
         <method body>
This syntax presently launches NameError and SyntaxError, which is correct as C 
is not yet defined, and the second syntax is unknown. But... it would allow a 
nicer syntax to define class method, and more: this syntax is precisely the one 
that will later be used to call the method.

An alternative may be to prefix a class method defintition with either 'type' 
or 'class', used as a pseudo keyword:
class C(object):
     def type.f():
         <method body>

Denis


spir a ?crit :
> Hello,
> 
> [New to the list. I spent some time exploring the archives, still I'm 
> not really sure of what kind of subjects fit here -- or not. If ever 
> this post, or a further one, is out of topic, just tell me.
> Also, I'm a self-trained amateur, and neither python nore english is my 
> native language, thus I may use non-standard idioms. ;-)]
> 
> -1- real-life case (can safely be skipped)
> 
> I'm writing an application that should allow a user to chose between 
> several wiki languages, including customized versions, on one side; and 
> uses either a subset of xhtml, or simple plain text tables (simulation 
> of DB import/export), as saving/exchange/standard format.
> To do this, I have a whole lot of configurable "Symbol" sub-types, each 
> representing a common language feature. (I imagine there are tons of 
> more professional approaches, but this is not my point -- I do it for 
> pleasure.) A list of symbols (instances), parsed from a source text, 
> build an abstract, language-independant, image of the text. The types 
> have to take the (wiki-side) configuration into account; I also wish 
> this config to be "switchable" at run-time. An example use of this 
> feature is to "transcode" a wiki source text into another wiki format.
> The pattern of a symbol type is then:
> 
> class BlockFormat(Symbol):
>    def config():
>        <set type attributes>
>    def __init__(self, source, ...):
>        <read instance attributes from source doc>
>    <read/write methods from/into known languages>
> 
> I /really/ expected this to work. config() obviously was, for me, a 
> type/class method. I intended to call it and its sisters from a module 
> top-level function:
> def config():
>    wiki_config.build(config_file_name)
>    for symbol_type in symbol_types:
>        symbol_type.config()
> 
> As a consequence, I happily discovered both classmethod() and 
> @classmethod.(Actually, I hadn't programmed for a long time, had 
> forgotten some idiomatic "details", and knew about nothing of python >= 
> 2.0, except for the overall new_style_classes pattern.)
> 
> -2- type/instance attribute pattern
> 
> (Below is called 'property' a non-callable object attribute, as opposed 
> to 'method'. I do not know if a better, standard, term is used in the 
> python community.)
> 
>                type/class          instance
> property        prop                self.prop
> method call     f(args)             self.f(args)
> method def      def f(args)+X       def f(self,args)
> 
> (where X means either classmethod() or @classmethod)
> 
> I wondered where the point is before writing down this table. Why (1) I 
> intended my code to work as is (2) we need to add a line of code to 
> define a class method.
> In order to distinguish an instance property from a type one, the former 
> is simply prefixed with 'self' -- or any placeholder for a potential 
> instance name --, later with the actual instance's name. This pattern 
> fully applies to method call. But is broken for method definition, for 
> any reason I'm unable to guess. I think this explains why I wrote the 
> code above.
> Now, watching such a table, the additional instruction looks to my eyes 
> like a workaround rather than a feature. Actually, the instance method 
> definition syntax takes the place of
> the one that may be expected for class methods instead. Lets imagine 
> this slight change:
> 
>                type/class          instance
> property        prop                self.prop
> method call     f(args)             self.f(args)
> method def      def f(args)         def self.f(args)       <==
> 
> Doesn't this deliciously fit in the table? Not only the syntax for 
> instance method definition matches the call syntax; but also the whole 
> method pattern matches the one for properties.
> 
> -3- proposal
> 
> I am fully conscious that this syntax cannot be introduced: this would 
> have as magic side-effect to transform all instance methods into class 
> methods ;-)
> 
> I wonder if the following may be considered: Allow prefixing of class 
> attributes (esp. methods) with the classe's name -- even in the classe's 
> own scope:
> class C(object):
>    C.a = 1
>    def C.f():
>        <method body>
> This syntax presently launches NameError and SyntaxError, which is 
> correct as C is not yet defined, and the second syntax is unknown. 
> But... it would allow a nicer syntax to define class method, and more: 
> this syntax is precisely the one that will later be used to call the 
> method.
> 
> An alternative may be to prefix a class method defintition with either 
> 'type' or 'class', used as a pseudo keyword:
> class C(object):
>    def type.f():
>        <method body>
> 
> Denis
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
> 
> 




From szport at gmail.com  Mon Nov  3 06:52:19 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Mon, 3 Nov 2008 08:52:19 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811022152p973ed6cp8d80821d1b1404d2@mail.gmail.com>

Arnaud Delobelle wrote:
> Looking at the page, it seems to me that it aims to:
> * be able to give a string representation of any(*) object like pickle
> and unlike json
>* produce human readable output like json and unlike pickle
Yes it works that way.

> (*) for a suitable definition of 'any', ideally the same as pickle I
> guess.
Now pyon can't dump any recursive object. It can dump recursive lists
and tuples now.
I also going to add support for recursive dicts, and then for other objects.

> lst = [1, 2]
> obj = [lst, lst]
pyon.dumps(obj, fast=False; this mode similar to pickle's fast mode)
produce a following text:
_p__0=[1,2]
[_p__0,_p__0]

pyon.dumps(obj) (i.e. fast=False) produce a following text:
[[1,2],[1,2]]

Best regards,
Zaur


From arnodel at googlemail.com  Mon Nov  3 13:41:33 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Mon, 3 Nov 2008 12:41:33 +0000
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811022152p973ed6cp8d80821d1b1404d2@mail.gmail.com>
References: <e2a7590811022152p973ed6cp8d80821d1b1404d2@mail.gmail.com>
Message-ID: <44112C97-3AD8-4463-88DE-E002E058263B@googlemail.com>


On 3 Nov 2008, at 05:52, Zaur Shibzoukhov wrote:

> Arnaud Delobelle wrote:
>> Looking at the page, it seems to me that it aims to:
>> * be able to give a string representation of any(*) object like  
>> pickle
>> and unlike json
>> * produce human readable output like json and unlike pickle
> Yes it works that way.
>
>> (*) for a suitable definition of 'any', ideally the same as pickle I
>> guess.
> Now pyon can't dump any recursive object. It can dump recursive lists
> and tuples now.
> I also going to add support for recursive dicts, and then for other  
> objects.

How do you represent a recursive list? E.g.

On 1 Nov 2008, at 19:49, Mathias Panzenb?ck wrote:
>
> I wonder what it would yield in this case:
> lst = ['foo']
> lst.append(lst)

-- 
Arnaud



From szport at gmail.com  Mon Nov  3 16:36:57 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Mon, 3 Nov 2008 18:36:57 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811030736h7f495b1dwb6f15efac5d05848@mail.gmail.com>

Arnaud Delobelle wrote:

> How do you represent a recursive list? E.g.
> On 1 Nov 2008, at 19:49, Mathias Panzenb?ck wrote:
> >
> > I wonder what it would yield in this case:
> > lst = ['foo']
> > lst.append(lst)
Now pyon can represent recursive lists and dicts:

>>> lst = ['foo']
>>> lst.append(lst)
>>> pyon.dumps(lst, fast=False) # fast mode is similar to pickle's fast mode
_p__0=['foo',None]
_p__0[1]=_p__0
_p__0

>>> d = {'a':'foo'}
>>> d['b'] = d
>>> pyon.dumps(d, fast=False)
_p__0={'a':'foo'}
_p__0['b']=_p__0
_p__0

I will commit changes to sources this evening.

Best regards,
Zaur


From greg.ewing at canterbury.ac.nz  Tue Nov  4 09:07:56 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 04 Nov 2008 21:07:56 +1300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811030736h7f495b1dwb6f15efac5d05848@mail.gmail.com>
References: <e2a7590811030736h7f495b1dwb6f15efac5d05848@mail.gmail.com>
Message-ID: <491002DC.1020002@canterbury.ac.nz>

Zaur Shibzoukhov wrote:

> _p__0=['foo',None]
> _p__0[1]=_p__0
> _p__0

It would be nice if it could be made a bit more declarative,
such as:

   _p__0=['foo',_p__0]

-- 
Greg


From szport at gmail.com  Tue Nov  4 09:12:53 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Tue, 4 Nov 2008 11:12:53 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811040012s71e4919by806d4f50d20be12e@mail.gmail.com>

Bruce Leban wrote:

> Furthermore, is there any reason this wouldn't be best integrated with
> pickle? That is, when I pickle an object, I could specify that it be in
> "Pyon" format (or maybe "Pyckle") and when I unpickle, it automatically
> accepts any format?
I think it could be integrated with pickle.

Best regards,
Zaur


From arnodel at googlemail.com  Tue Nov  4 12:09:45 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Tue, 4 Nov 2008 11:09:45 +0000
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <491002DC.1020002@canterbury.ac.nz>
References: <e2a7590811030736h7f495b1dwb6f15efac5d05848@mail.gmail.com>
	<491002DC.1020002@canterbury.ac.nz>
Message-ID: <9bfc700a0811040309u384c3894u9c84273499b79388@mail.gmail.com>

2008/11/4 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> Zaur Shibzoukhov wrote:
>
>> _p__0=['foo',None]
>> _p__0[1]=_p__0
>> _p__0
>
> It would be nice if it could be made a bit more declarative,
> such as:
>
>  _p__0=['foo',_p__0]
>
> --
> Greg

I implemented a rough version of dumps for fun on sunday, and I
decided to let recursive / mutually recursive object be represented in
this manner.  Here are some examples below.

    >>> print dumps([1, 2, 1])
    [1, 2, 1]

Recursive objects are represented 'declaratively'

    >>> x = [1, 2]
    >>> y = [x, 'a', x]
    >>> print dumps(y)
    sym0 = [1, 2]
    [sym0, 'a', sym0]

Mutually recursive objects also:

    >>> x.append(y)
    >>> print dumps((x, y))
    sym0 = [1, 2, sym1]
    sym1 = [sym0, 'a', sym0]
    (sym0, sym1)

Some examples with dictionaries

    >>> d = {'foo': (1, 2)}
    >>> print dumps(d)
    {'foo': (1, 2)}

    >>> d['me'] = d
    >>> print dumps(d)
    sym0 = {'me': sym0, 'foo': (1, 2)}
    sym0

An example with a class

    >>> class A(object): pass
    ...
    >>> a = A()
    >>> a.my = 'spam'
    >>> a.oh = (3, a)
    >>> print dumps(a)
    sym0 = A(my='spam', oh=(3, sym0))
    sym0

Implementing this gave me the idea of extending it to representing
object 'given' some definition. E.g. given that a='hello', then
['hello', 'world'] can be represented as [a, 'world'].

This could be useful as when 'pickling' an object sometimes you end up
pickling a lot of the state of the program, which is not necessary as
you know it will not vary.  Or sometimes you would like to pickle
something 'modulo' some state.  E.g.

    >>> print dumps(['hello', 'world'], a='hello')
    [a, 'world']

For hashable types, equal objects will be factored:

    >>> t = (1, 2)
    >>> print dumps(((1, 2), (1, 2)), u=(1, 2))
    (u, u)
    >>> print dumps((t, (1, 2)), u=(1, 2))
    (u, u)

For non hashable types, this is not the case unless the objects are
actually the same object:

    >>> l = [1, 2]
    >>> print dumps((l, l), mylist=l)
    (mylist, mylist)
    >>> print dumps((l, [1, 2]), mylist=l)
    (mylist, [1, 2])

One last example:

    >>> a = 3
    >>> b = [1, 2]
    >>> class C(object): pass
    ...
    >>> c = C()
    >>> c.x = a, b
    >>> b.append(c)
    >>> print dumps(c)
    sym0 = C(x=(3, [1, 2, sym0]))
    sym0
    >>> c.y={a:b}
    >>> print dumps(c)
    sym0 = C(y={3: sym1}, x=(3, sym1))
    sym1 = [1, 2, sym0]
    sym0
    >>> print dumps(b)
    sym0 = [1, 2, C(y={3: sym0}, x=(3, sym0))]
    sym0
    >>> print dumps(b, c=c)
    [1, 2, c]

-- 
Arnaud


From greg.ewing at canterbury.ac.nz  Wed Nov  5 01:42:53 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 05 Nov 2008 13:42:53 +1300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <9bfc700a0811040309u384c3894u9c84273499b79388@mail.gmail.com>
References: <e2a7590811030736h7f495b1dwb6f15efac5d05848@mail.gmail.com>
	<491002DC.1020002@canterbury.ac.nz>
	<9bfc700a0811040309u384c3894u9c84273499b79388@mail.gmail.com>
Message-ID: <4910EC0D.1010306@canterbury.ac.nz>

Arnaud Delobelle wrote:

> For hashable types, equal objects will be factored:
> 
>     >>> t = (1, 2)
>     >>> print dumps(((1, 2), (1, 2)), u=(1, 2))
>     (u, u)

Careful -- hashability is not necessarily the same thing
as immutability. It's possible for an object to be hashable
while still having mutable state, as long as the mutable
state isn't included in the criteria for equality. But
an application may still care about the identity of such
objects.

-- 
Greg


From szport at gmail.com  Wed Nov  5 09:16:40 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Wed, 5 Nov 2008 11:16:40 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>

I have added support for naming objects in dumps,  cross-references
and declarative support in dumps/loads too.
I can't now commit changes. This night I will commit changes to
sources and update project pages.

Here are examples of how it works now:

== Examples with loads==

===Example with recursive list===

>>> lst = pyon.loads("""
... lst = ['foo', lst]
... lst""")
>>> lst is lst[1]
True

===Example with recursive dict===

>>> d = pyon.loads("""
... d = {'a':'foo', 'b':d}
... d""")
>>> d is d['b']
True

===Example with cross-references===

>>> ob = pyon.loads("""
... lst = ['foo', lst, d]
... d = {'a':'foo', 'b':d, 'c':lst}
... [d, lst]""")
>>> lst = ob[1]
>>> d = ob[0]
>>> lst[1] is lst
True
>>> d is d['b']
True
>>> lst[2] is d
True
>>> d['c'] is lst
True

===Example with recursive class and cross-references===

>>> ob = pyon.loads("""
... c = C(parent=c, lst=lst, d=d)
... lst = ['foo', lst, d, c]
... d = {'a':'foo', 'b':d, 'c':lst, 'd':c}
... [d, lst, c]""")
>>> lst = ob[1]
>>> d = ob[0]
>>> c = ob[2]
>>> c.parent is c
True
>>> c.lst is lst
True
>>> c.d is d
True
>>> d is d['b']
True
>>> lst[2] is d
True
>>> d['c'] is lst
True
>>> d['d'] is c
True
>>> lst[3] is c
True

==Examples with dumps==

===Example with naming and assignments==

>>> p1 = (1,2)
>>> p2 = [1,2]
>>> pyon.dumps([p1,p2,p1,p2], fast=False)
_p__0=(1,2)
_p__1=[1,2]
[_p__0,_p__1,_p__0,_p__1]
>>> pyon.dumps([p1,p2,p1,p2], fast=False, p1=p1,p2=p2)
p1=(1,2)
p2=[1,2]
[p1,p2,p1,p2]

===Example with recursive list===

>>> lst = ['foo']
>>> lst.append(lst)
>>> pyon.dumps(lst, fast=False)
_p__0=['foo',_p__0]
_p__0
>>> pyon.dumps(lst, fast=False, lst=lst)
lst=['foo',lst]
lst

===Example with recursive dict===

>>> d = {'a':'foo'}
>>> d['b'] = d
>>> pyon.dumps(d, fast=False)
_p__0={'a':'foo', 'b':_p__0}
_p__0
>>> pyon.dumps(d, fast=False, d=d)
d={'a':'foo', 'b':d}
d

===Example with recursion in class instance==

class C(object):
    def __reduce__(self):
        return C, (), self.__dict__

>>> c= C()
>>> c.parent = c
>>> pyon.dumps(c, fast=False)
_p__0=C(parent=_p__0)
_p__0
>>> pyon.dumps(c, fast=False, c=c)
c=C(parent=c)
c

===Example with cross-refernce===

class C(object):
    def __reduce__(self):
        return C, (), self.__dict__

>>> lst = ['foo']
>>> lst.append(lst)
>>> d = {'a':'bar','b':lst}
>>> d['c'] = d
>>> c = C()
>>> c.lst = lst
>>> c.d = d
>>> c.parent = c
>>> d['d'] = c
>>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)
lst=['foo',lst]
_p__1=C(lst=lst,d=d,parent=_p__1)
d={'a':'bar','c':d,'b':lst,'d':_p__1}
[lst,d,_p__1]

Best regards,
Zaur


From arnodel at googlemail.com  Wed Nov  5 11:57:24 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Wed, 5 Nov 2008 10:57:24 +0000
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
Message-ID: <9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>

On 05/11/2008, Zaur Shibzoukhov <szport at gmail.com> wrote:
> I have added support for naming objects in dumps,  cross-references
> and declarative support in dumps/loads too.

This is great stuff!

> I can't now commit changes. This night I will commit changes to
> sources and update project pages.
>
> Here are examples of how it works now:
[...]
> >>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)

How about changing the syntax slightly so that the given names are all
in a dictionary:

>>> pyon.dumps([lst, d, c], fast=False, given={'lst':lst, 'd':d})
(or one could use given=dict(lst=lst, d=d))

This would have two advantages:

* eliminate the rist of keyword argument name collision
* one could put all the 'given' objects in a dictionary and then
'pickle' expressions as needed using this method.  Later pyon.loads
could be passed this dictionary so that the objects can be unpickled
correctly.

I think this idea is good as it would make it possible to pickle some
objects that contain unpicklable objects just by declaring them as
'given'.


Also, what happens with types? E.g.

>>> pyon.dumps([int, float, str])

I think it would be good if typenames were considered literals (like
numbers and strings) so that the above returns '[int, float, str]'
(and the same for user-defined types maybe).

-- 
Arnaud


From szport at gmail.com  Wed Nov  5 12:25:58 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Wed, 5 Nov 2008 14:25:58 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
Message-ID: <e2a7590811050325q24a2a441qfd96856cabb6b88c@mail.gmail.com>

2008/11/5 Arnaud Delobelle wrote:
> (or one could use given=dict(lst=lst, d=d))
>
> This would have two advantages:
>
> * eliminate the rist of keyword argument name collision
> * one could put all the 'given' objects in a dictionary and then
> 'pickle' expressions as needed using this method.  Later pyon.loads
> could be passed this dictionary so that the objects can be unpickled
> correctly.
>
> I think this idea is good as it would make it possible to pickle some
> objects that contain unpicklable objects just by declaring them as
> 'given'.
>
I think it's reasonable. I will change the interface.

> Also, what happens with types? E.g.
>
>>>> pyon.dumps([int, float, str])
>
> I think it would be good if typenames were considered literals (like
> numbers and strings) so that the above returns '[int, float, str]'
> (and the same for user-defined types maybe).
Yes, pyon can dump types too.
One note: default rule for name resolving uses
sys._getframe(1).f_globals and sys._getframe(1).f_locals. But you can
change name resolver writing you own.

For example:
>>> class C(object): pass
...
>>> pyon.loads("[int,bool,float,C]")
[<class 'int'>, <class 'bool'>, <class 'float'>, <class '__main__.C'>]

>>> pyon.dumps([int,bool,float,C])
'[int,bool,float,C]'

Best regards,
Zaur


From bruce at leapyear.org  Wed Nov  5 15:25:05 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Wed, 5 Nov 2008 06:25:05 -0800
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
Message-ID: <cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>

I've been following this discussion and it seems like implementation is way
ahead of design. I'm looking at the syntax below and seeing it has no
advantage over text pickle format to me. Sure it's a bit more readable,
but as it stands, this is really only going to be useful for
python-python operations and the existing pickle formats do that fine.
Why would we need another one-off markup language?
All that you've said so far about Yaml was "I didn't yet made
comparison with yaml. I should do that too. Now I can only say that
yaml is much complicated notation (IMHO)."
In fact, I think a subset of Yaml is all that is necessary for this, just as
Json is (now) a subset of Yaml. My suggestion is that Json < Pyon < Yaml is
a good goal.
I agree Yaml is complicated and the docs don't help as much as they could
with too much emphasis on syntax and not enough on semantics. However, Yaml
has already addressed issues like typing and defining objects to be reused.
I'm not a Yaml expert so I may have gotten some of the following wrong, but
it should be enough to give a general idea:

[int, float, str]
==
[!type int, !type float, !type str]
or maybe
 [!py!type int, !py!type float, !py!type str]


and

_p__0=(1,2)
_p__1=[1,2]
[_p__0,_p__1,_p__0,_p__1]

==

[&_p__0 !tuple [1,2],  &_p__1 [1,2], *_p__0, *_p__1]

or

- &_p__0 (1,2)
- &_p__1 [1,2]
- *_p__0
- *_p__1


and

lst=['foo',lst]
_p__1=C(lst=lst,d=d,parent=_p__1)
d={'a':'bar','c':d,'b':lst,'d':_p__1}
[lst,d,_p__1]

==?

[&lst ['foo', *lst]], &d{'a','bar','c':*d,'b':*lst,'d':&_p__1 !!C {lst:
*lst, d: *d, parent: *_p__1}}]

or in a multi-line format:

- &lst ['foo, *lst]
- &d
    'a': 'bar'
    'c': *d
    'b': *lst
    'd': &_p__1 !!C
        lst: *lst
        d: *d
        parent: *_p__1


The only thing I see missing from Yaml is forward references which might be
nice for producing more readable output in some cases but I don't think is
technically necessary.

--- Bruce



On Wed, Nov 5, 2008 at 2:57 AM, Arnaud Delobelle <arnodel at googlemail.com>wrote:

> On 05/11/2008, Zaur Shibzoukhov <szport at gmail.com> wrote:
> > I have added support for naming objects in dumps,  cross-references
> > and declarative support in dumps/loads too.
>
> This is great stuff!
>
> > I can't now commit changes. This night I will commit changes to
> > sources and update project pages.
> >
> > Here are examples of how it works now:
> [...]
> > >>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)
>
> How about changing the syntax slightly so that the given names are all
> in a dictionary:
>
> >>> pyon.dumps([lst, d, c], fast=False, given={'lst':lst, 'd':d})
> (or one could use given=dict(lst=lst, d=d))
>
> This would have two advantages:
>
> * eliminate the rist of keyword argument name collision
> * one could put all the 'given' objects in a dictionary and then
> 'pickle' expressions as needed using this method.  Later pyon.loads
> could be passed this dictionary so that the objects can be unpickled
> correctly.
>
> I think this idea is good as it would make it possible to pickle some
> objects that contain unpicklable objects just by declaring them as
> 'given'.


<snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081105/11f53caa/attachment.html>

From szport at gmail.com  Wed Nov  5 16:01:17 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Wed, 5 Nov 2008 18:01:17 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
Message-ID: <e2a7590811050701o5d570fc1i405c951fccdf454e@mail.gmail.com>

I think main difference between JSON, PyON and YAML is that both JSON
and PyON are notations, YAML is markup language.
I consider PyON as an extension of JSON that better reflects python
object model such as JSON reflects Javascript object model.

If object has no cycles or cross-references then it's representation is clear.
In other cases representation similar to "object equation".

Best regards,
Zaur

2008/11/5 Bruce Leban <bruce at leapyear.org>:
> I've been following this discussion and it seems like implementation is way
> ahead of design. I'm looking at the syntax below and seeing it has no
> advantage over text pickle format to me. Sure it's a bit more readable,
> but as it stands, this is really only going to be useful for python-python operations and the existing pickle formats do that fine.
> Why would we need another one-off markup language?
> All that you've said so far about Yaml was "I didn't yet made comparison with yaml. I should do that too. Now I can only say that yaml is much complicated notation (IMHO)."
> In fact, I think a subset of Yaml is all that is necessary for this, just as
> Json is (now) a subset of Yaml. My suggestion is that Json < Pyon < Yaml is
> a good goal.
> I agree Yaml is complicated and the docs don't help as much as they could
> with too much emphasis on syntax and not enough on semantics. However, Yaml
> has already addressed issues like typing and defining objects to be reused.
> I'm not a Yaml expert so I may have gotten some of the following wrong, but
> it should be enough to give a general idea:
>
> [int, float, str]
> ==
> [!type int, !type float, !type str]
> or maybe
>  [!py!type int, !py!type float, !py!type str]
>
> and
>
> _p__0=(1,2)
> _p__1=[1,2]
> [_p__0,_p__1,_p__0,_p__1]
>
> ==
>
> [&_p__0 !tuple [1,2],  &_p__1 [1,2], *_p__0, *_p__1]
>
> or
>
> - &_p__0 (1,2)
> - &_p__1 [1,2]
> - *_p__0
> - *_p__1
>
>
> and
>
> lst=['foo',lst]
> _p__1=C(lst=lst,d=d,parent=_p__1)
> d={'a':'bar','c':d,'b':lst,'d':_p__1}
> [lst,d,_p__1]
>
> ==?
>
> [&lst ['foo', *lst]], &d{'a','bar','c':*d,'b':*lst,'d':&_p__1 !!C {lst:
> *lst, d: *d, parent: *_p__1}}]
>
> or in a multi-line format:
>
> - &lst ['foo, *lst]
> - &d
>     'a': 'bar'
>     'c': *d
>     'b': *lst
>     'd': &_p__1 !!C
>         lst: *lst
>         d: *d
>         parent: *_p__1
>
> The only thing I see missing from Yaml is forward references which might be
> nice for producing more readable output in some cases but I don't think is
> technically necessary.
>
> --- Bruce
>
>
> On Wed, Nov 5, 2008 at 2:57 AM, Arnaud Delobelle <arnodel at googlemail.com>
> wrote:
>>
>> On 05/11/2008, Zaur Shibzoukhov <szport at gmail.com> wrote:
>> > I have added support for naming objects in dumps,  cross-references
>> > and declarative support in dumps/loads too.
>>
>> This is great stuff!
>>
>> > I can't now commit changes. This night I will commit changes to
>> > sources and update project pages.
>> >
>> > Here are examples of how it works now:
>> [...]
>> > >>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)
>>
>> How about changing the syntax slightly so that the given names are all
>> in a dictionary:
>>
>> >>> pyon.dumps([lst, d, c], fast=False, given={'lst':lst, 'd':d})
>> (or one could use given=dict(lst=lst, d=d))
>>
>> This would have two advantages:
>>
>> * eliminate the rist of keyword argument name collision
>> * one could put all the 'given' objects in a dictionary and then
>> 'pickle' expressions as needed using this method.  Later pyon.loads
>> could be passed this dictionary so that the objects can be unpickled
>> correctly.
>>
>> I think this idea is good as it would make it possible to pickle some
>> objects that contain unpicklable objects just by declaring them as
>> 'given'.
>
> <snip>


From josiah.carlson at gmail.com  Wed Nov  5 18:45:57 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Wed, 5 Nov 2008 09:45:57 -0800
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
Message-ID: <e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>

Has anyone in this discussion used either Yaml or Json?  I've used
both.  And I much prefer Json.  The libraries to encode and decode in
most languages worth mentioning are *very* fast (comparable to
cPickle).  Yaml...not so much.  Never mind that Yaml has some ugly
bits that make it's use as a configuration language (which isn't
uncommon) have some very unpleasant gotchas.

Adding *yet another* Python-centric serialization language seems more
than a little silly to me; it seems like a waste of time.  Of course
you are free to develop this method as you see fit, but don't be
surprised if you bring it to python-dev and they say, "no."

 - Josiah

On Wed, Nov 5, 2008 at 6:25 AM, Bruce Leban <bruce at leapyear.org> wrote:
> I've been following this discussion and it seems like implementation is way
> ahead of design. I'm looking at the syntax below and seeing it has no
> advantage over text pickle format to me. Sure it's a bit more readable,
> but as it stands, this is really only going to be useful for python-python operations and the existing pickle formats do that fine.
> Why would we need another one-off markup language?
> All that you've said so far about Yaml was "I didn't yet made comparison with yaml. I should do that too. Now I can only say that yaml is much complicated notation (IMHO)."
> In fact, I think a subset of Yaml is all that is necessary for this, just as
> Json is (now) a subset of Yaml. My suggestion is that Json < Pyon < Yaml is
> a good goal.
> I agree Yaml is complicated and the docs don't help as much as they could
> with too much emphasis on syntax and not enough on semantics. However, Yaml
> has already addressed issues like typing and defining objects to be reused.
> I'm not a Yaml expert so I may have gotten some of the following wrong, but
> it should be enough to give a general idea:
>
> [int, float, str]
> ==
> [!type int, !type float, !type str]
> or maybe
>  [!py!type int, !py!type float, !py!type str]
>
> and
>
> _p__0=(1,2)
> _p__1=[1,2]
> [_p__0,_p__1,_p__0,_p__1]
>
> ==
>
> [&_p__0 !tuple [1,2],  &_p__1 [1,2], *_p__0, *_p__1]
>
> or
>
> - &_p__0 (1,2)
> - &_p__1 [1,2]
> - *_p__0
> - *_p__1
>
>
> and
>
> lst=['foo',lst]
> _p__1=C(lst=lst,d=d,parent=_p__1)
> d={'a':'bar','c':d,'b':lst,'d':_p__1}
> [lst,d,_p__1]
>
> ==?
>
> [&lst ['foo', *lst]], &d{'a','bar','c':*d,'b':*lst,'d':&_p__1 !!C {lst:
> *lst, d: *d, parent: *_p__1}}]
>
> or in a multi-line format:
>
> - &lst ['foo, *lst]
> - &d
>     'a': 'bar'
>     'c': *d
>     'b': *lst
>     'd': &_p__1 !!C
>         lst: *lst
>         d: *d
>         parent: *_p__1
>
> The only thing I see missing from Yaml is forward references which might be
> nice for producing more readable output in some cases but I don't think is
> technically necessary.
>
> --- Bruce
>
>
> On Wed, Nov 5, 2008 at 2:57 AM, Arnaud Delobelle <arnodel at googlemail.com>
> wrote:
>>
>> On 05/11/2008, Zaur Shibzoukhov <szport at gmail.com> wrote:
>> > I have added support for naming objects in dumps,  cross-references
>> > and declarative support in dumps/loads too.
>>
>> This is great stuff!
>>
>> > I can't now commit changes. This night I will commit changes to
>> > sources and update project pages.
>> >
>> > Here are examples of how it works now:
>> [...]
>> > >>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d)
>>
>> How about changing the syntax slightly so that the given names are all
>> in a dictionary:
>>
>> >>> pyon.dumps([lst, d, c], fast=False, given={'lst':lst, 'd':d})
>> (or one could use given=dict(lst=lst, d=d))
>>
>> This would have two advantages:
>>
>> * eliminate the rist of keyword argument name collision
>> * one could put all the 'given' objects in a dictionary and then
>> 'pickle' expressions as needed using this method.  Later pyon.loads
>> could be passed this dictionary so that the objects can be unpickled
>> correctly.
>>
>> I think this idea is good as it would make it possible to pickle some
>> objects that contain unpicklable objects just by declaring them as
>> 'given'.
>
> <snip>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>


From szport at gmail.com  Wed Nov  5 20:10:33 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Wed, 5 Nov 2008 22:10:33 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
Message-ID: <e2a7590811051110x6a7219b0obdb126a333468064@mail.gmail.com>

2008/11/5 Josiah Carlson <josiah.carlson at gmail.com>:
> Adding *yet another* Python-centric serialization language seems more
> than a little silly to me; it seems like a waste of time.  Of course
> you are free to develop this method as you see fit, but don't be
> surprised if you bring it to python-dev and they say, "no."
PyON is just that-born. The PyON concept and it's implementation is at
an early stage.
Therefore, it too early offer python-dev.

Personally I don't consider PyON as another serialization language. I
would like to see it as literal object notation based on python
syntax. Currently, this is not possible, because it is necessary to
expand the syntax of the python language. I don't expect this soon.

At this stage PyON uses the existing syntax of python language for the
human readable/writeble literal representation of objects.
I hope that one day someone will propose to expand the syntax of the
language and introduce literal notation for objects representation
embedded into python language.

Best regards,
Zaur


From josiah.carlson at gmail.com  Wed Nov  5 22:44:45 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Wed, 5 Nov 2008 13:44:45 -0800
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e2a7590811051110x6a7219b0obdb126a333468064@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
	<e2a7590811051110x6a7219b0obdb126a333468064@mail.gmail.com>
Message-ID: <e6511dbf0811051344s226b4a54o5253d08213f7644e@mail.gmail.com>

On Wed, Nov 5, 2008 at 11:10 AM, Zaur Shibzoukhov <szport at gmail.com> wrote:
> 2008/11/5 Josiah Carlson <josiah.carlson at gmail.com>:
>> Adding *yet another* Python-centric serialization language seems more
>> than a little silly to me; it seems like a waste of time.  Of course
>> you are free to develop this method as you see fit, but don't be
>> surprised if you bring it to python-dev and they say, "no."
> PyON is just that-born. The PyON concept and it's implementation is at
> an early stage.
> Therefore, it too early offer python-dev.
>
> Personally I don't consider PyON as another serialization language. I
> would like to see it as literal object notation based on python
> syntax. Currently, this is not possible, because it is necessary to
> expand the syntax of the python language. I don't expect this soon.
>
> At this stage PyON uses the existing syntax of python language for the
> human readable/writeble literal representation of objects.
> I hope that one day someone will propose to expand the syntax of the
> language and introduce literal notation for objects representation
> embedded into python language.

Python already has a literal syntax for describing objects in-line in
the language.  It's the syntax itself, and repr(obj) (given proper
__repr__ methods) can give you everything you need, except for
recursive and multi-referenced objects.

I guess I really don't understand the purpose of PyON.  Syntactically
it doesn't fit between json and yaml.  It supports features that are
more useful for a serialization language for RPC, etc., rather than
configuration/inlining.  And it doesn't really offer a reverse of
representation -> object without going through the standard Python
parser and executing the result (which has security implications).

Again, json is very human readable/writable, is very close to literal
Python syntax, and already has support in just about every language
worth discussing (and Python offers a json loading module in the
standard library).  Can you give me a good reason why someone would
want to choose PyON over json in 6 months?

 - Josiah


From szport at gmail.com  Thu Nov  6 09:08:33 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Thu, 6 Nov 2008 11:08:33 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e6511dbf0811051344s226b4a54o5253d08213f7644e@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
	<e2a7590811051110x6a7219b0obdb126a333468064@mail.gmail.com>
	<e6511dbf0811051344s226b4a54o5253d08213f7644e@mail.gmail.com>
Message-ID: <e2a7590811060008u11d090e0xafd25f3fffa9d3bc@mail.gmail.com>

2008/11/6 Josiah Carlson <josiah.carlson at gmail.com>:

> I guess I really don't understand the purpose of PyON.  Syntactically
> it doesn't fit between json and yaml.  It supports features that are
> more useful for a serialization language for RPC, etc., rather than
> configuration/inlining.  And it doesn't really offer a reverse of
> representation -> object without going through the standard Python
> parser and executing the result (which has security implications).
PyON dosn't use exec in order to reconstruct obbject.
It uses python parser for constructing AST and then builds object
using pickle-like protocol from AST.
I guess PyON could be used as standard reconstructable representation
of python objects.


> Again, json is very human readable/writable, is very close to literal
> Python syntax, and already has support in just about every language
> worth discussing (and Python offers a json loading module in the
> standard library).  Can you give me a good reason why someone would
> want to choose PyON over json in 6 months?
If someone need standard way for reconstructable representation
of almost every python object based on python syntax then PyON is a
possible choice (probably in near future).
Also maybe in the future someone will offer better solution for
reconstructable representation of
python objects based on python syntax.

Also I do not think that PyON should be used instead of JSON.

Best regards,
Zaur


From george.sakkis at gmail.com  Thu Nov  6 21:31:11 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 6 Nov 2008 15:31:11 -0500
Subject: [Python-ideas] __missing__ object/keyword
Message-ID: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>

Several times I find myself using the following idiom:

_Missing = object()   # sentinel

def foo(x, y=_Missing):
   if y is _Missing:
     do_this
   else:
     do_that

The reason for using a "private" sentinel is that any python object,
including None, might be a valid argument. Another option is using
*args or **kwds instead of y but that obfuscates unnecessarily the
function signature.

It would be nice if a new object or keyword, say __missing__, was
introduced as a canonical way to address this common scenario.
Specifically, the only valid usages of __missing__ would be:
1. As a default argument in a callable.
2. In identity tests: <var> is __missing__
Anything else would raise either a SyntaxError (e.g. `x =
__missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
__missing__). Only the interpreter could assign __missing__ to a name
when binding objects to formal parameters.

If this was to be accepted, a further generalization could be to allow
the `var is __missing__` expression even if `var` is not a formal
parameter. This would be equivalent to:

try: var
except NameError: expr = True
else: expr = False

Thoughts ?

George


From grosser.meister.morti at gmx.net  Thu Nov  6 21:39:59 2008
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Thu, 06 Nov 2008 21:39:59 +0100
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <4913561F.7090004@gmx.net>

Why not doing this?

def foo(x, y=None):
   if y is None:
     do_this
   else:
     do_that

George Sakkis schrieb:
> Several times I find myself using the following idiom:
> 
> _Missing = object()   # sentinel
> 
> def foo(x, y=_Missing):
>    if y is _Missing:
>      do_this
>    else:
>      do_that
> 
> The reason for using a "private" sentinel is that any python object,
> including None, might be a valid argument. Another option is using
> *args or **kwds instead of y but that obfuscates unnecessarily the
> function signature.
> 
> It would be nice if a new object or keyword, say __missing__, was
> introduced as a canonical way to address this common scenario.
> Specifically, the only valid usages of __missing__ would be:
> 1. As a default argument in a callable.
> 2. In identity tests: <var> is __missing__
> Anything else would raise either a SyntaxError (e.g. `x =
> __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
> __missing__). Only the interpreter could assign __missing__ to a name
> when binding objects to formal parameters.
> 
> If this was to be accepted, a further generalization could be to allow
> the `var is __missing__` expression even if `var` is not a formal
> parameter. This would be equivalent to:
> 
> try: var
> except NameError: expr = True
> else: expr = False
> 
> Thoughts ?
> 
> George
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
> 



From cvrebert at gmail.com  Thu Nov  6 21:43:27 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Thu, 6 Nov 2008 12:43:27 -0800
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <47c890dc0811061243k3302a386vd1762292696924d3@mail.gmail.com>

On Thu, Nov 6, 2008 at 12:31 PM, George Sakkis <george.sakkis at gmail.com> wrote:
> Several times I find myself using the following idiom:
>
> _Missing = object()   # sentinel
>
> def foo(x, y=_Missing):
>   if y is _Missing:
>     do_this
>   else:
>     do_that
>
> The reason for using a "private" sentinel is that any python object,
> including None, might be a valid argument. Another option is using
> *args or **kwds instead of y but that obfuscates unnecessarily the
> function signature.
>
> It would be nice if a new object or keyword, say __missing__, was
> introduced as a canonical way to address this common scenario.
> Specifically, the only valid usages of __missing__ would be:
> 1. As a default argument in a callable.
> 2. In identity tests: <var> is __missing__
> Anything else would raise either a SyntaxError (e.g. `x =
> __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
> __missing__). Only the interpreter could assign __missing__ to a name
> when binding objects to formal parameters.
>
> If this was to be accepted, a further generalization could be to allow
> the `var is __missing__` expression even if `var` is not a formal
> parameter. This would be equivalent to:
>
> try: var
> except NameError: expr = True
> else: expr = False
>
> Thoughts ?

By analogy with the necessity of __missing__ when we already have
None, what if I have something that calls foo() and I want __missing__
to be a valid argument? The problem is that an infinite series of
higher-level None-like objects is necessary.
Is the one extra line to define `sentinel` really so bad?

Cheers,
Chris
-- 
Follow the path of the Iguana...
http://rebertia.com

>
> George
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From veloso at verylowsodium.com  Thu Nov  6 21:47:33 2008
From: veloso at verylowsodium.com (Greg Falcon)
Date: Thu, 6 Nov 2008 15:47:33 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <3cdcefb80811061247k6ac0bd56u5540464f9e99252a@mail.gmail.com>

On Thu, Nov 6, 2008 at 3:31 PM, George Sakkis <george.sakkis at gmail.com> wrote:
> Several times I find myself using the following idiom:
>
> _Missing = object()   # sentinel
>
> def foo(x, y=_Missing):
>   if y is _Missing:
>     do_this
>   else:
>     do_that

> It would be nice if a new object or keyword, say __missing__, was
> introduced as a canonical way to address this common scenario.

> Thoughts ?

This has been proposed and shot down before:

http://mail.python.org/pipermail/python-dev/2007-May/073439.html

The older proposal didn't give __missing__ the special run-time and
compile-time error behaviors, but this actually just makes things
worse.  Why complicate the language merely to save a single idiomatic
line of code dealing with a relatively infrequent use-case?

Greg F


From george.sakkis at gmail.com  Thu Nov  6 21:59:49 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 6 Nov 2008 15:59:49 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <47c890dc0811061243k3302a386vd1762292696924d3@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<47c890dc0811061243k3302a386vd1762292696924d3@mail.gmail.com>
Message-ID: <91ad5bf80811061259j314564b5iafab3045d43ca818@mail.gmail.com>

On Thu, Nov 6, 2008 at 3:43 PM, Chris Rebert <cvrebert at gmail.com> wrote:

On Thu, Nov 6, 2008 at 12:31 PM, George Sakkis <george.sakkis at gmail.com>
> wrote:
> > Several times I find myself using the following idiom:
> >
> > _Missing = object()   # sentinel
> >
> > def foo(x, y=_Missing):
> >   if y is _Missing:
> >     do_this
> >   else:
> >     do_that
> >
> > The reason for using a "private" sentinel is that any python object,
> > including None, might be a valid argument. Another option is using
> > *args or **kwds instead of y but that obfuscates unnecessarily the
> > function signature.
> >
> > It would be nice if a new object or keyword, say __missing__, was
> > introduced as a canonical way to address this common scenario.
> > Specifically, the only valid usages of __missing__ would be:
> > 1. As a default argument in a callable.
> > 2. In identity tests: <var> is __missing__
> > Anything else would raise either a SyntaxError (e.g. `x =
> > __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
> > __missing__). Only the interpreter could assign __missing__ to a name
> > when binding objects to formal parameters.
> >
> > If this was to be accepted, a further generalization could be to allow
> > the `var is __missing__` expression even if `var` is not a formal
> > parameter. This would be equivalent to:
> >
> > try: var
> > except NameError: expr = True
> > else: expr = False
> >
> > Thoughts ?
>
> By analogy with the necessity of __missing__ when we already have
> None, what if I have something that calls foo() and I want __missing__
> to be a valid argument?


You won't be able to; by definition __missing__ cannot be a valid argument.

>
> Is the one extra line to define `sentinel` really so bad?


Certainly it's not a showstopper by any means, but it's more than one extra
line. If __missing__ is a regular object, a client may "cheat" by passing it
explicitly. It can also help introspection and documentation tools (e.g.
epydoc) and IDEs.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081106/6ca8288a/attachment.html>

From george.sakkis at gmail.com  Thu Nov  6 22:15:49 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 6 Nov 2008 16:15:49 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <3cdcefb80811061247k6ac0bd56u5540464f9e99252a@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<3cdcefb80811061247k6ac0bd56u5540464f9e99252a@mail.gmail.com>
Message-ID: <91ad5bf80811061315i37152459mff93b4fd66dd130e@mail.gmail.com>

On Thu, Nov 6, 2008 at 3:47 PM, Greg Falcon <veloso at verylowsodium.com>wrote:

On Thu, Nov 6, 2008 at 3:31 PM, George Sakkis <george.sakkis at gmail.com>
> wrote:
> > Several times I find myself using the following idiom:
> >
> > _Missing = object()   # sentinel
> >
> > def foo(x, y=_Missing):
> >   if y is _Missing:
> >     do_this
> >   else:
> >     do_that
>
> > It would be nice if a new object or keyword, say __missing__, was
> > introduced as a canonical way to address this common scenario.
>
> > Thoughts ?
>
> This has been proposed and shot down before:
>
> http://mail.python.org/pipermail/python-dev/2007-May/073439.html
>
> The older proposal didn't give __missing__ the special run-time and
> compile-time error behaviors,


I agree that it doesn't make sense without special compile/runtime behavior;
that would be like adding a second None.


> but this actually just makes things
> worse. Why complicate the language merely to save a single idiomatic
> line of code dealing with a relatively infrequent use-case?


I can't tell how much it would complicate the implementation of the language
but the semantics are pretty straightforward. But you have a point there,
None is more often than not an adequare sentinel, so if implementing
__missing__ requires significant work it's probably not worth the effort.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081106/f5f7033d/attachment.html>

From python at rcn.com  Thu Nov  6 22:18:58 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 6 Nov 2008 13:18:58 -0800
Subject: [Python-ideas] __missing__ object/keyword
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <1A17A67ED0D2482297A1F3A688ECE2C6@RaymondLaptop1>

From: "George Sakkis" <george.sakkis at gmail.com>
> It would be nice if a new object or keyword, say __missing__, was
> introduced as a canonical way to address this common scenario.
> Specifically, the only valid usages of __missing__ would be:
> 1. As a default argument in a callable.
> 2. In identity tests: <var> is __missing__
> Anything else would raise either a SyntaxError (e.g. `x =
> __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
> __missing__). Only the interpreter could assign __missing__ to a name
> when binding objects to formal parameters.

It would be nice to not introduce a new language feature for every
minor programming idiom.  IMO, growing the language with more
special cases does not make it easier to learn and use.


Raymond



From arnodel at googlemail.com  Thu Nov  6 22:59:05 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Thu, 6 Nov 2008 21:59:05 +0000
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <04710CC8-48DA-4875-87BE-F9DB62866234@googlemail.com>


On 6 Nov 2008, at 20:31, George Sakkis wrote:

> Several times I find myself using the following idiom:
>
> _Missing = object()   # sentinel
>
> def foo(x, y=_Missing):
>   if y is _Missing:
>     do_this
>   else:
>     do_that
>
> The reason for using a "private" sentinel is that any python object,
> including None, might be a valid argument. Another option is using
> *args or **kwds instead of y but that obfuscates unnecessarily the
> function signature.
>
> It would be nice if a new object or keyword, say __missing__, was
> introduced as a canonical way to address this common scenario.
> Specifically, the only valid usages of __missing__ would be:
> 1. As a default argument in a callable.
> 2. In identity tests: <var> is __missing__
> Anything else would raise either a SyntaxError (e.g. `x =
> __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is
> __missing__). Only the interpreter could assign __missing__ to a name
> when binding objects to formal parameters.
>
> If this was to be accepted, a further generalization could be to allow
> the `var is __missing__` expression even if `var` is not a formal
> parameter. This would be equivalent to:
>
> try: var
> except NameError: expr = True
> else: expr = False
>
> Thoughts ?

Here's a proof-of-concept decorator version:

from inspect import getargspec

def tell_missing(f):
     argnames = getargspec(f)[0][1:]
     def decorated(*args, **kwargs):
         missing = set(argnames[len(args):]) - set(kwargs)
         return f(missing, *args, **kwargs)
     return decorated

 >>> @tell_missing
... def f(missing, x, y=None, z=None):
...     print "Missing arguments:", ', '.join(missing)
...
 >>> f(1, 2, 3)
Missing arguments:
 >>> f(1, 2)
Missing arguments: z
 >>> f(1)
Missing arguments: y, z

-- 
Arnaud



From szport at gmail.com  Fri Nov  7 06:27:09 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Fri, 7 Nov 2008 08:27:09 +0300
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e6511dbf0811061710p1e66021cg9f90cf3ae0a83049@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
	<e2a7590811051110x6a7219b0obdb126a333468064@mail.gmail.com>
	<e6511dbf0811051344s226b4a54o5253d08213f7644e@mail.gmail.com>
	<e2a7590811060008u11d090e0xafd25f3fffa9d3bc@mail.gmail.com>
	<e6511dbf0811061710p1e66021cg9f90cf3ae0a83049@mail.gmail.com>
Message-ID: <e2a7590811062127l292943bake6195e9a154fc886@mail.gmail.com>

I am sure that it is now too early to draw conclusions about PyON.

Best regards,
Zaur

2008/11/7 Josiah Carlson <josiah.carlson at gmail.com>:
> On Thu, Nov 6, 2008 at 12:08 AM, Zaur Shibzoukhov <szport at gmail.com> wrote:
>> 2008/11/6 Josiah Carlson <josiah.carlson at gmail.com>:
>>
>>> I guess I really don't understand the purpose of PyON.  Syntactically
>>> it doesn't fit between json and yaml.  It supports features that are
>>> more useful for a serialization language for RPC, etc., rather than
>>> configuration/inlining.  And it doesn't really offer a reverse of
>>> representation -> object without going through the standard Python
>>> parser and executing the result (which has security implications).
>> PyON dosn't use exec in order to reconstruct obbject.
>> It uses python parser for constructing AST and then builds object
>> using pickle-like protocol from AST.
>> I guess PyON could be used as standard reconstructable representation
>> of python objects.
>
> Then that strictly limits it to Python.  No other language can make
> use of it.  And in that sense, we may as well use pickle (which is
> fast, already exists, supports recursive object definitions, as well
> as arbitrary Python objects).
>
>>> Again, json is very human readable/writable, is very close to literal
>>> Python syntax, and already has support in just about every language
>>> worth discussing (and Python offers a json loading module in the
>>> standard library).  Can you give me a good reason why someone would
>>> want to choose PyON over json in 6 months?
>> If someone need standard way for reconstructable representation
>> of almost every python object based on python syntax then PyON is a
>> possible choice (probably in near future).
>> Also maybe in the future someone will offer better solution for
>> reconstructable representation of
>> python objects based on python syntax.
>>
>> Also I do not think that PyON should be used instead of JSON.
>
> Limiting yourself to Python syntax for something that really isn't
> human readable (in particular recursive structures and arbitrary
> object serialization) doesn't make a lot of sense.  It's like limiting
> yourself to a 3rd grade vocabulary level for a doctoral dissertation
> because you think that 3rd graders might want to read it some day.
> People don't really read object representations.  And when they do,
> it's because the representations are configuration files, in which
> self-references are a *really* bad idea.
>
> If you want a pure-python representation (rather than json), look at
> 'unrepr'; it uses the Python parser, and by default only supports
> standard data structures.  It can be extended to support arbitrary
> classes with standard instantiation methods.
>
>  - Josiah
>



-- 
? ?????????,
???????? ?.?.

From jan.kanis at phil.uu.nl  Fri Nov  7 12:54:21 2008
From: jan.kanis at phil.uu.nl (Jan Kanis)
Date: Fri, 7 Nov 2008 12:54:21 +0100
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
Message-ID: <59a221a0811070354l1de778c1ieb1c1f652654b2e7@mail.gmail.com>

On 05/11/2008, Josiah Carlson <josiah.carlson at gmail.com> wrote:
> Has anyone in this discussion used either Yaml or Json?  I've used
> both.  And I much prefer Json.  The libraries to encode and decode in
> most languages worth mentioning are *very* fast (comparable to
> cPickle).  Yaml...not so much.  Never mind that Yaml has some ugly
> bits that make it's use as a configuration language (which isn't
> uncommon) have some very unpleasant gotchas.

Josiah,

A bit OT, but I'm wondering, what kind of unpleasant gotchas are we
talking about? I've used YAML a very little bit, but it looked very
interesting to me. Could you give a pointer to what unpleasantness to
expect?

Jan


From josiah.carlson at gmail.com  Fri Nov  7 22:59:35 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Fri, 7 Nov 2008 13:59:35 -0800
Subject: [Python-ideas] Python Object Notation (PyON)
In-Reply-To: <59a221a0811070354l1de778c1ieb1c1f652654b2e7@mail.gmail.com>
References: <e2a7590811050016u29189753yc8204e332177bab4@mail.gmail.com>
	<9bfc700a0811050257p6e723c3fw86b1eb04c0436ec1@mail.gmail.com>
	<cf5b87740811050625t59c5d26fxe70a8c22e116b249@mail.gmail.com>
	<e6511dbf0811050945v18968c0epbff12b62d62e3c2b@mail.gmail.com>
	<59a221a0811070354l1de778c1ieb1c1f652654b2e7@mail.gmail.com>
Message-ID: <e6511dbf0811071359j5c85c533y7dd4f339202d5217@mail.gmail.com>

I ran into some empty string issues, some binary string issues, and
I've heard from Guido that he's had some issues with empty lists.
These are all trivial cases in json.

I also don't know how yaml handles unicode data, but I do know that a
good json library will have no issues with unicode.

 - Josiah

On Fri, Nov 7, 2008 at 3:54 AM, Jan Kanis <jan.kanis at phil.uu.nl> wrote:
> On 05/11/2008, Josiah Carlson <josiah.carlson at gmail.com> wrote:
>> Has anyone in this discussion used either Yaml or Json?  I've used
>> both.  And I much prefer Json.  The libraries to encode and decode in
>> most languages worth mentioning are *very* fast (comparable to
>> cPickle).  Yaml...not so much.  Never mind that Yaml has some ugly
>> bits that make it's use as a configuration language (which isn't
>> uncommon) have some very unpleasant gotchas.
>
> Josiah,
>
> A bit OT, but I'm wondering, what kind of unpleasant gotchas are we
> talking about? I've used YAML a very little bit, but it looked very
> interesting to me. Could you give a pointer to what unpleasantness to
> expect?
>
> Jan
>


From bruce at leapyear.org  Sat Nov  8 06:37:06 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Fri, 7 Nov 2008 21:37:06 -0800
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>

The problem with using a value like None as some have proposed is that None
may be a valid parameter value. Thus the only safe value is a special value
like a throwaway object. There are numerous problems with this including
that it's not safe: I might not check for the missing value in some place
and end up passing the throwaway object to another function which then
passes it as one of the optional values.
There *is* one guaranteed way of ensuring that I can't use a variable's
value: leaving it unbound. That is, to support this, we would add a new
syntax something like what George proposed with slightly different
semantics:

  def foo(x, y=__unbound__):

where if y is omitted from the call, then y is unbound. This is slightly
different than what would happen if y were left out of the parameter list as
in that case, y could reference a global of the same name. In this case, y
can only reference an unbound local.

No other changes are required to use this. If I don't check whether or not y
is bound, then I'll get a NameError when I try to use it, just as with any
other unbound variable.

If this proposal were to be seriously considered, there are of course
alternative syntaxes that could be considered, like using missing,
__missing__ or def foo(x, ?y) but that's getting ahead.

I agree it would be nice to have a way to check whether a variable is
unbound without writing a multi-line try/except, but I think that can be
discussed as a different issue.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081107/ecd3a36c/attachment.html>

From fuzzyman at gmail.com  Sat Nov  8 12:36:29 2008
From: fuzzyman at gmail.com (Michael)
Date: Sat, 8 Nov 2008 11:36:29 +0000
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
Message-ID: <EA4644A8-F41B-42B8-8EF9-F58567AA7729@gmail.com>

This seems to be a solution in search of a problem. If you handle  
sentinel default values early in a function then they are rarely  
problematic.

Michael Foord

http://www.ironpythoninaction.com

On 8 Nov 2008, at 05:37, "Bruce Leban" <bruce at leapyear.org> wrote:

> The problem with using a value like None as some have proposed is  
> that None may be a valid parameter value. Thus the only safe value  
> is a special value like a throwaway object. There are numerous  
> problems with this including that it's not safe: I might not check  
> for the missing value in some place and end up passing the throwaway  
> object to another function which then passes it as one of the  
> optional values.
>
> There *is* one guaranteed way of ensuring that I can't use a  
> variable's value: leaving it unbound. That is, to support this, we  
> would add a new syntax something like what George proposed with  
> slightly different semantics:
>
>   def foo(x, y=__unbound__):
>
> where if y is omitted from the call, then y is unbound. This is  
> slightly different than what would happen if y were left out of the  
> parameter list as in that case, y could reference a global of the  
> same name. In this case, y can only reference an unbound local.
>
> No other changes are required to use this. If I don't check whether  
> or not y is bound, then I'll get a NameError when I try to use it,  
> just as with any other unbound variable.
>
> If this proposal were to be seriously considered, there are of  
> course alternative syntaxes that could be considered, like using  
> missing, __missing__ or def foo(x, ?y) but that's getting ahead.
>
> I agree it would be nice to have a way to check whether a variable  
> is unbound without writing a multi-line try/except, but I think that  
> can be discussed as a different issue.
>
> --- Bruce
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas


From jimjjewett at gmail.com  Sat Nov  8 18:15:33 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sat, 8 Nov 2008 12:15:33 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
Message-ID: <fb6fbf560811080915n6f83e84dpb7ab46e4c4e89f3a@mail.gmail.com>

On Thu, Nov 6, 2008 at 3:31 PM, George Sakkis <george.sakkis at gmail.com> wrote:
> Several times I find myself using the following idiom:

> _Missing = object()   # sentinel

> def foo(x, y=_Missing):
>   if y is _Missing:
>     do_this
>   else:
>     do_that

And I often catch myself trying to write

    def foo(x, y=object()):
        if y is ... # oops, I need to define the y *outside* the function.

But once I've defined it outside the function, it gets tempting to
reuse it for something else, such as another method in the same class
with a similar need.  And eventually, it may end up getting promoted
to a real object, like None...

I'll freely grant that this is a small use case, but ... it is one I
would appreciate seeing handled better.

> Specifically, the only valid usages of __missing__ would be:
> 1. As a default argument in a callable.
> 2. In identity tests: <var> is __missing__

I assume you could also write

2a.  var is not __missing__

> If this was to be accepted, a further generalization could be to
> allow the `var is __missing__` expression even if `var` is not a
> formal parameter. This would be equivalent to:

> try: var
> except NameError: expr = True
> else: expr = False

I wouldn't do this, at least at first.  I see now that it is
effectively a way of checking for run-time parameters added to
builtins, which can be used to control imports, etc.  But that wasn't
obvious as first.

-jJ


From george.sakkis at gmail.com  Sat Nov  8 20:36:26 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Sat, 8 Nov 2008 14:36:26 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <EA4644A8-F41B-42B8-8EF9-F58567AA7729@gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
	<EA4644A8-F41B-42B8-8EF9-F58567AA7729@gmail.com>
Message-ID: <91ad5bf80811081136v1c7d789eh6d310c4a7a839066@mail.gmail.com>

On Sat, Nov 8, 2008 at 6:36 AM, Michael <fuzzyman at gmail.com> wrote:

This seems to be a solution in search of a problem. If you handle sentinel
> default values early in a function then they are rarely problematic.


The general consensus so far seems to be that None and sentinel values are
good enough in practice and adding a new feature is over-engineering, but I
wouldn't go as far as calling it a solution in search of problem. To me it
looks similar to the motivation for keyword-only arguments; as the PEP
mentions, one can effectively have keyword-only arguments with the idiom:

def compare(a, b, *ignore, key=None):
    if ignore:  # If ignore is not empty
        raise TypeError

Thankfully, this didn't prevent the PEP from being accepted.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081108/42784959/attachment.html>

From george.sakkis at gmail.com  Sat Nov  8 20:53:00 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Sat, 8 Nov 2008 14:53:00 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
Message-ID: <91ad5bf80811081153ve7beb7bx7fce52645548f0fd@mail.gmail.com>

On Sat, Nov 8, 2008 at 12:37 AM, Bruce Leban <bruce at leapyear.org> wrote:

There *is* one guaranteed way of ensuring that I can't use a variable's
> value: leaving it unbound. That is, to support this, we would add a new
> syntax something like what George proposed with slightly different
> semantics:
>
>   def foo(x, y=__unbound__):
>
> where if y is omitted from the call, then y is unbound. This is slightly
> different than what would happen if y were left out of the parameter list as
> in that case, y could reference a global of the same name. In this case, y
> can only reference an unbound local.
>
> No other changes are required to use this. If I don't check whether or not
> y is bound, then I'll get a NameError when I try to use it, just as with any
> other unbound variable.
>

I like that, it's more straightforward than checking for identity with a
__missing__ pseudo-object. if this was to be accepted, checking whether a
name is bound would be more common than now, so it might be worthwhile
considering a new isbound('var') builtin as a more explicit (and perhaps
faster) alternative of "if 'var' in locals()".

If this proposal were to be seriously considered, there are of course
> alternative syntaxes that could be considered, like using missing,
> __missing__ or def foo(x, ?y) but that's getting ahead.
>

+1 for the alternative syntax, reads much better and it's at least as
intuitive as *args and **kwds.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081108/f2a177fb/attachment.html>

From tjreedy at udel.edu  Sat Nov  8 21:05:36 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 08 Nov 2008 15:05:36 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <fb6fbf560811080915n6f83e84dpb7ab46e4c4e89f3a@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<fb6fbf560811080915n6f83e84dpb7ab46e4c4e89f3a@mail.gmail.com>
Message-ID: <gf4re8$vrc$1@ger.gmane.org>

Jim Jewett wrote:
> On Thu, Nov 6, 2008 at 3:31 PM, George Sakkis <george.sakkis at gmail.com> wrote:
>> Several times I find myself using the following idiom:
> 
>> _Missing = object()   # sentinel
> 
>> def foo(x, y=_Missing):
>>   if y is _Missing:
>>     do_this
>>   else:
>>     do_that
> 
> And I often catch myself trying to write
> 
>     def foo(x, y=object()):
>         if y is ... # oops, I need to define the y *outside* the function.

if type(y) is object: ...

And no, there is no problem if a foolish caller passes an object(), 
because such has no meaning other than what your sentinal y means.



From tjreedy at udel.edu  Sat Nov  8 21:19:50 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 08 Nov 2008 15:19:50 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
Message-ID: <gf4s8v$2m0$1@ger.gmane.org>

Bruce Leban wrote:
> The problem with using a value like None as some have proposed is that 
> None may be a valid parameter value.

It usually is not, and when it is, a private object suffices.


> Thus the only safe value is a 
> special value like a throwaway object.

Yes, a private instance of object().

> There *is* one guaranteed way of ensuring that I can't use a variable's 
> value: leaving it unbound.

This Perl, etc. concept does not fit Python's name-object model.  A 
Python mappings and sequences cannot have a key or index without a 
value.  To propose otherwise is a major conceptual change.

tjr



From bruce at leapyear.org  Sat Nov  8 22:20:24 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Sat, 8 Nov 2008 13:20:24 -0800
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <gf4s8v$2m0$1@ger.gmane.org>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
	<gf4s8v$2m0$1@ger.gmane.org>
Message-ID: <cf5b87740811081320r3ae613fdgd66f977260913b47@mail.gmail.com>

On Sat, Nov 8, 2008 at 12:19 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> Bruce Leban wrote:
>
>>
>>  There *is* one guaranteed way of ensuring that I can't use a variable's
>> value: leaving it unbound.
>>
>
> This Perl, etc. concept does not fit Python's name-object model.  A Python
> mappings and sequences cannot have a key or index without a value.  To
> propose otherwise is a major conceptual change.
>
> tjr
>

What I would expect (as a programmer) is that when the parameter is omitted,
the variable is simply not bound and therefore it's omitted from the
mapping, not added to the mapping with a special magic value meaning
unbound.

However, there is an implementation complication due to the way variable
scoping works in Python: if a variable is left unbound in the function
locals, then references to that variable name would pick up the global if it
exists which would definitely be a surprising result. So I agree that there
would definitely be some complexities to implement this.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081108/7809a469/attachment.html>

From greg.ewing at canterbury.ac.nz  Sat Nov  8 23:06:11 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 09 Nov 2008 11:06:11 +1300
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <cf5b87740811081320r3ae613fdgd66f977260913b47@mail.gmail.com>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
	<gf4s8v$2m0$1@ger.gmane.org>
	<cf5b87740811081320r3ae613fdgd66f977260913b47@mail.gmail.com>
Message-ID: <49160D53.8050205@canterbury.ac.nz>

Bruce Leban wrote:

> However, there is an implementation complication due to the way variable 
> scoping works in Python: if a variable is left unbound in the function 
> locals, then references to that variable name would pick up the global 
> if it exists

No, it wouldn't:

Python 2.3 (#1, Aug  5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def f():
...  print x
...  x = 0
...
 >>> f()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

Python already has the machinery to make this work. All
that's needed is a way to leave parameters unbound, and
a syntax for asking "Would I get a NameError if I were to
refer to this name now?"

Perhaps something like

   def f(x?):
     if x?:
       ...

-- 
Greg


From leif.walsh at gmail.com  Sun Nov  9 00:21:59 2008
From: leif.walsh at gmail.com (Leif Walsh)
Date: Sat, 8 Nov 2008 18:21:59 -0500
Subject: [Python-ideas] __missing__ object/keyword
In-Reply-To: <49160D53.8050205@canterbury.ac.nz>
References: <91ad5bf80811061231v22cee2e8j35af45a3e3bf1209@mail.gmail.com>
	<cf5b87740811072137w382d615dh53cbd526d1fcb01f@mail.gmail.com>
	<gf4s8v$2m0$1@ger.gmane.org>
	<cf5b87740811081320r3ae613fdgd66f977260913b47@mail.gmail.com>
	<49160D53.8050205@canterbury.ac.nz>
Message-ID: <cc7430500811081521j5d5a873cp9e2a9aa69efb4eb0@mail.gmail.com>

On Sat, Nov 8, 2008 at 5:06 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Python already has the machinery to make this work. All
> that's needed is a way to leave parameters unbound, and
> a syntax for asking "Would I get a NameError if I were to
> refer to this name now?"

Well, there's always

def Foo(*args, **kwargs):
  try:
    x = kwargs['x']
  except KeyError, unused_e:
    x = default_x

-- 
Cheers,
Leif


From carl at carlsensei.com  Mon Nov 10 03:56:55 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Sun, 9 Nov 2008 16:56:55 -1000
Subject: [Python-ideas] Proposal for Ruby-style anonymous block functions
	(that don't kill the indention)
Message-ID: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>

This list had a proposal last month to make everything an expression,  
and it has not infrequent attempts to create multi-line lambdas, and I  
think the reason for this is that people want a better way to create  
functions that act like Ruby-style blocks since sometimes it makes  
more sense to write the function that will be passed after the thing  
it will be passed to and not before. So, here's my proposal. I expect  
it to get rejected, but hey, someone approved @decorator, so maybe it  
will make it...

Instead of

 >>> def decorator(f):
...     def inner(*args, **kwargs):
...         print(*args, **kwargs)
...         return f(*args, **kwargs)
...     return inner
...

where the def inner comes before you know what it's going to be used  
for, why not

 >>> def decorator(f):
...     return @(*args, **kwargs):
...         print(*args, **kwargs)
...         return f(*args, **kwargs)
...

? Here's it's very straightforward that what you're doing is returning  
an anonymous function, and then you find out what's in the function.  
Similarly,

 >>> words = ["blah one", "Blah two", " bLAh three"]
 >>> sorted(words, key=@(word)):
...     word = word.lower()
...     word = word.replace("one", "1")
...     word = word.replace("two", "2")
...     word = word.replace("three", "3")
...     word = word.replace(" ", "")
...     return word
...
[u'blah one', u'Blah two', u' bLAh three']

Which will be equivalent to:

 >>> words = ["blah one", "Blah two", " bLAh three"]
 >>> def key(word):
...     word = word.lower()
...     word = word.replace("one", "1")
...     word = word.replace("two", "2")
...     word = word.replace("three", "3")
...     word = word.replace(" ", "")
...     return word
...
 >>> sorted(words, key=key)
[u'blah one', u'Blah two', u' bLAh three']

Again, I think it's clear here to be told first, "Oh, we're going to  
sort something" and then learn how the sorting will be done than it is  
to read a weird function and only after that learn what it's for.

Caveats: This shouldn't be allowed to work with two @s in one line. If  
you have two of them, you should give them names ahead of time with  
def. This also should not be allowed work inside a for-, if-, with-,  
or while- statement's initial expression, since the indenting won't  
work out. Also, myfunc = @(args) should be preemptively banned, since  
def is the one right way to do it. Also you shouldn't be allowed to do  
this to make one liners with this (as you can eg. with if-statements),  
since that's why there's lambda. And using this on the declaration  
line of a decorator is just crazy.

Of course, for all I know, Python's grammar is too simple to make this  
work with all the caveats, but if it's not, I think this might be a  
good way to improve readability without killing the indention-based  
nature of Python that we all know and love.

My other thought is that if @ is deemed to be too "Perl-ish" of line  
noise, def could be used as the keyword instead. Or perhaps a new  
keyword like "block" or something. That said, I think there is a good  
analogy here to the existing @-decorator where things are, strictly  
speaking, written out of order so that the readability is improved and  
the function that follows is given as an argument to the initial @ line.

Thoughts?

-- Carl


From leif.walsh at gmail.com  Mon Nov 10 07:59:20 2008
From: leif.walsh at gmail.com (Leif Walsh)
Date: Mon, 10 Nov 2008 01:59:20 -0500
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
	functions (that don't kill the indention)
In-Reply-To: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
Message-ID: <cc7430500811092259m3b362a0aue135d3289f103af5@mail.gmail.com>

On Sun, Nov 9, 2008 at 9:56 PM, Carl Johnson <carl at carlsensei.com> wrote:
>>>> words = ["blah one", "Blah two", " bLAh three"]
>>>> sorted(words, key=@(word)):
> ...     word = word.lower()
> ...     word = word.replace("one", "1")
> ...     word = word.replace("two", "2")
> ...     word = word.replace("three", "3")
> ...     word = word.replace(" ", "")
> ...     return word
> ...
> [u'blah one', u'Blah two', u' bLAh three']

This bothers me.  You seem to have some kind of syntax error here,
because you have two parens before the colon.  I don't know if you
meant to do this, but it seems very, very strange the way you have it,
and the obvious alternative seems strange as well:

>>> sorted(words, key=@(word):
...   word = word.lower()
...   ...
...   return word)
...
[stuff]

Since I can't think of a reasonable way to fix this, I'm going to have to -1 it.

Also, I think in the light that lambda functions are just hard to work
with in general (as seductive as they are when you're typing), I'd
rather encourage people to formally specify any functions they are
going to use, if only to give them a chance to be tested (Hey look,
I'm promoting TDD!  How out of character!).

-- 
Cheers,
Leif


From carl at carlsensei.com  Mon Nov 10 09:07:01 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Sun, 9 Nov 2008 22:07:01 -1000
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
	functions (that don't kill the indention)
In-Reply-To: <cc7430500811092259m3b362a0aue135d3289f103af5@mail.gmail.com>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<cc7430500811092259m3b362a0aue135d3289f103af5@mail.gmail.com>
Message-ID: <E05BBBE4-87BF-4118-A80A-86068C45E5BB@carlsensei.com>

> This bothers me.  You seem to have some kind of syntax error here,
> because you have two parens before the colon.  I don't know if you
> meant to do this, but it seems very, very strange the way you have it,
> and the obvious alternative seems strange as well:

No, the "extra" parenthesis is intentional. The original expression  
must terminate before the block begins. Not having the parenthesis  
there would mean that it needs to be added to end of the block, but  
then it wouldn't be the indentation that controls the block but the  
parenthesis, and that's unpythonic. The original idea I had was to  
have a special keyword for "variable which I will define on the next  
line, just wait a minute please" but then I simplified it down to @ on  
analogy to decorators. Still, some people might like the original idea  
more:

 >>> words = ["blah one", "Blah two", " bLAh three"]
 >>> sorted(words, key=DEFERRED)
 >>> def DEFERRED(word):
...     word = word.lower()
...     word = word.replace("one", "1")
...     word = word.replace("two", "2")
...     word = word.replace("three", "3")
...     word = word.replace(" ", "")
...     return word
...
[u'blah one', u'Blah two', u' bLAh three']

And then we just have to fight about what would be a good keyword or  
symbol for "deferred."


From carl at carlsensei.com  Mon Nov 10 09:18:09 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Sun, 9 Nov 2008 22:18:09 -1000
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
	functions (that don't kill the indention)
In-Reply-To: <20081110011512.0503f6e6@bhuda.mired.org>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<20081110011512.0503f6e6@bhuda.mired.org>
Message-ID: <8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>


On 2008/11/09, at 8:15 pm, Mike Meyer wrote:

> On Sun, 9 Nov 2008 16:56:55 -1000
> Carl Johnson <carl at carlsensei.com> wrote:
>
>> This list had a proposal last month to make everything an expression,
>> and it has not infrequent attempts to create multi-line lambdas,  
>> and I
>> think the reason for this is that people want a better way to create
>> functions that act like Ruby-style blocks since sometimes it makes
>> more sense to write the function that will be passed after the thing
>> it will be passed to and not before. So, here's my proposal. I expect
>> it to get rejected, but hey, someone approved @decorator, so maybe it
>> will make it...
>
> I think you may be on to something. You've identified the real cause
> of the reasons this kind of thing generates ugly code, and attempted
> to deal with them. But it needs some tweaking.
>
>> Instead of
>>
>>>>> def decorator(f):
>> ...     def inner(*args, **kwargs):
>> ...         print(*args, **kwargs)
>> ...         return f(*args, **kwargs)
>> ...     return inner
>> ...
>>
>> where the def inner comes before you know what it's going to be used
>> for, why not
>>
>>>>> def decorator(f):
>> ...     return @(*args, **kwargs):
>> ...         print(*args, **kwargs)
>> ...         return f(*args, **kwargs)
>> ...
>
> You seem to have realized *part* of the problem, and attempt to deal
> with it here:
>
>> Caveats: This shouldn't be allowed to work with two @s in one line.  
>> If
>> you have two of them, you should give them names ahead of time with
>> def. This also should not be allowed work inside a for-, if-, with-,
>> or while- statement's initial expression, since the indenting won't
>> work out.
>
> Yup, this makes lots of sense, and would seem to eliminate some simple
> ugly cases. But it doesn't deal with the real ugliness that comes with
> multiple things in a statement. This would look like a godsend to
> creating properties, where you need three functions that could all be
> anonymous, like so:
>
>   class Ugly(object):
>        x = property(@(self):
> 	    return self._x
> 	, @(self, value):
> 	    self._x = value
> 	, @(self), "I'm the x property"):
> 	   del self._x
>
> Except that that's the simple case, and it border on unreadable all by
> itself.
>
> Maybe @() shouldn't be allowed except for the last line in a
> multi-line statement?

Properties have already been fixed in Python 2.6+ as far as I'm  
concerned, but I don't think that should be a valid use of the @, even  
without my caveats, since it's mixing blocks around inside an  
expression. The expression should be terminated before the beginning  
of the block.

>> Also, myfunc = @(args) should be preemptively banned, since
>> def is the one right way to do it. Also you shouldn't be allowed to  
>> do
>> this to make one liners with this (as you can eg. with if- 
>> statements),
>> since that's why there's lambda.
>
> I disagree with both of these, mostly on symmetry grounds. I can
> already do:
>
>    lowerfunc = lamba word: word.lower()
>
> why should this nifty new construct not be allowed to play? Similarly,
> every statement that is followed by a block can be followed by a
> simple statement, or a list of simple statements separated by
> semicolons. Why is this one different?

Mostly on grounds of TWOOTDI. I know people already consider "x =  
lambda:" to be poor style, so I want to ban bad style preemptively  
with @.

Incidentally, does anyone know why for decorators,

@lambda x: x
def f(): pass

is a syntax error? I guess people just don't want lambda based  
decorators, for whatever reason.

> In particular, this fixes one of the properties of lambda's that
> people complain about most often: the inability to put statements in
> them. Why provide that win, only to basically make it worthless by
> forcing people it to use multiple statements? I mean, this:
>
>  newlist = sorted(words, key=lambda word, print word; word.lower())
>
> would be great, but isn't allowed because lambda is restricted to an
> expression. You fix it by giving us:
>
>  newlist = sorted(words, @(word)): print word; return word.lower()
>
> only to turn around and day "No, this block is special, and you can't
> do that here."????

I think it would look better on four lines. Maybe I'm wrong, but  
that's my intuition.


>> And using this on the declaration line of a decorator is just crazy.
>
> Why? One of the most powerful languages I know of came about because
> the designers let people do "crazy" things. Sure, using a @( construct
> for the decorator expression is sort of pointless, but what if you
> want to pass an anonymous function to a decorator. Why is:
>
>    @magicdecorator(lambda word, word.lower())
>    def function(...
>
> ok, but:
>
>    @advancedmagicdecorator(@(word)):
>        return word.lower()
>    def function(...
>
> not ok?

Ah, to be honest, I hadn't thought it through and just assumed it was  
impossible to make it work, since there would be two things needing  
indent-dedent tokens in a row. Still, isn't it a little ugly? (And  
remember, this proposal is not about adding power to Python, just  
making things more readable.)

> I kinda like it, if you can figure out how to deal with things like
> property. On the other hand, it smells a lot like lambda, which some
> people would like removed from the language...

Agreed. I fully expect the BDFL to reject this proposal, but I still  
think it's interesting to consider as a "solution" to the insolvable  
problem of multiline anonymous functions.

>    <mike
> -- 
> Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more  
> information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>



From george.sakkis at gmail.com  Mon Nov 10 17:46:49 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Mon, 10 Nov 2008 11:46:49 -0500
Subject: [Python-ideas] Smallest/Largest singletons
Message-ID: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>

One small side-effect of not being able to compare incompatible types in 3.0
is that None cannot be used any more as the smallest element. Yes this has
always been an implementation artifact and a hack, but it was very
convenient none the less. Is it maybe the right time to add a builtin
Smallest (and also Largest) object, i.e. two singletons so that `Smallest <
x` for every x: x is not Smallest and `Largest > x` for every x: x is not
Largest ? Although it's not hard to define them in pure Python and one could
object with "not every n-liner needs to be a builtin", the main added value
is that these will be endorsed as the standard, otherwise we risk
mymodule.Smallest clashing with with yourmodule.Smallest.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081110/4d760513/attachment.html>

From jan.kanis at phil.uu.nl  Thu Nov 13 18:53:15 2008
From: jan.kanis at phil.uu.nl (Jan Kanis)
Date: Thu, 13 Nov 2008 18:53:15 +0100
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
	functions (that don't kill the indention)
In-Reply-To: <8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<20081110011512.0503f6e6@bhuda.mired.org>
	<8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>
Message-ID: <59a221a0811130953v1b2090f4v5e36fde3207f133c@mail.gmail.com>

I actually like the idea. Having an @ in a statement turns that
statement grammatically into the start of a block construct. But I
prefer the easier way of allowing lambda x: print x; return x*x kind
of syntax (which may require brackets around the lambda to
disambiguate the semicolons), and that doesn't look like it's going to
make it any time soon.

I also agree with not liking something like myfunc = @(args): ..., but
I don't think the grammar should be complicated with more special
cases than necessary. Leave this to the style guide.

One major technical problem with this is that it would stop the python
grammar from being LL1, and I think Guido wants to keep it like that.
In fact, I'm not quite sure this grammar is still context free (but I
think it still barely is...)

Jan


From greg.ewing at canterbury.ac.nz  Fri Nov 14 05:22:42 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 14 Nov 2008 17:22:42 +1300
Subject: [Python-ideas] Proposal for Ruby-style anonymous
 block	functions (that don't kill the indention)
In-Reply-To: <59a221a0811130953v1b2090f4v5e36fde3207f133c@mail.gmail.com>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<20081110011512.0503f6e6@bhuda.mired.org>
	<8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>
	<59a221a0811130953v1b2090f4v5e36fde3207f133c@mail.gmail.com>
Message-ID: <491CFD12.7050503@canterbury.ac.nz>

Jan Kanis wrote:
> One major technical problem with this is that it would stop the python
> grammar from being LL1

Not necessarily. You could just allow any expression-statement
to be followed by a block, and sort out whether it makes sense
later on.

-- 
Greg


From scott+python-ideas at scottdial.com  Fri Nov 14 08:25:42 2008
From: scott+python-ideas at scottdial.com (Scott Dial)
Date: Fri, 14 Nov 2008 02:25:42 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
Message-ID: <491D27F6.4070609@scottdial.com>

George Sakkis wrote:
> One small side-effect of not being able to compare incompatible types in
> 3.0 is that None cannot be used any more as the smallest element. Yes
> this has always been an implementation artifact and a hack, but it was
> very convenient none the less. Is it maybe the right time to add a
> builtin Smallest (and also Largest) object, i.e. two singletons so that
> `Smallest < x` for every x: x is not Smallest and `Largest > x` for
> every x: x is not Largest ? Although it's not hard to define them in
> pure Python and one could object with "not every n-liner needs to be a
> builtin", the main added value is that these will be endorsed as the
> standard, otherwise we risk mymodule.Smallest clashing with with
> yourmodule.Smallest.
> 

You can more-or-less take all of the replies to the thread about a
blessed "__missing__" object and apply them to "Smallest"/"Largest".
Using special objects to be lazy with your algorithm will never be wise.
Eventually, someone will use them to mean something else entirely. It's
almost always better to avoid using special objects or to roll-your-own
(so that nobody can use it unexpectedly). Furthermore, preloading an
output value with a nonsense value like "Smallest" or "Largest" is just
asking for it to get leaked accidentally (the same problem exists with
preloading None).

-1 Let's not provide features for misguided programming idioms.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu


From jan.kanis at phil.uu.nl  Fri Nov 14 15:09:11 2008
From: jan.kanis at phil.uu.nl (Jan Kanis)
Date: Fri, 14 Nov 2008 15:09:11 +0100
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
	functions (that don't kill the indention)
In-Reply-To: <491CFD12.7050503@canterbury.ac.nz>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<20081110011512.0503f6e6@bhuda.mired.org>
	<8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>
	<59a221a0811130953v1b2090f4v5e36fde3207f133c@mail.gmail.com>
	<491CFD12.7050503@canterbury.ac.nz>
Message-ID: <59a221a0811140609l77cad394ide05f9091dd84ba6@mail.gmail.com>

On 14/11/2008, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Jan Kanis wrote:
>> One major technical problem with this is that it would stop the python
>> grammar from being LL1
>
> Not necessarily. You could just allow any expression-statement
> to be followed by a block, and sort out whether it makes sense
> later on.

Hm, hadn't thought about it in that way. Doing so now, if we follow
this train of thought to it's ultimate conclusion everything is LL1,
just parse the file as a sequence of characters and sort out whether
they make sense later on :) .

Jan


From greg.ewing at canterbury.ac.nz  Sat Nov 15 00:54:10 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 15 Nov 2008 12:54:10 +1300
Subject: [Python-ideas] Proposal for Ruby-style anonymous block
 functions (that don't kill the indention)
In-Reply-To: <59a221a0811140609l77cad394ide05f9091dd84ba6@mail.gmail.com>
References: <8CAA56E4-08DB-4514-BB9B-5FD4F7C202F8@carlsensei.com>
	<20081110011512.0503f6e6@bhuda.mired.org>
	<8B10C797-BC27-49AE-92B3-4368BEBAB5BF@carlsensei.com>
	<59a221a0811130953v1b2090f4v5e36fde3207f133c@mail.gmail.com>
	<491CFD12.7050503@canterbury.ac.nz>
	<59a221a0811140609l77cad394ide05f9091dd84ba6@mail.gmail.com>
Message-ID: <491E0FA2.60609@canterbury.ac.nz>

Jan Kanis wrote:
> if we follow
> this train of thought to it's ultimate conclusion everything is LL1,
> just parse the file as a sequence of characters and sort out whether
> they make sense later on :) .

You're right that this is a possible implementation strategy,
but it doesn't mean that "everything is LL(1)".

Being LL(1) or not is a property of the grammar, and it concerns
the language that the *parser* accepts. The Python language
itself is actually not LL(1). CPython gets away with using
an LL(1) parser because the parser accepts a slightly
different language that's a superset of Python, and *that*
language is LL(1) (meaning that you can write down an LL(1)
grammar for it).

This is the strategy used by almost all practical language
implementations, and usually the division of labour is
arranged so that the parser does most of the hard work of
weeding out invalid programs.

In the case you suggest, you've gone to the extreme of making
the parser do almost none of the work, and although the
language the parser accepts is LL(1), it's a wildly different
one from the language the system as a whole accepts.

So when we talk somewhat loosely about a language such as
Python being LL(1), what we mean is that there is a superset,
which isn't *too* much bigger, that's LL(1), and we make
our parser recognize that superset.

-- 
Greg


From skip at pobox.com  Sat Nov 15 01:15:59 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 14 Nov 2008 18:15:59 -0600
Subject: [Python-ideas] Suggestion for 2.7/3.[01] - sys.isinteractive()
Message-ID: <18718.5311.771896.153235@montanaro-dyndns-org.local>


We have a special exception handling hook written for the application
platform we developed at work.  Mostly it makes sure any exceptions raised
get their tracebacks logged before going belly up.  But it also makes sure
the program does go belly up.

When using bits of this platform in an interactive session it can be
annoying (to say the least) for the interpreter to exit when you make a
spelling error.  Consequently I wanted something like:

    if we are not running interactively:
        sys.excepthook = exception_handler

The only problem was to decide what the proper python-speak was for "we are
not running interactively".  It seemed to me that sys.argv[0] was the empty
string when running interactively but that seemed fragile so I decided to
ask on comp.lang.python.  Peter Otten responded with

    hasattr(sys, "ps1")

and a link to the sys module doc section where the presence of sys.ps1 only
in interacive mode is documented.

So now I know the proper spelling in python-speak, but that seems like a
very non-obvious way to do that (and a bit fragile since it's possible, if
not exactly reasonable to "del sys.ps1".  It seems to me that it would be
preferable if sys had an "interactive" attribute or an "isinteractive"
method.  Maybe in 2.7 and 3.0 or 3.1?  Am I way off base?  I realize that
would present two ways to do it, but in my mind one would be obvious, the
other not.

Thx,

Skip


From lists at cheimes.de  Sat Nov 15 02:05:07 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 15 Nov 2008 02:05:07 +0100
Subject: [Python-ideas] Suggestion for 2.7/3.[01] - sys.isinteractive()
In-Reply-To: <18718.5311.771896.153235@montanaro-dyndns-org.local>
References: <18718.5311.771896.153235@montanaro-dyndns-org.local>
Message-ID: <gfl782$geh$1@ger.gmane.org>

skip at pobox.com wrote:
> So now I know the proper spelling in python-speak, but that seems like a
> very non-obvious way to do that (and a bit fragile since it's possible, if
> not exactly reasonable to "del sys.ps1".  It seems to me that it would be
> preferable if sys had an "interactive" attribute or an "isinteractive"
> method.  Maybe in 2.7 and 3.0 or 3.1?  Am I way off base?  I realize that
> would present two ways to do it, but in my mind one would be obvious, the
> other not.

+1 from me, skip!

Christian



From josiah.carlson at gmail.com  Sun Nov 16 23:33:40 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Sun, 16 Nov 2008 14:33:40 -0800
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <491D27F6.4070609@scottdial.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
	<491D27F6.4070609@scottdial.com>
Message-ID: <e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>

On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial
<scott+python-ideas at scottdial.com> wrote:
> George Sakkis wrote:
>> One small side-effect of not being able to compare incompatible types in
>> 3.0 is that None cannot be used any more as the smallest element. Yes
>> this has always been an implementation artifact and a hack, but it was
>> very convenient none the less. Is it maybe the right time to add a
>> builtin Smallest (and also Largest) object, i.e. two singletons so that
>> `Smallest < x` for every x: x is not Smallest and `Largest > x` for
>> every x: x is not Largest ? Although it's not hard to define them in
>> pure Python and one could object with "not every n-liner needs to be a
>> builtin", the main added value is that these will be endorsed as the
>> standard, otherwise we risk mymodule.Smallest clashing with with
>> yourmodule.Smallest.
>>
>
> You can more-or-less take all of the replies to the thread about a
> blessed "__missing__" object and apply them to "Smallest"/"Largest".
> Using special objects to be lazy with your algorithm will never be wise.
> Eventually, someone will use them to mean something else entirely. It's
> almost always better to avoid using special objects or to roll-your-own
> (so that nobody can use it unexpectedly). Furthermore, preloading an
> output value with a nonsense value like "Smallest" or "Largest" is just
> asking for it to get leaked accidentally (the same problem exists with
> preloading None).
>
> -1 Let's not provide features for misguided programming idioms.

See PEP 326.  Unless additional motivations are presented, I'm going
to have to be -1 as well (despite 326 being my PEP).

 - Josiah


From george.sakkis at gmail.com  Mon Nov 17 02:21:50 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Sun, 16 Nov 2008 20:21:50 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
	<491D27F6.4070609@scottdial.com>
	<e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
Message-ID: <91ad5bf80811161721t1803f20eyfcb7bbfc7291d1e8@mail.gmail.com>

On Sun, Nov 16, 2008 at 5:33 PM, Josiah Carlson <josiah.carlson at gmail.com>wrote:

On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial
> <scott+python-ideas at scottdial.com <scott%2Bpython-ideas at scottdial.com>>
> wrote:
> > George Sakkis wrote:
> >> One small side-effect of not being able to compare incompatible types in
> >> 3.0 is that None cannot be used any more as the smallest element. Yes
> >> this has always been an implementation artifact and a hack, but it was
> >> very convenient none the less. Is it maybe the right time to add a
> >> builtin Smallest (and also Largest) object, i.e. two singletons so that
> >> `Smallest < x` for every x: x is not Smallest and `Largest > x` for
> >> every x: x is not Largest ? Although it's not hard to define them in
> >> pure Python and one could object with "not every n-liner needs to be a
> >> builtin", the main added value is that these will be endorsed as the
> >> standard, otherwise we risk mymodule.Smallest clashing with with
> >> yourmodule.Smallest.
> >>
> >
> > You can more-or-less take all of the replies to the thread about a
> > blessed "__missing__" object and apply them to "Smallest"/"Largest".
> > Using special objects to be lazy with your algorithm will never be wise.
>

s/lazy/elegant

> Eventually, someone will use them to mean something else entirely. It's
> almost always better to avoid using special objects or to roll-your-own
> (so that nobody can use it unexpectedly). Furthermore, preloading an
> output value with a nonsense value like "Smallest" or "Largest" is just
> asking for it to get leaked accidentally (the same problem exists with
> preloading None).
>
> -1 Let's not provide features for misguided programming idioms.

I don't consider Dijkstra's shortest path algorithm and the others mentioned
in PEP 326 as examples of misguided programming idioms.

See PEP 326.  Unless additional motivations are presented, I'm going
> to have to be -1 as well (despite 326 being my PEP).


The additional motivation since the PEP is that the None hack (as equivalent
to Smallest) cannot be used anymore in 3.x, and I'm sure I'm not the only
one using it. Besides, the reasons for rejection read more like a lukewarm
-0 ("not that useful, easily implemented, can't decide on a name"), not a
strong "this is silly" -1.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081116/5b4e0d03/attachment.html>

From george.sakkis at gmail.com  Mon Nov 17 02:43:27 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Sun, 16 Nov 2008 20:43:27 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
	<491D27F6.4070609@scottdial.com>
	<e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
Message-ID: <91ad5bf80811161743q75375eay5a43894d0fd64522@mail.gmail.com>

On Sun, Nov 16, 2008 at 5:33 PM, Josiah Carlson <josiah.carlson at gmail.com>wrote:

On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial
> <scott+python-ideas at scottdial.com <scott%2Bpython-ideas at scottdial.com>>
> wrote:
> > George Sakkis wrote:
> >> One small side-effect of not being able to compare incompatible types in
> >> 3.0 is that None cannot be used any more as the smallest element. Yes
> >> this has always been an implementation artifact and a hack, but it was
> >> very convenient none the less. Is it maybe the right time to add a
> >> builtin Smallest (and also Largest) object, i.e. two singletons so that
> >> `Smallest < x` for every x: x is not Smallest and `Largest > x` for
> >> every x: x is not Largest ? Although it's not hard to define them in
> >> pure Python and one could object with "not every n-liner needs to be a
> >> builtin", the main added value is that these will be endorsed as the
> >> standard, otherwise we risk mymodule.Smallest clashing with with
> >> yourmodule.Smallest.
> >>
> >
> > You can more-or-less take all of the replies to the thread about a
> > blessed "__missing__" object and apply them to "Smallest"/"Largest".
> > Using special objects to be lazy with your algorithm will never be wise.
>

s/lazy/elegant

> Eventually, someone will use them to mean something else entirely. It's
> almost always better to avoid using special objects or to roll-your-own
> (so that nobody can use it unexpectedly). Furthermore, preloading an
> output value with a nonsense value like "Smallest" or "Largest" is just
> asking for it to get leaked accidentally (the same problem exists with
> preloading None).
>
> -1 Let's not provide features for misguided programming idioms.

I don't consider Dijkstra's shortest path algorithm and the others mentioned
in PEP 326 as examples of misguided programming idioms.

See PEP 326.  Unless additional motivations are presented, I'm going
> to have to be -1 as well (despite 326 being my PEP).


The additional motivation since the PEP is that the None hack (as equivalent
to Smallest) cannot be used anymore in 3.x, and I'm sure I'm not the only
one using it. Besides, the reasons for rejection read more like a lukewarm
-0 ("not that useful, easily implemented, can't decide on a name"), not a
strong "this is silly" -1.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081116/b7a2382b/attachment.html>

From scott+python-ideas at scottdial.com  Mon Nov 17 03:21:43 2008
From: scott+python-ideas at scottdial.com (Scott Dial)
Date: Sun, 16 Nov 2008 21:21:43 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <91ad5bf80811161721t1803f20eyfcb7bbfc7291d1e8@mail.gmail.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>	<491D27F6.4070609@scottdial.com>	<e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
	<91ad5bf80811161721t1803f20eyfcb7bbfc7291d1e8@mail.gmail.com>
Message-ID: <4920D537.80803@scottdial.com>

George Sakkis wrote:
>> Using special objects to be lazy with your algorithm will never be
>> wise.
> 
> s/lazy/elegant

To each his own, but your substitution fails to convince me that magic
values are more readable than using a "valid" flag variable.

>> -1 Let's not provide features for misguided programming idioms.
> 
> I don't consider Dijkstra's shortest path algorithm and the others
> mentioned in PEP 326 as examples of misguided programming idioms.

The algorithm isn't misguided. The use of a magic constant is misguided.
Please don't confuse the language I choose. The only way it's safe is if
you if-check the output values from your algorithm, and then there is no
reason to have a special value, just use a flag. If you are not doing
the if-check, then you are using a misguided programming idiom (unless
you have proven for all possible inputs, there is a solution to your
algorithm.) While in the examples in PEP 326, it's vaguely clear that
it's not a problem. I imagine many uses that behave like this:

minval = Max
for i in vals:
    if i < minval:
        minval = i

Which is a failure of design championed by a programming idiom you want
to create. At least, if they attempt to pick some "Max" value, they will
have the opportunity to realize the mistake rather than assume "it's the
Python way". Furthermore, the PEP's examples aren't compelling because
you can roll-your-own easily if you want such a thing, and since I
consider it strictly bad to use them as output values, it makes no
difference if its a built-in or not.

> Besides, the reasons for rejection read more
> like a lukewarm -0 ("not that useful, easily implemented, can't decide

Perhaps, but I for one think it's silly.

-Scott

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu


From george.sakkis at gmail.com  Mon Nov 17 03:39:52 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Sun, 16 Nov 2008 21:39:52 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <4920D537.80803@scottdial.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
	<491D27F6.4070609@scottdial.com>
	<e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
	<91ad5bf80811161721t1803f20eyfcb7bbfc7291d1e8@mail.gmail.com>
	<4920D537.80803@scottdial.com>
Message-ID: <91ad5bf80811161839o4980e4cdva2d8627175b48fe@mail.gmail.com>

On Sun, Nov 16, 2008 at 9:21 PM, Scott Dial <
scott+python-ideas at scottdial.com <scott%2Bpython-ideas at scottdial.com>>wrote:

George Sakkis wrote:
> >> Using special objects to be lazy with your algorithm will never be
> >> wise.
> >
> > s/lazy/elegant
>
> To each his own, but your substitution fails to convince me that magic
> values are more readable than using a "valid" flag variable.


So the concept of infinity is a "magic value" and a flag variable is not ? I
bet you find C-like error codes more readable than exceptions too.

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081116/88e1ee3c/attachment.html>

From leif.walsh at gmail.com  Mon Nov 17 04:22:14 2008
From: leif.walsh at gmail.com (Leif Walsh)
Date: Sun, 16 Nov 2008 22:22:14 -0500
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <91ad5bf80811161839o4980e4cdva2d8627175b48fe@mail.gmail.com>
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
	<491D27F6.4070609@scottdial.com>
	<e6511dbf0811161433u53a2653an21ad256efb7e83e6@mail.gmail.com>
	<91ad5bf80811161721t1803f20eyfcb7bbfc7291d1e8@mail.gmail.com>
	<4920D537.80803@scottdial.com>
	<91ad5bf80811161839o4980e4cdva2d8627175b48fe@mail.gmail.com>
Message-ID: <cc7430500811161922nbe12fcew8d211462b7254d4e@mail.gmail.com>

On Sun, Nov 16, 2008 at 9:39 PM, George Sakkis <george.sakkis at gmail.com> wrote:
>> George Sakkis wrote:
>> >> Using special objects to be lazy with your algorithm will never be
>> >> wise.
>> >
>> > s/lazy/elegant
>>
>> To each his own, but your substitution fails to convince me that magic
>> values are more readable than using a "valid" flag variable.
>
> So the concept of infinity is a "magic value" and a flag variable is not ? I
> bet you find C-like error codes more readable than exceptions too.

Whoa, whoa, calm down, kids.

I'm going -1 on this, by the way.  If you come across an absolute need
for this, it's likely that you're doing something wrong, and if you
have namespace clashes, you're definitely doing something wrong.  It's
too easy to fix most of the use cases for Smallest or Largest with
None, in any case:

minval = None
for elt in lst:
  if minval is None or elt < minval:
    minval = elt

-- 
Cheers,
Leif


From grosser.meister.morti at gmx.net  Mon Nov 17 20:14:46 2008
From: grosser.meister.morti at gmx.net (=?ISO-8859-15?Q?Mathias_Panzenb=F6ck?=)
Date: Mon, 17 Nov 2008 20:14:46 +0100
Subject: [Python-ideas] Lock-File class: FileLock
Message-ID: <4921C2A6.7040100@gmx.net>

Hi.

Maybe I'm just blind and can't find it, but it seems that python has no file
based lock. I wrote one using fcntl (mscvrt on windows):

http://twoday.tuwien.ac.at/pub/stories/319462/

I think this would be a nice addition to pythons standard library.

I called the lock/unlock methods, well, lock and unlock (and there is a trylock
method, too). I just now saw the methods of threading.Lock are called acquire
and release. Shall I change the method names? (a matter of s/\<lock\>/acquire/g
s/\<unlock\>/release/g s/\<trylock\>/tryacquire/g) I will change it if it gets
included to python that way.
I like lock/unlock more, though.

	-panzi


From ezio.melotti at gmail.com  Fri Nov 21 14:49:11 2008
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 21 Nov 2008 15:49:11 +0200
Subject: [Python-ideas] A Wiki-style documentation with an approval process
Message-ID: <4926BC57.8030509@gmail.com>

As far as I know, the only way to report a typo or change something in 
the documentation is actually open an issue in the bug tracker.
This implies that:
1. If the user is not registered to the bug tracker he can't open the 
issue, and he won't probably register for a small mistake;
2. The user has to spend some time to reach the bug tracker page, open a 
new issue, write a brief description of the problem and possibly create 
and attach a patch;
3. A developer (of Python) has to read the issue, write a patch or check 
if the attached patch is ok and then apply it (even if I think that some 
developers can edit the doc directly).
In my opinion this is rather clumsy and certainly not user-friendly. 
Even if the user is registered to the bug tracker and knows how to 
report an issue (and this is already a small subset of the doc readers) 
he may not want to go through all these step just to fix a typo.

The idea is to allow all the users to edit the documentation pages 
directly (like a wiki), but wait the approval of a developer before 
apply the changes.
The steps will then be:
1. The user finds a mistake, clicks on an [edit] link and fixes it;
2. A developer check if the correction is ok and approves of refuses it.

This will also lead to the following benefits:
1. All the users can contribute even if they are not registered and/or 
they don't know how/where to report the problem;
2. The process is simpler so the users are more likely to report 
mistakes, spending less time;
3. If the process is easy enough, users may want to submit some example 
or tip that could be useful to others;
4. The developers just have to check and approve/refuse the changes. 
Again, this will require less time and they will be able to fix several 
mistakes in few minutes (if not seconds);
5. The bug tracker won't be "polluted" by issues regarding typos and 
other small mistakes in the doc.

Problems and limitations:
Even if probably there's already something like this out there, I don't 
know how easy it is to find/implement it. It shouldn't be too hard to 
write something ex-novo, but then again, someone will have to do it. 
Something like this works well for self-explanatory corrections (like 
typos), but it could not be the best when you have to explain the 
reasons of the change. Possible solutions are:
1. Allow the user to write an (optional) comment to the correction (e.g. 
"Changed xyz to match the new docstring.");
2. Open an issue where to discuss about the correction and then edit the 
page (some developers could have direct access to the page so they can 
edit them immediately -- I don't know if there's already something like 
that now or if they have to apply patches);
3. Have a "discussion page" like the the ones that are commonly used in 
wikis.

I don't know how feasible this idea is, but I'd really like to have a 
simpler way of editing the doc. It would also be nice, if the users 
could contribute actively to improve the doc, adding more exampes and 
pointing out possible pitfalls (and the developers' approval will still 
assure correctness).

--
Ezio Melotti


From ironfroggy at gmail.com  Fri Nov 21 15:07:33 2008
From: ironfroggy at gmail.com (Calvin Spealman)
Date: Fri, 21 Nov 2008 09:07:33 -0500
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <4926BC57.8030509@gmail.com>
References: <4926BC57.8030509@gmail.com>
Message-ID: <76fd5acf0811210607r7ca15f6ep311258cc7b8725d6@mail.gmail.com>

Certainly interesting, but it is important to keep some quality to
control. I think a line can be found to tread in the middle. There has
been a lot of talk about the possibility of adopting distributed
version control, and we already have mirrors in place officially and
unofficially. I could imagine such a documentation editing being
committed to branches in such a system.

I'm not completely sure there are enough changes needed to the
documentation to warrant it, however.

On Fri, Nov 21, 2008 at 8:49 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> As far as I know, the only way to report a typo or change something in the
> documentation is actually open an issue in the bug tracker.
> This implies that:
> 1. If the user is not registered to the bug tracker he can't open the issue,
> and he won't probably register for a small mistake;
> 2. The user has to spend some time to reach the bug tracker page, open a new
> issue, write a brief description of the problem and possibly create and
> attach a patch;
> 3. A developer (of Python) has to read the issue, write a patch or check if
> the attached patch is ok and then apply it (even if I think that some
> developers can edit the doc directly).
> In my opinion this is rather clumsy and certainly not user-friendly. Even if
> the user is registered to the bug tracker and knows how to report an issue
> (and this is already a small subset of the doc readers) he may not want to
> go through all these step just to fix a typo.
>
> The idea is to allow all the users to edit the documentation pages directly
> (like a wiki), but wait the approval of a developer before apply the
> changes.
> The steps will then be:
> 1. The user finds a mistake, clicks on an [edit] link and fixes it;
> 2. A developer check if the correction is ok and approves of refuses it.
>
> This will also lead to the following benefits:
> 1. All the users can contribute even if they are not registered and/or they
> don't know how/where to report the problem;
> 2. The process is simpler so the users are more likely to report mistakes,
> spending less time;
> 3. If the process is easy enough, users may want to submit some example or
> tip that could be useful to others;
> 4. The developers just have to check and approve/refuse the changes. Again,
> this will require less time and they will be able to fix several mistakes in
> few minutes (if not seconds);
> 5. The bug tracker won't be "polluted" by issues regarding typos and other
> small mistakes in the doc.
>
> Problems and limitations:
> Even if probably there's already something like this out there, I don't know
> how easy it is to find/implement it. It shouldn't be too hard to write
> something ex-novo, but then again, someone will have to do it. Something
> like this works well for self-explanatory corrections (like typos), but it
> could not be the best when you have to explain the reasons of the change.
> Possible solutions are:
> 1. Allow the user to write an (optional) comment to the correction (e.g.
> "Changed xyz to match the new docstring.");
> 2. Open an issue where to discuss about the correction and then edit the
> page (some developers could have direct access to the page so they can edit
> them immediately -- I don't know if there's already something like that now
> or if they have to apply patches);
> 3. Have a "discussion page" like the the ones that are commonly used in
> wikis.
>
> I don't know how feasible this idea is, but I'd really like to have a
> simpler way of editing the doc. It would also be nice, if the users could
> contribute actively to improve the doc, adding more exampes and pointing out
> possible pitfalls (and the developers' approval will still assure
> correctness).
>
> --
> Ezio Melotti
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy


From brett at python.org  Fri Nov 21 19:30:06 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 10:30:06 -0800
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <4926BC57.8030509@gmail.com>
References: <4926BC57.8030509@gmail.com>
Message-ID: <bbaeab100811211030t20d6c2a4q674e7a17ed275c34@mail.gmail.com>

On Fri, Nov 21, 2008 at 05:49, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> As far as I know, the only way to report a typo or change something in the
> documentation is actually open an issue in the bug tracker.
> This implies that:
> 1. If the user is not registered to the bug tracker he can't open the issue,
> and he won't probably register for a small mistake;
> 2. The user has to spend some time to reach the bug tracker page, open a new
> issue, write a brief description of the problem and possibly create and
> attach a patch;
> 3. A developer (of Python) has to read the issue, write a patch or check if
> the attached patch is ok and then apply it (even if I think that some
> developers can edit the doc directly).
> In my opinion this is rather clumsy and certainly not user-friendly. Even if
> the user is registered to the bug tracker and knows how to report an issue
> (and this is already a small subset of the doc readers) he may not want to
> go through all these step just to fix a typo.
>
> The idea is to allow all the users to edit the documentation pages directly
> (like a wiki), but wait the approval of a developer before apply the
> changes.
> The steps will then be:
> 1. The user finds a mistake, clicks on an [edit] link and fixes it;
> 2. A developer check if the correction is ok and approves of refuses it.
>

Georg can correct me if I am wrong, but I believe he has been working
on a commenting system for the docs for this exact need. Don't know
how far along it is, but I am sure any help you can provide to move it
along would be appreciated.

-Brett


From tjreedy at udel.edu  Fri Nov 21 22:36:08 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 21 Nov 2008 16:36:08 -0500
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <4926BC57.8030509@gmail.com>
References: <4926BC57.8030509@gmail.com>
Message-ID: <gg79k7$k5e$1@ger.gmane.org>

Ezio Melotti wrote:

I have thought of the same idea, as have others, but decided not to 
propose it.

> As far as I know, the only way to report a typo

There are rather few left I think.  I and others report all we notice.

 > or change something in
> the documentation is actually open an issue in the bug tracker.
> This implies that:
> 1. If the user is not registered to the bug tracker he can't open the 
> issue, and he won't probably register for a small mistake;

If the user is not registered to the wiki.... ditto.

Actually, the wiki has some problems.  When I forgot my password and 
clicked 'Email me ...', it sent me a link to the wrong page with a 
password that did not work. I reported it but it apparently will not be 
fixed.

> 2. The user has to spend some time to reach the bug tracker page,

or the wiki page.  Actually trivial in either case.

> open a new issue, write a brief description of the problem

This does take longer, but not near as long as thinking about what words 
to write.

 > and possibly create and attach a patch;

The doc maintainers seem to be happy to either copy,paste,format from 
ascii text submissions or rewrite in a style they think better fits 
their idea of the Python doc style.  They probably do this faster than I 
can write the text to copy and paste.

> 3. A developer (of Python) has to read the issue, write a patch or check 
> if the attached patch is ok and then apply it (even if I think that some 
> developers can edit the doc directly).
> In my opinion this is rather clumsy and certainly not user-friendly. 
> Even if the user is registered to the bug tracker and knows how to 
> report an issue (and this is already a small subset of the doc readers) 
> he may not want to go through all these step just to fix a typo.

Do you know any such 'he's?

> The idea is to allow all the users to edit the documentation pages 
> directly (like a wiki), but wait the approval of a developer before 
> apply the changes.
> The steps will then be:
> 1. The user finds a mistake, clicks on an [edit] link and fixes it;
> 2. A developer check if the correction is ok and approves of refuses it.

I suspect that the doc maintainers would spend as much time rewriting 
submissions as they do now and more time rejecting suggestions.  Since 
suggestions would be hidden until approved, they could also get 
conflicting suggestions, or repetitions of rejected suggestions. 
Non-maintainers would not be able to improve suggestions.

With the tracker, everything is visible and searchable (which is not to 
say that it could be be made even better).

> This will also lead to the following benefits:
> 1. All the users can contribute even if they are not registered and/or 
> they don't know how/where to report the problem;
> 2. The process is simpler so the users are more likely to report 
> mistakes, spending less time;

If you are right, they are also more likely to make suggestions ranging 
from the inane to high quality but stylistically not fitting.

> 3. If the process is easy enough, users may want to submit some example 
> or tip that could be useful to others;

I strongly feel examples and tips should be separate docs.  People could 
do that with the wiki now.  But, of course, that would require learning 
the wiki formatting language.

> 4. The developers just have to check and approve/refuse the changes. 
> Again, this will require less time and they will be able to fix several 
> mistakes in few minutes (if not seconds);

They would still have to copy changes back to the master .rst copy in 
the repository, so I see little time saving if any.  But they can decide 
that.

> 5. The bug tracker won't be "polluted" by issues regarding typos and 
> other small mistakes in the doc.

Tracker pollution is issues like 'why does 1.1 print as 1.1000000001'.

Many doc issues *need* discussion before a new text is decided on.

> Problems and limitations:
> Even if probably there's already something like this out there, I don't 
> know how easy it is to find/implement it. It shouldn't be too hard to 
> write something ex-novo, but then again, someone will have to do it. 
> Something like this works well for self-explanatory corrections (like 
> typos), but it could not be the best when you have to explain the 
> reasons of the change. Possible solutions are:
> 1. Allow the user to write an (optional) comment to the correction (e.g. 
> "Changed xyz to match the new docstring.");

That is what one can do with the tracker.

> 2. Open an issue where to discuss about the correction and then edit the 
> page (some developers could have direct access to the page so they can 
> edit them immediately -- I don't know if there's already something like 
> that now or if they have to apply patches);

> 3. Have a "discussion page" like the the ones that are commonly used in 
> wikis.

Wikis have one discussion page for each wiki page, with all discussions 
that one page jumbled together and never really closed.  After a few 
years, it can become a mess.

Tracker discussions are separate for each issue.  Once closed, new 
issues start fresh.  Participants in a particular issues are 
automatically notified of new posts to that issue, but only to that issue.

Tracker issues and discussions are not limited to one section of one 
document.  I have submitted issues that involved both the language and 
library manuals.

Terry Jan Reedy




From stephen at xemacs.org  Sat Nov 22 06:34:00 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 22 Nov 2008 14:34:00 +0900
Subject: [Python-ideas] A Wiki-style documentation with an
	approval	process
In-Reply-To: <gg79k7$k5e$1@ger.gmane.org>
References: <4926BC57.8030509@gmail.com>
	<gg79k7$k5e$1@ger.gmane.org>
Message-ID: <8763mgl3xz.fsf@xemacs.org>

Terry Reedy writes:
 > Ezio Melotti wrote:
 > 
 > I have thought of the same idea, as have others, but decided not to 
 > propose it.
 > 
 > > As far as I know, the only way to report a typo
 > 
 > There are rather few left I think.  I and others report all we notice.
 > 
 > > or change something in the documentation is actually open an
 > > issue in the bug tracker.

The really big differences between the bug tracker and a "wiki" seem
to be

(1) Anonymous "wiki" submission means no registration, which is a PITA
    for the bug tracker (I've a couple of users who religiously send
    PRs to the mailing list because they oppose using web interfaces
    that require registration on principle!)

    But these days even wikis are often requiring registration to slow
    down wiki spam.  Specifically, Python's does.

(2) Directly editing the document avoids the need to learn about the
    project workflow, figuring out appropriate people to assign to,
    the relevant module, applicable versions, etc.

    This is a quality vs. quantity tradeoff.  IMO Python is among the
    best in terms of quality, and it's not hurting in terms of
    quantity.  Don't fix what ain't broke.

[WARNING: following taken out of context; used to be at end.]

 > > 3. Have a "discussion page" like the the ones that are commonly used in 
 > > wikis.
 > 
 > Wikis have one discussion page for each wiki page, with all discussions 
 > that one page jumbled together and never really closed.  After a few 
 > years, it can become a mess.
 > 
 > Tracker discussions are separate for each issue.  Once closed, new 
 > issues start fresh.  Participants in a particular issues are 
 > automatically notified of new posts to that issue, but only to that issue.

This is a crucial point.  Wikis are good for free-form discussion, but
Python's issues have a lot of extra structure that the tracker should
take advantage of (even if it becomes more wiki-like in some ways).

I think a better approach would be to find unnecessary impediments in
the bug tracker, and eliminate them.  I don't know of any in Python's
(but I'm pretty familiar with it so I'm probably blind to its faults).

One *possibly* unnecessary impediment is the roundtrip requirement of
registering before being allowed to submit.  In Roundup it would be
straightforward to construct the new issue page to allow simultaneous
registration.  It would even be possible to "hold" the submission
until the registration confirmation were received, I think, but that
would be pretty hackish.

[Back to original order.]

 > > 3. A developer (of Python) has to read the issue, write a patch or check 
 > > if the attached patch is ok and then apply it (even if I think that some 
 > > developers can edit the doc directly).
 > > In my opinion this is rather clumsy and certainly not user-friendly. 
 > > Even if the user is registered to the bug tracker and knows how to 
 > > report an issue (and this is already a small subset of the doc readers) 
 > > he may not want to go through all these step just to fix a typo.
 > 
 > Do you know any such 'he's?

C'mon, I bet you've let a typo or two slide because your brain was on
fire to finish your latest hack.  Haven't we all?  If the doc you were
reading was the wiki and a fix was a mouse click, two keystrokes, and
another mouse click away, you might fix it in that situation.

The thing is, fixing typos and style issues is important as a general
indicator of quality (attention to detail), but going from 4 sigma to
6 sigma on typos just isn't that big a deal.

 > > The idea is to allow all the users to edit the documentation pages 
 > > directly (like a wiki), but wait the approval of a developer before 
 > > apply the changes.
 > > The steps will then be:
 > > 1. The user finds a mistake, clicks on an [edit] link and fixes it;
 > > 2. A developer check if the correction is ok and approves of refuses it.
 > 
 > I suspect that the doc maintainers would spend as much time rewriting 
 > submissions as they do now and more time rejecting suggestions.

Agree.  Not a good thing.

 > Since suggestions would be hidden until approved, they could also
 > get conflicting suggestions, or repetitions of rejected
 > suggestions.

Fixable.  Clicking on the edit link would bring up the pending changes
to that page.  Presenting these could be done as a series of diff -U1
hunks, for example.  Conflicting changes would be marked in some
special way.  Each hunk gets a Defer/Approve/Reject radio button box
if you have sufficient karma.  Maybe there should be a Spam button too.

 > Non-maintainers would not be able to improve suggestions.

Not directly, but they could get access to previous suggestions as
above and file a conflicting one.

 > > This will also lead to the following benefits:
 > > 1. All the users can contribute even if they are not registered and/or 
 > > they don't know how/where to report the problem;
 > > 2. The process is simpler so the users are more likely to report 
 > > mistakes, spending less time;
 > 
 > If you are right, they are also more likely to make suggestions ranging 
 > from the inane to high quality but stylistically not fitting.

Agree.  "Simple process good, simplistic process, not so good."

 > > 3. If the process is easy enough, users may want to submit some example 
 > > or tip that could be useful to others;
 > 
 > I strongly feel examples and tips should be separate docs.  People could 
 > do that with the wiki now.  But, of course, that would require learning 
 > the wiki formatting language.
 > 
 > > 4. The developers just have to check and approve/refuse the changes. 
 > > Again, this will require less time and they will be able to fix several 
 > > mistakes in few minutes (if not seconds);
 > 
 > They would still have to copy changes back to the master .rst copy in 
 > the repository,

This can be automated, but I can't say at what cost.  You might have
to rewrite the whole wiki software....

 > > 5. The bug tracker won't be "polluted" by issues regarding typos and 
 > > other small mistakes in the doc.
 > 
 > Many doc issues *need* discussion before a new text is decided on.

Agree.  Among other things, it can be useful to QA to know how many
trivial issues are being fixed and by whom.

 > > 1. Allow the user to write an (optional) comment to the correction (e.g. 
 > > "Changed xyz to match the new docstring.");
 > 
 > That is what one can do with the tracker.

Right, but one can't write a patch in the tracker the way you can in a
wiki.

Trac has its wiki/tracker "integration", but this kind of thing
doesn't seem to be there.  WIBNI you could pull up source (both code
and doc) in the wiki and wiki-like edit it, which would then generate
and optionally submit a diff against the official sources?  (Not
entirely serious, for the reasons you give about frivolous
"contributions", but with appropriate controls, why not?



From skip at pobox.com  Sat Nov 22 13:54:25 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 22 Nov 2008 06:54:25 -0600
Subject: [Python-ideas] A Wiki-style documentation with an approval
 process
In-Reply-To: <8763mgl3xz.fsf@xemacs.org>
References: <8763mgl3xz.fsf@xemacs.org>
Message-ID: <18728.257.728949.613062@montanaro-dyndns-org.local>


    Stephen>     But these days even wikis are often requiring registration
    Stephen>     to slow down wiki spam.  Specifically, Python's does.

We've added ACLs to a number of frequently spammed pages, but in general we
still allow anonymous contributions to the Python wiki.  You can see that's
the case if you visit the info link of most pages.  For example I know the
BayPiggiesGoogleMeetings page is frequently edited anonymously:

    http://wiki.python.org/moin/BayPiggiesGoogleMeetings?action=info

Note that the editor column is frequently a hostname.

OTOH, the FrontPage was frequently spammed as were a number of unusual
pages.  The form such spam takes is often about the same from one incident
to another.  My guess is there's a "root kit" for spamming wikis out there.
It's probably a case of "even my grandmother could spam your wiki".

Skip


From partoa at gmail.com  Sat Nov 22 15:19:12 2008
From: partoa at gmail.com (Patrick Atambo)
Date: Sat, 22 Nov 2008 17:19:12 +0300
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <bbaeab100811211030t20d6c2a4q674e7a17ed275c34@mail.gmail.com>
References: <4926BC57.8030509@gmail.com>
	<bbaeab100811211030t20d6c2a4q674e7a17ed275c34@mail.gmail.com>
Message-ID: <ddfc2cb60811220619p782371b4kbc78b37b31ecc74@mail.gmail.com>

I believe that a commenting system could be very helpful.
I have done some PHP coding and in my early years the chm that includes the
comments was of great value to me since I never had an Internet connection
at home so I would just download the document from a cyber cafe and hack
away.
In the case of Python, where I still don't have a lot of experience, the
fact that I must always be online to find possible solutions to a problem
can be quite a drag, still, dir and docstrings help a lot though.
At that if I could help out, Georg, let me know how, I'm relatively new to
this stuff but I would love to give back to the community, Python has made
me quite some money.

Kind Regards,
Patrick Atambo.

On 11/21/08, Brett Cannon <brett at python.org> wrote:
> On Fri, Nov 21, 2008 at 05:49, Ezio Melotti <ezio.melotti at gmail.com>
wrote:
>  > As far as I know, the only way to report a typo or change something in
the
>  > documentation is actually open an issue in the bug tracker.
>  > This implies that:
>  > 1. If the user is not registered to the bug tracker he can't open the
issue,
>  > and he won't probably register for a small mistake;
>  > 2. The user has to spend some time to reach the bug tracker page, open
a new
>  > issue, write a brief description of the problem and possibly create and
>  > attach a patch;
>  > 3. A developer (of Python) has to read the issue, write a patch or
check if
>  > the attached patch is ok and then apply it (even if I think that some
>  > developers can edit the doc directly).
>  > In my opinion this is rather clumsy and certainly not user-friendly.
Even if
>  > the user is registered to the bug tracker and knows how to report an
issue
>  > (and this is already a small subset of the doc readers) he may not want
to
>  > go through all these step just to fix a typo.
>  >
>  > The idea is to allow all the users to edit the documentation pages
directly
>  > (like a wiki), but wait the approval of a developer before apply the
>  > changes.
>  > The steps will then be:
>  > 1. The user finds a mistake, clicks on an [edit] link and fixes it;
>  > 2. A developer check if the correction is ok and approves of refuses
it.
>  >
>
>
> Georg can correct me if I am wrong, but I believe he has been working
>  on a commenting system for the docs for this exact need. Don't know
>  how far along it is, but I am sure any help you can provide to move it
>  along would be appreciated.
>
>
>  -Brett
>
> _______________________________________________
>  Python-ideas mailing list
>  Python-ideas at python.org
>  http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081122/a391bb32/attachment.html>

From aahz at pythoncraft.com  Sat Nov 22 16:20:53 2008
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 22 Nov 2008 07:20:53 -0800
Subject: [Python-ideas] A Wiki-style documentation with an
	approval	process
In-Reply-To: <ddfc2cb60811220619p782371b4kbc78b37b31ecc74@mail.gmail.com>
References: <4926BC57.8030509@gmail.com>
	<bbaeab100811211030t20d6c2a4q674e7a17ed275c34@mail.gmail.com>
	<ddfc2cb60811220619p782371b4kbc78b37b31ecc74@mail.gmail.com>
Message-ID: <20081122152053.GA23228@panix.com>

On Sat, Nov 22, 2008, Patrick Atambo wrote:
>
> In the case of Python, where I still don't have a lot of experience, the
> fact that I must always be online to find possible solutions to a problem
> can be quite a drag, still, dir and docstrings help a lot though.

Well, Python does make it easy to download the HTML docs; that's what
I've done for years to have a local copy handy.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan


From tjreedy at udel.edu  Sat Nov 22 21:30:20 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 22 Nov 2008 15:30:20 -0500
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <ddfc2cb60811220619p782371b4kbc78b37b31ecc74@mail.gmail.com>
References: <4926BC57.8030509@gmail.com>	<bbaeab100811211030t20d6c2a4q674e7a17ed275c34@mail.gmail.com>
	<ddfc2cb60811220619p782371b4kbc78b37b31ecc74@mail.gmail.com>
Message-ID: <gg9q4p$il9$1@ger.gmane.org>

Patrick Atambo wrote:
> I believe that a commenting system could be very helpful.
> I have done some PHP coding and in my early years the chm that includes 
> the comments was of great value to me since I never had an Internet 
> connection at home so I would just download the document from a cyber 
> cafe and hack away.
> In the case of Python, where I still don't have a lot of experience, the 
> fact that I must always be online to find possible solutions to a 
> problem can be quite a drag,

The Windows installer installs a .chm version of the docs with a nice 
TOC and module index.  It seems to have everything the .html version has 
except the general index.  (I presume that because Help does not have 
within doc anchors).  If you could use PHP .chm, cannot you use Python 
.chm also?



From tjreedy at udel.edu  Sat Nov 22 21:35:09 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 22 Nov 2008 15:35:09 -0500
Subject: [Python-ideas] A Wiki-style documentation with an approval
	process
In-Reply-To: <8763mgl3xz.fsf@xemacs.org>
References: <4926BC57.8030509@gmail.com>	<gg79k7$k5e$1@ger.gmane.org>
	<8763mgl3xz.fsf@xemacs.org>
Message-ID: <gg9qdr$jbq$1@ger.gmane.org>

Stephen J. Turnbull wrote:

> C'mon, I bet you've let a typo or two slide because your brain was on
> fire to finish your latest hack.  Haven't we all?  If the doc you were
> reading was the wiki and a fix was a mouse click, two keystrokes, and
> another mouse click away, you might fix it in that situation.

1. There are very few overt typos left in the docs.
2. Why would I use such an inferior version as a wiki version would be?

Now, if someone wrote a Microsoft Help workalike program that also 
included an 'email corrections' feature, that would be something else.



From rocco.rossi at gmail.com  Mon Nov 24 21:01:15 2008
From: rocco.rossi at gmail.com (Rocco Orlando Rossi)
Date: Mon, 24 Nov 2008 21:01:15 +0100
Subject: [Python-ideas] Complex rationals in Python.
Message-ID: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>

I appreciate the inclusion of the fractions module in Python 2.6 and
therefore in Python 3.0. But I feel there's something missing: no
possibility for complex rationals (or arbitrary precision) integers. I
was just checking the complex number support in Python, compared, for
instance, to Common Lisp and Scheme, and I realized that there was
this subtle omission. The inclusion of rationals and arbitrary
integers is cool, but the numeric tower (say, compared to Scheme) is
not complete. I don't think there would be a performance hit if
complex rationals were provided. Ordinary operations on complex
floats, in theory, should not be affected and handled separately. But
it would be nice to be able to do:

(3/4 + 1/2j) * (1/4 - j) = 11/16 - 5/8j

with no loss of precision.

Python is heavily used in math and science all over the world. We've
even got a recent symbolic math project (sympy) that looks very
promising, so I guess this could be an important issue.

Note: there exists a library that implements what I'm talking about:
http://calcrpnpy.sourceforge.net/clnum.html
but still I personally would have liked to see this stuff included
natively in the new Python 3.0.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20081124/a46f6d37/attachment.html>

From guido at python.org  Mon Nov 24 21:22:36 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 24 Nov 2008 12:22:36 -0800
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
Message-ID: <ca471dc20811241222r53ccdce3g5cb72b978ae60c9b@mail.gmail.com>

It's way too late in the 3.0 release cycle, but feel free to submit a
patch for inclusion into 2.7 and 3.1.

On Mon, Nov 24, 2008 at 12:01 PM, Rocco Orlando Rossi
<rocco.rossi at gmail.com> wrote:
> I appreciate the inclusion of the fractions module in Python 2.6 and
> therefore in Python 3.0. But I feel there's something missing: no
> possibility for complex rationals (or arbitrary precision) integers. I
> was just checking the complex number support in Python, compared, for
> instance, to Common Lisp and Scheme, and I realized that there was
> this subtle omission. The inclusion of rationals and arbitrary
> integers is cool, but the numeric tower (say, compared to Scheme) is
> not complete. I don't think there would be a performance hit if
> complex rationals were provided. Ordinary operations on complex
> floats, in theory, should not be affected and handled separately. But
> it would be nice to be able to do:
>
> (3/4 + 1/2j) * (1/4 - j) = 11/16 - 5/8j
>
> with no loss of precision.
>
> Python is heavily used in math and science all over the world. We've
> even got a recent symbolic math project (sympy) that looks very
> promising, so I guess this could be an important issue.
>
> Note: there exists a library that implements what I'm talking about:
> http://calcrpnpy.sourceforge.net/clnum.html
> but still I personally would have liked to see this stuff included
> natively in the new Python 3.0.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From dickinsm at gmail.com  Mon Nov 24 21:24:28 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 24 Nov 2008 20:24:28 +0000
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
Message-ID: <5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>

On Mon, Nov 24, 2008 at 8:01 PM, Rocco Orlando Rossi
<rocco.rossi at gmail.com> wrote:
> I appreciate the inclusion of the fractions module in Python 2.6 and
> therefore in Python 3.0. But I feel there's something missing: no
> possibility for complex rationals (or arbitrary precision) integers.

This seems like a specialist need to me---one that belongs in a Python
extension package or library, but not in core Python.

Another thought: the field Q(i) is just one of an infinite number
of quadratic extensions of the field of rationals.  Why implement
that one and not the others?  Put another way, the field of
complex numbers is a fairly natural object, but the choice to
represent it as reals adjoin sqrt(-1) is quite arbitrary---one
could just as easily adjoin sqrt(-2), or sqrt(-3), or
(-1+sqrt(-3))/2 instead.

Have you investigated sage? (www.sagemath.org)

Mark


From tjreedy at udel.edu  Mon Nov 24 21:41:35 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 24 Nov 2008 15:41:35 -0500
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
	<5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
Message-ID: <ggf3hv$l94$1@ger.gmane.org>

Mark Dickinson wrote:
> On Mon, Nov 24, 2008 at 8:01 PM, Rocco Orlando Rossi
> <rocco.rossi at gmail.com> wrote:
>> I appreciate the inclusion of the fractions module in Python 2.6 and
>> therefore in Python 3.0. But I feel there's something missing: no
>> possibility for complex rationals (or arbitrary precision) integers.
> 
> This seems like a specialist need to me---one that belongs in a Python
> extension package or library, but not in core Python.

Call is 'algebra'?, and included quaternions.

> Another thought: the field Q(i) is just one of an infinite number
> of quadratic extensions of the field of rationals.  Why implement
> that one and not the others?  Put another way, the field of
> complex numbers is a fairly natural object, but the choice to
> represent it as reals adjoin sqrt(-1) is quite arbitrary---one
> could just as easily adjoin sqrt(-2), or sqrt(-3), or
> (-1+sqrt(-3))/2 instead.
> 
> Have you investigated sage? (www.sagemath.org)
> 
> Mark



From dickinsm at gmail.com  Mon Nov 24 21:50:47 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 24 Nov 2008 20:50:47 +0000
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <ggf3hv$l94$1@ger.gmane.org>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
	<5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
	<ggf3hv$l94$1@ger.gmane.org>
Message-ID: <5c6f2a5d0811241250n23caf0ceo94c287501321ad51@mail.gmail.com>

On Mon, Nov 24, 2008 at 8:41 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Call is 'algebra'?, and included quaternions.

And octonions, too?  :-)


From arnodel at googlemail.com  Mon Nov 24 21:58:01 2008
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Mon, 24 Nov 2008 20:58:01 +0000
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
	<5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
Message-ID: <DD2140A1-FF78-401C-B3B4-404F8B800CC9@googlemail.com>


On 24 Nov 2008, at 20:24, Mark Dickinson wrote:

> On Mon, Nov 24, 2008 at 8:01 PM, Rocco Orlando Rossi
> <rocco.rossi at gmail.com> wrote:
>> I appreciate the inclusion of the fractions module in Python 2.6 and
>> therefore in Python 3.0. But I feel there's something missing: no
>> possibility for complex rationals (or arbitrary precision) integers.
>
> This seems like a specialist need to me---one that belongs in a Python
> extension package or library, but not in core Python.
>
> Another thought: the field Q(i) is just one of an infinite number
> of quadratic extensions of the field of rationals.  Why implement
> that one and not the others?  Put another way, the field of
> complex numbers is a fairly natural object, but the choice to
> represent it as reals adjoin sqrt(-1) is quite arbitrary---one
> could just as easily adjoin sqrt(-2), or sqrt(-3), or
> (-1+sqrt(-3))/2 instead.

If we want Q(i), then surely we also want Z[i].  Gaussian integers  
have plenty of uses.

-- 
Arnaud



From dickinsm at gmail.com  Mon Nov 24 22:05:16 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 24 Nov 2008 21:05:16 +0000
Subject: [Python-ideas] Complex rationals in Python.
In-Reply-To: <DD2140A1-FF78-401C-B3B4-404F8B800CC9@googlemail.com>
References: <720198610811241201u77ef5a73i288a5b11350e2bb8@mail.gmail.com>
	<5c6f2a5d0811241224u224584f7l729f42618e61f654@mail.gmail.com>
	<DD2140A1-FF78-401C-B3B4-404F8B800CC9@googlemail.com>
Message-ID: <5c6f2a5d0811241305m7e16536dq7f2d605970a164a2@mail.gmail.com>

On Mon, Nov 24, 2008 at 8:58 PM, Arnaud Delobelle
<arnodel at googlemail.com> wrote:

> If we want Q(i), then surely we also want Z[i].  Gaussian integers have
> plenty of uses.

Sure, but what are the uses of Z[i] that don't also
apply to other rings of integers of quadratic fields?

I guess I can see uses in teaching:  if you're playing around
with complex numbers for the first time then it's possible that
all your calculations actually lie in Q[i].

Mark


From rbonvall+gmane at gmail.com  Thu Nov 27 05:09:14 2008
From: rbonvall+gmane at gmail.com (Roberto Bonvallet)
Date: Thu, 27 Nov 2008 04:09:14 +0000 (UTC)
Subject: [Python-ideas] Smallest/Largest singletons
References: <91ad5bf80811100846w604491e9ibb5105cc041419fd@mail.gmail.com>
Message-ID: <ggl6ha$5o1$1@ger.gmane.org>

George Sakkis <george.sakkis at gmail.com> wrote:
> Is it maybe the right time to add a builtin Smallest (and also Largest)
> object, i.e. two singletons so that `Smallest < x` for every x: x is not
> Smallest and `Largest > x` for every x: x is not Largest ?

Largest  = float('Infinity')
Smallest = float('-Infinity')

-- 
Roberto Bonvallet




From skip at pobox.com  Thu Nov 27 19:59:57 2008
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 27 Nov 2008 12:59:57 -0600
Subject: [Python-ideas] Smallest/Largest singletons
In-Reply-To: <ggl6ha$5o1$1@ger.gmane.org>
References: <ggl6ha$5o1$1@ger.gmane.org>
Message-ID: <18734.60973.116037.43231@montanaro-dyndns-org.local>


    >> Is it maybe the right time to add a builtin Smallest (and also
    >> Largest) object, i.e. two singletons so that `Smallest < x` for every
    >> x: x is not Smallest and `Largest > x` for every x: x is not Largest
    >> ?

    Roberto> Largest  = float('Infinity')
    Roberto> Smallest = float('-Infinity')

Hmmm...

    Python 2.7a0 (trunk:67276M, Nov 18 2008, 21:20:11) 
    [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> Smallest = float('-Infinity')
    >>> Largest = float('Infinity')
    >>> Smallest < 'a'
    True
    >>> Largest < 'a'
    True

In short, it will likely work for numbers but not other types.

Skip