date:20160703

On Sunday, July 3, 2016 at 6:59:14 PM UTC+12, John Ladasky wrote:
> from math import pi as π
> 
> c = 2 * π * r

ldo@theon:~> python3
Python 3.5.1+ (default, Jun 10 2016, 09:03:40) 
[GCC 5.4.0 20160603] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import pi as π
>>> 
>>> c = 2 * π * r
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'r' is not defined

It wasn’t the “π” it was complaining about...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Jussi Piitulainen

John Ladasky writes:

[- -]

> The nabla symbol (∇) is used in the naming of gradients.  Python isn't
> having it.  The interpreter throws a "SyntaxError: invalid character
> in identifier" when it encounters the ∇.
>
> I am now wondering what constitutes a valid character for an
> identifier, and how they were chosen.  Obviously, the Western alphabet
> and standard Greek letters work.  I just tried a few very weird
> characters from the Latin Extended range, and some Cyrillic
> characters.  These are also fine.

I think they merely extended the identifier syntax to Unicode: one or
more letters, underscores and digits, not starting with a digit. The
nabla symbol is not classified as a letter in Unicode, so it's not
allowed under this rule, and there is no other rule to allow it.

(Hm. Python seems to understand that the character occurs in what is
intended to be an identifier. Perhaps that's a default error message.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro :

> It wasn’t the “π” it was complaining about...

The question is why π is accepted but ∇ is not.

The immediate reason is that π is a letter while ∇ is not. But the
question, then, is why bother excluding nonletters from identifiers.

Personally, I don't think even π should be used in identifiers.
Mathematicians and physicists have a questionable tradition of using
single-character identifiers in their formulas. That shouldn't be
transported to programming.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Rustom Mody

On Sunday, July 3, 2016 at 12:29:14 PM UTC+5:30, John Ladasky wrote:
> A while back, I shared my love for using Greek letters as variable names in 
> my Python (3.4) code -- when, and only when, they are warranted for improved 
> readability.  For example, I like to see the following:
> 
> 
> from math import pi as π
> 
> c = 2 * π * r
> 
> 
> When I am copying mathematical formulas from publications, and Greek letters 
> are used in that publication, I prefer to follow the text exactly as written.
> 
> Up until today, every character I've tried has been accepted by the Python 
> interpreter as a legitimate character for inclusion in a variable name.  Now 
> I'm copying a formula which defines a gradient.  The nabla symbol (∇) is used 
> in the naming of gradients.  Python isn't having it.  The interpreter throws 
> a "SyntaxError: invalid character in identifier" when it encounters the ∇.
> 
> I am now wondering what constitutes a valid character for an identifier, and 
> how they were chosen.  Obviously, the Western alphabet and standard Greek 
> letters work.  I just tried a few very weird characters from the Latin 
> Extended range, and some Cyrillic characters.  These are also fine.

https://docs.python.org/3.5/reference/lexical_analysis.html
points to
https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

Quite hardwired

> 
> A philosophical question.  Why should any character be excluded from a 
> variable name, besides the fact that it might also be an operator?
> 
> This might be a problem I can solve, I'm not sure.  Is there a file that the 
> Python interpreter refers to which defines the accepted variable name 
> characters?  Perhaps I could just add ∇.

You need to try something like

>>> import unicodedata as ud
>>> ud.category("∇")
'Sm'
>>> ud.category("A")
'Lu'
>>> ud.category("π")
'Ll'
>>> ud.category("a")
'Ll'

followed by figuring out why/what etc from (say)
https://en.wikipedia.org/wiki/Unicode_character_property

This is the way it IS
Not saying it SHOULD BE…
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky  wrote:
> Up until today, every character I've tried has been accepted by the Python 
> interpreter as a legitimate character for inclusion in a variable name.  Now 
> I'm copying a formula which defines a gradient.  The nabla symbol (∇) is used 
> in the naming of gradients.  Python isn't having it.  The interpreter throws 
> a "SyntaxError: invalid character in identifier" when it encounters the ∇.
>
> I am now wondering what constitutes a valid character for an identifier, and 
> how they were chosen.  Obviously, the Western alphabet and standard Greek 
> letters work.  I just tried a few very weird characters from the Latin 
> Extended range, and some Cyrillic characters.  These are also fine.
>

Very good question! The detaily answer is here:

https://docs.python.org/3/reference/lexical_analysis.html#identifiers

> A philosophical question.  Why should any character be excluded from a 
> variable name, besides the fact that it might also be an operator?
>

In a way, that's exactly what's happening here. Python permits certain
categories of character as identifiers, leaving other categories
available for operators. Even though there aren't any non-ASCII
operators in a vanilla CPython, it's plausible that someone could
create a Python-based language with more operators (eg ≠ NOT EQUAL TO
as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
is nonsensical.

> This might be a problem I can solve, I'm not sure.  Is there a file that the 
> Python interpreter refers to which defines the accepted variable name 
> characters?  Perhaps I could just add ∇.
>

The key here is its Unicode category:

>>> unicodedata.category("∇")
'Sm'

You could probably hack CPython to include Sm, and maybe Sc, Sk, and
So, as valid identifier characters. I'm not sure where, though, and
I've just spent a good bit of time delving (it's based on the
XID_Start and XID_Continue derived properties, but I have no idea
where they're defined - Tools/unicode/makeunicodedata.py looks
promising, but even there, I can't find it). And - or maybe instead -
you could appeal to the core devs to have the category/ies in question
added to the official Python spec. Symbols like that are a bit of a
grey area, so you may find that you're starting a huge debate :)

Have fun.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:

> Personally, I don't think even π should be used in identifiers.

Why not? Python already has all the other single-character constants in what 
probably the most fundamental identity in all of mathematics:

$$e^{i \pi} + 1 = 0$$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro :

> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>
>> Personally, I don't think even π should be used in identifiers.
>
> Why not?

1. It can't be typed easily.

2. It can look like an n.

3. Single-character identifiers should not be promoted, especially with
   a global scope.

> Python already has all the other single-character constants in what
> probably the most fundamental identity in all of mathematics:
>
> $$e^{i \pi} + 1 = 0$$

Mathematics and physics have run into trouble with single-character
identifiers already. They have run out of letters and have had to reuse
them. Programmers used to have the same problem until they realized it's
ok to use descriptive names.

Just say,

>>> import cmath
>>> cmath.e ** (1j * cmath.pi) + 1
1.2246467991473532e-16j

Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Robert Kern


On 2016-07-03 08:29, Jussi Piitulainen wrote:

(Hm. Python seems to understand that the character occurs in what is
intended to be an identifier. Perhaps that's a default error message.)


I suspect that "identifier" is the final catch-all token in the lexer. Comments 
and strings are clearly delimited. Keywords, operators, and [{(braces)}] are all 
explicitly whitelisted from finite lists. Well, I guess it could have been 
intended by the user to be a numerical literal, but I suspect that's attempted 
before identifier.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Alain Ketterlin

John Ladasky  writes:

> from math import pi as π
> [...]
> c = 2 * π * r

> Up until today, every character I've tried has been accepted by the
> Python interpreter as a legitimate character for inclusion in a
> variable name. Now I'm copying a formula which defines a gradient. The
> nabla symbol (∇) is used in the naming of gradients. Python isn't
> having it. The interpreter throws a "SyntaxError: invalid character in
> identifier" when it encounters the ∇.

The rules are at
https://docs.python.org/3.5/reference/lexical_analysis.html#identifiers

To me it makes a lot of sense to *not* include category Sm characters in
identifiers, since they are usually used to denote operators (like +).
It would be very confusing to have a variable named ∇f, as confusing as
naming a variable a+b or √x.

-- Alain.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Alain Ketterlin :

> It would be very confusing to have a variable named ∇f, as confusing
> as naming a variable a+b or √x.

Scheme allows *any* characters whatsoever in identifiers.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Christian Gollwitzer


Am 03.07.16 um 13:01 schrieb Marko Rauhamaa:

Alain Ketterlin :


It would be very confusing to have a variable named ∇f, as confusing
as naming a variable a+b or √x.


Scheme allows *any* characters whatsoever in identifiers.


Parentheses?

Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Christian Gollwitzer :

> Am 03.07.16 um 13:01 schrieb Marko Rauhamaa:
>> Alain Ketterlin :
>>
>>> It would be very confusing to have a variable named ∇f, as confusing
>>> as naming a variable a+b or √x.
>>
>> Scheme allows *any* characters whatsoever in identifiers.
>
> Parentheses?

Yes.

Hint: Python allows *any* characters whatsoever in strings.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Sat, Jul 2, 2016 at 11:37 PM, Lawrence D’Oliveiro
 wrote:
> On Sunday, July 3, 2016 at 4:49:15 PM UTC+12, Ian wrote:
>>
>> On Sat, Jul 2, 2016 at 12:40 AM, Lawrence D’Oliveiro wrote:
>>>
>>> On Saturday, July 2, 2016 at 5:10:06 PM UTC+12, Ian wrote:

 You should use functools.wraps instead of clobbering the decorated
 function's name and docstring:
>>>
>>> Where am I doing that?
>>
>> Using the implementation you posted:
>>
> @decorator_with_args
>> ... def my_decorator(func, *args, **kwargs):
>> ... """Returns func unmodified."""
>> ... return func
>> ...
> my_decorator.__doc__
>> 'generates a decorator which applies my_decorator to the given arguments'
>
> That is a function that I am generating, so naturally I want to give it a 
> useful docstring. Am I “clobbering” any objects passed in by the caller, or 
> returned by the caller? No, I am not.

It isn't useful, though. If somebody writes a docstring for a
function, it's because they want that to be the docstring for the
function, not some arbitrary and vague docstring assigned by a
decorator. If I type "help(my_decorator)" in the interactive
interpreter, I should see what my_decorator actually does, not
"generates a decorator which applies my_decorator", which just
confuses with its recursiveness. The only way to find out what
my_decorator actually does from the interactive interpreter would be
to realize that it's been opaquely decorated and type out something
like this:

>>> my_decorator.__closure__[0].cell_contents.__doc__
'Returns func unmodified.'

That's far too obscure. Alternatively, one could go read the source.
But if you have to go read the source to understand what a function
does, then you've lost the purpose of having a docstring in the first
place.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of


On 03/07/2016 12:01, Marko Rauhamaa wrote:

Alain Ketterlin :


It would be very confusing to have a variable named ∇f, as confusing
as naming a variable a+b or √x.


Scheme allows *any* characters whatsoever in identifiers.


I think it's one of those languages that has already dispensed with most 
syntax anyway. Including distinctions between names and symbols.


Some people think that extra syntax rules including enforcing such 
distinctions and having restrictions can improve readability. Otherwise 
you can be looking at:


  a b c d e f g h

(not Scheme) and wondering which are names and which are operators.

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Lost in descriptor land

2016-07-03 Thread Ankush Thakur

On Sunday, July 3, 2016 at 4:37:49 AM UTC+5:30, Ian wrote:
> Classes define object behavior;
> instances contain object state. For example, you can't define a method
> on an instance (though you can certainly store a function there and
> call it).

Nice! Thanks for clearing that up. :)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lost in descriptor land

2016-07-03 Thread Ankush Thakur

On Sunday, July 3, 2016 at 6:32:56 AM UTC+5:30, Lawrence D’Oliveiro wrote:
> Haste makes waste, as they say. At least read the relevant part of the 
> article.

I really feel like I've been pushed into studying its genetics while I only 
wanted to pluck the fruit. Why do descriptors have to be so overwhelming?! . . 
. Okay, I guess I'll read at least the descriptor part of the article, but then 
I'm leaving the whole subject for another day.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Christian Gollwitzer


Am 03.07.16 um 13:22 schrieb Marko Rauhamaa:

Christian Gollwitzer :


Am 03.07.16 um 13:01 schrieb Marko Rauhamaa:

Alain Ketterlin :


It would be very confusing to have a variable named ∇f, as confusing
as naming a variable a+b or √x.


Scheme allows *any* characters whatsoever in identifiers.


Parentheses?


Yes.

Hint: Python allows *any* characters whatsoever in strings.


My knowledge of Scheme is rusty. How do you do that? Consider

(define x 'hello)

then the x is the identifier, isn't it? How can you include a 
metacharacter like space, ', or ( in it? I'm using 
https://repl.it/languages/scheme to try it out.


Another language which allows any characters in identifiers is Tcl. Here 
you can quote identifiers:


set {a b} c

creates a variable "a b" with a space in it, because there is no 
distinction between quoted/unquoted. Metacharacters can be included by 
\-escapes. How does that work in Scheme?


Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Christian Gollwitzer :

> Am 03.07.16 um 13:22 schrieb Marko Rauhamaa:
>> Christian Gollwitzer :
>>> Am 03.07.16 um 13:01 schrieb Marko Rauhamaa:
 Scheme allows *any* characters whatsoever in identifiers.
>>> Parentheses?
>> Yes.
>
> My knowledge of Scheme is rusty. How do you do that?

   Moreover, all characters whose Unicode scalar values are greater than
   127 and whose Unicode category is Lu, Ll, Lt, Lm, Lo, Mn, Mc, Me, Nd,
   Nl, No, Pd, Pc, Po, Sc, Sm, Sk, So, or Co can be used within
   identifiers. In addition, any character can be used within an
   identifier when specified via an . For example,
   the identifier H\x65;llo is the same as the identifier Hello, and the
   identifier \x3BB; is the same as the identifier λ.
   http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.4>

Guile doesn't support the R6RS inline hex escape notation. Instead, it
natively supports a notation of its own:

   #{foo bar}#

   #{what
   ever}#

   #{4242}#

Or the R7RS notation:

   |foo bar|
   |\x3BB; is a greek lambda|
   |\| is a vertical bar|

   https://www.gnu.org/software/guile/manual/html_node/Symbol-Rea
   d-Syntax.html#index-r7rs_002dsymbols>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Descriptor: class name precedence over instance name

2016-07-03 Thread Veek. M

Ian Kelly wrote:

> On Sat, Jul 2, 2016 at 3:34 AM, Veek. M  wrote:
>> So essentially from what Ian said:
>> data_descriptor_in_instance -> instance_attribute -> non-
>> data_descriptor_in_instance -->__mro__
>>
>> is how the search takes place. Correct?
> 
> Close, but I would write it as:
> data_descriptor_in_class_including_mro -> instance_attribute ->
> non_data_descriptor_or_class_attribute_including_mro
> 
> In either case the class dict search is in __mro__ order. You can find
> the actual implementation here:
> 
> https://hg.python.org/cpython/file/30099abdb3a4/Objects/object.c#l1326
> 
> Roughly, the algorithm is this:
> 
> tp = type(obj)
> 
> # This call searches the MRO.
> descr = _PyType_Lookup(tp, name)
> 
> if descr != NULL and is_data_descriptor(descr):
> return descr.__get__(obj, tp)
> 
> if name in obj.__dict__:
> return obj.__dict__[name]
> 
> if descr != NULL and is_non_data_descriptor(descr):
> return descr.__get__(obj, tp)
> 
> if descr != NULL:
> return descr
> 
> raise AttributeError(name)
> 
>> --
>>
>> Regarding part2 of the Q, :) Ian hasn't explained it, so I'm not sure
>> how to explain it better :) but i'll try given that he has clarified
>> part of the answer.
>>
>> Basically Beazley has a TypedProperty descriptor class, and in class
>> Foo he instantiates:
>>  name = TypedProperty
>> Then he does f = Foo()
>>
>> Thanks to Ian, we now know that any lookup on 'f' eg: f.name would
> 
> Not *any* lookup, only one for which there is a declared descriptor.
> So in this example f.name or f.num would resolve according to the
> descriptor's __get__ method, but any other attribute lookup would just
> return whatever value is set on the instance (if any).
> 
>> cause.. well.. the f.name(TypedProperty-descriptor) to gain
>> precedence thus hiding the f.name attribute! Therefore he needs to
>> name-decorate or in this example append an '_' for whatever stupid
>> reason.
> 
> Right, if the "name" descriptor tried to store the value in the
> unmangled "name" instance attribute, then its getattr call would just
> recur back to the descriptor and you'd have an infinite loop.
> 
> In my opinion the mangling should be a bit heavier than what's done in
> this example, to avoid collisions between the descriptor and the class
> that's using it. I like to follow the pattern of __foo name mangling,
> so I would have instead used:
> 
> self.name = "_TypedProperty__" + name

Ouch - that's above my skill level (Python types, especially 
PyType_Lookup has no docs but i did find 
https://docs.python.org/3/c-api/index.html) and I got side tracked into reading 
the PCIe spec so 
today went down the drain. I'm putting this on hold as totally not 
understood and requiring much more reading. I'll drag it up later if 
everyones okay with it.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: super and mix-in class: how exactly is the search order altered?

2016-07-03 Thread Veek. M

dieter wrote:

> "Veek. M"  writes:
>> ...
>> I'm reading this article:
>> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>>
>> He's trying to explain the purpose of a 'mix-in class' and he says
>>
>> We did not alter the source code for LoggingDict. Instead we
>> built a
>> subclass whose only logic is to compose two existing classes and
>> control their search order.
>>
>> class LoggingOD(LoggingDict, collections.OrderedDict):
>> pass
>>
>> My question is this: in the above article context, is he talking
>> about the LoggingDict's search order that is being manipulated? Or he
>> is talking about manipulating the LoggingOD search order?
> 
> Likely, his language has been a bit sloppy.
> 
> Likely, his setup is as follows:
> 
>  * He has an existing class ("collections.OrderDict")
>which the base functionality he needs
> 
>  * He has an additional requirement (over that of
>  "collections.OrderDict")
>-- logging modifications
> 
>  * He wants to implement his requirements (the base ones and the
>the additional one) without modifying the existing class in any way
> 
>  * His idea to implement the additional requirement is to define
>a derived class ("LoggingOD") and lets its modifying methods
>perform the logging and then call the corresponding methods of the
>base class.
> 
>  * He recognizes that this logging feature might be interesting
>not only for "collections.OrderDict" but also for other
>dictionary like base classes.
>Therefore, instead of implementing it directly in
>"LoggingOD", he implements it in the mixin class "LoggingDict".
> 
>  * Because "LoggingDict" was explicitely designed to be used
>as mixin class to enhance a base class, it knows that
>some methods ("__setitem__") of the base class need to be called
>in its own implementation of the corresponding method.
> 
>  * The integrator (the one combining "LoggingDict" with the base
>class) must ensure (by an appropriate inheritance order)
>that the combining class ("LoggingOD" in the example)
>calls the "LoggingDict"'s methods (which know about that of the
>base class) rather than the base class's methods (which do not
>know about the mixin class's methods).
> 
>Therefore, he uses the inheritance order "LoggingDict" followed
>by the base class (and not vice versa).
> 
> 
> Python clearly defines in what order attributes of an object
> and of the construct "super(,)" are looked up.
> 
> The essential concept is the so called "MRO" ("method resolution
> order") (in fact, it is an attribute resolution order).
> 
> In simple cases (no common base classes), the MRO of
> a definition "class C(B_1, ..., B_n): ..."
> is defined by a left to right lookup: i.e. first in "C", then "B_1",
> then "B_2", ...
> 
> The rules are a bit more complicated when the "B_i" have a (or more)
> common base classes.

Hey Dieter, I'll need some time to read this and get back on it - hope 
that's okay. But yeah, I think he's explaining it badly and extremely 
misleading (imho).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016 at 7:01 PM, Marko Rauhamaa  wrote:
> Lawrence D’Oliveiro :
>
>> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>>
>>> Personally, I don't think even π should be used in identifiers.
>>
>> Why not?
>
> 1. It can't be typed easily.
>
> 2. It can look like an n.
>
> 3. Single-character identifiers should not be promoted, especially with
>a global scope.

None of these is a language-level concern. You can't type it? That's
your problem - and you can choose not to use it. But Python lets you,
if you want to. Remember, some people speak Greek natively, and for
those people, typing Greek text is as natural as typing Latin text is
for us. Similarly, Cyrillic text is the most natural language for
Russian speakers. Why should Python block them?

Your other concerns might be a case for linters, but definitely not
the language.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Tkinter based GUI for PIP : Needed Feedback

2016-07-03 Thread Upendra Kumar

Hello everyone,

We have made a preliminary version of GUI for PIP.  This project is a part
of GSoC 2016. This project is intended to provide a GUI version for "pip".
 ( target audience for the project : beginners in Python ).

The project idea is discussed on these issues :
1. Issue #23551 : IDLE to provide menu link to PIP gui.
2. Issue #27051 : Create PIP GUI

The GitHub repo of the project : https://github.com/upendra-k14/pip_gui

Therefore, we would like to have feedback on this project so that we can
improve the GUI and other features to it. Please post as many issues and
suggestions here :
https://github.com/upendra-k14/pip_gui/issues.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lost in descriptor land

On Sun, 3 Jul 2016 09:06 am, Ian Kelly wrote:

> you can't define a method
> on an instance (though you can certainly store a function there and
> call it).

Yes -- the difference is that Python doesn't apply the descriptor protocol
to attributes attached to the instance. So the function remains a function
and is not converted to a method, which means it doesn't automatically get
the special "self" argument:

class Test(object):
pass

instance = Test()

def method(self):
print("method called from self", self)

instance.method = method

If you try to call the "method", you get an error:

py> instance.method()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: method() missing 1 required positional argument: 'self'

But if you prepare the method ahead of time, it works:

from types import MethodType
instance.method = MethodType(method, instance)

Now calling it works fine:

py> instance.method()
method called from self <__main__.Test object at 0xb79fcf14>

-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I need a pure python module from PyPI without additional packages on my OS.

2016-07-03 Thread Laurent Pointal

Seti Volkylany wrote:

> I heard about cairo, but it required installed on my computer before.

Some precision would be wellcome.

Do you need any pure Python module from PyPI ?

Do you need a "cairo compatible" pure Python module from PyPI ?

A+
L.P.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What the deal with python3.5m.so and python3.5.so ??

2016-07-03 Thread Laurent Pointal

Steven Truppe wrote:

> Hi all,
> 
> can someone tell me the difference between python3.5m.so and python3.5.so
> ??

The 'm' tagged version is for a Python compiled with PyMalloc:

https://www.python.org/dev/peps/pep-3149/

(found it with Blender's bundled Python)

> 
> Tanks in advance,
> Steven Truppe

A+
L.P.

-- 
https://mail.python.org/mailman/listinfo/python-list

Special attributes added to classes on creation

I have some code which can preprocess (using a metaclass) or postprocess
(using a decorator) a class:

@process
class K:
pass


class K(metaclass=process):
pass


Both should give the same result, but I have found that the results are
slightly different because the dict passed to process as a metaclass is
different from the the class dict seen by the decorator. I can demonstrate
the difference in Python 3.6 by using this metaclass/decorator:

class process(type):
def __new__(meta, *args):
if len(args) == 1:
# decorator usage
cls = args[0]
d = cls.__dict__
elif len(args) == 3:
# metaclass usage
name, bases, d = args
cls = super().__new__(meta, *args)
print(sorted(d.keys()))
return cls


If I then try it against two identical (apart from their names) classes, I
get these results:


py> @process
... class K:
... x = 1
...
['__dict__', '__doc__', '__module__', '__weakref__', 'x']
py> class Q(metaclass=process):
... x = 1
...
['__module__', '__qualname__', 'x']



Now if I check the newly created Q, I see the same keys K has:

py> sorted(Q.__dict__.keys())
['__dict__', '__doc__', '__module__', '__weakref__', 'x']


Is there any documentation for exactly what keys are added to classes when? 




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread John Ladasky

Lawrence, I trust you understand that I didn't post a complete working program, 
just a few lines showing the intended usage?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Special attributes added to classes on creation

On Sun, Jul 3, 2016 at 10:02 AM, Steven D'Aprano  wrote:
> If I then try it against two identical (apart from their names) classes, I
> get these results:
>
>
> py> @process
> ... class K:
> ... x = 1
> ...
> ['__dict__', '__doc__', '__module__', '__weakref__', 'x']
> py> class Q(metaclass=process):
> ... x = 1
> ...
> ['__module__', '__qualname__', 'x']
> Now if I check the newly created Q, I see the same keys K has:
>
> py> sorted(Q.__dict__.keys())
> ['__dict__', '__doc__', '__module__', '__weakref__', 'x']
>
>
> Is there any documentation for exactly what keys are added to classes when?

I'm only aware of the sequence defined at
https://docs.python.org/3/reference/datamodel.html#customizing-class-creation.
Based on that, I'm surprised to even see __module__ and __qualname__
in there at the point when the metaclass is handling it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread John Ladasky

On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote:
> On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote:

> Very good question! The detaily answer is here:
> 
> https://docs.python.org/3/reference/lexical_analysis.html#identifiers
> 
> > A philosophical question.  Why should any character be excluded from a 
> > variable name, besides the fact that it might also be an operator?
> 
> In a way, that's exactly what's happening here. Python permits certain
> categories of character as identifiers, leaving other categories
> available for operators. Even though there aren't any non-ASCII
> operators in a vanilla CPython, it's plausible that someone could
> create a Python-based language with more operators (eg ≠ NOT EQUAL TO
> as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
> is nonsensical.

I agree that there are some characters in the Unicode definition that could 
(should?) be operators and, as such, disallowed in identifiers.  "≠", "≥" and 
"√" come to mind.  I don't know whether the Unicode "character properties" are 
assigned to the characters in a way that would be satisfying to the needs of 
programmers.  I'll do some reading.

> Symbols like that are a bit of a
> grey area, so you may find that you're starting a huge debate :)

Oh, I can see that debate coming.  I know that not all of these characters are 
easily TYPED, and so I have to reach for a Unicode table to cut and paste them. 
 But once but and pasted, they are easily READ, and that's a big plus.

Here's another worm for the can.  Would you rather read this...

d = sqrt(x**2 + y**2)

...or this?

d = √(x² + y²)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread MRAB

On 2016-07-03 19:39, John Ladasky wrote:

On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote:

On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote:

Very good question! The detaily answer is here:

https://docs.python.org/3/reference/lexical_analysis.html#identifiers

> A philosophical question. Why should any character be excluded from a
variable name, besides the fact that it might also be an operator?

In a way, that's exactly what's happening here. Python permits certain
categories of character as identifiers, leaving other categories
available for operators. Even though there aren't any non-ASCII
operators in a vanilla CPython, it's plausible that someone could
create a Python-based language with more operators (eg ≠ NOT EQUAL TO
as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
is nonsensical.

I agree that there are some characters in the Unicode definition that could (should?) be operators and, as such,
disallowed in identifiers. "≠", "≥" and "√" come to mind. I don't know whether the
Unicode "character properties" are assigned to the characters in a way that would be satisfying to the needs
of programmers. I'll do some reading.

Symbols like that are a bit of a
grey area, so you may find that you're starting a huge debate :)

Oh, I can see that debate coming. I know that not all of these characters are
easily TYPED, and so I have to reach for a Unicode table to cut and paste them.
But once but and pasted, they are easily READ, and that's a big plus.

Here's another worm for the can. Would you rather read this...

d = sqrt(x**2 + y**2)

...or this?

d = √(x² + y²)

It's easy to read something as simple like that, but it's harder when
the exponent is more than a number or a variable. And what about a**b**c?

Not to mention the limited number of superscript codepoints available...
--
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Random832

On Sun, Jul 3, 2016, at 07:22, Marko Rauhamaa wrote:
> Christian Gollwitzer :
> > Am 03.07.16 um 13:01 schrieb Marko Rauhamaa:
> >> Scheme allows *any* characters whatsoever in identifiers.
> >
> > Parentheses?
> 
> Yes.
> 
> Hint: Python allows *any* characters whatsoever in strings.

Being able to put any character in a symbol doesn't make those strings
identifiers, any more than passing them to getattr/setattr (or
__import__, something's __name__, etc) does in Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Sunday, July 3, 2016 at 11:53:46 PM UTC+12, Ian wrote:
> On Sat, Jul 2, 2016 at 11:37 PM, Lawrence D’Oliveiro wrote:
>> That is a function that I am generating, so naturally I want to give it a
>> useful docstring. Am I “clobbering” any objects passed in by the caller,
>> or returned by the caller? No, I am not.
> 
> It isn't useful, though. If somebody writes a docstring for a
> function, it's because they want that to be the docstring for the
> function ...

Which I am not “clobbering” at all. Do you get that yet? My docstrings apply to 
*my* functions, not those supplied or generated by the caller.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 9:02:05 PM UTC+12, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro:
> 
>> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>>
>>> Personally, I don't think even π should be used in identifiers.
>>
> > Why not?
> 
> 1. It can't be typed easily.

I have a custom .XCompose, so it’s just “compose-p-i”. Easy to type, easy to 
remember.

> 2. It can look like an n.

Only to someone accustomed to using just one alphabet. :)

> 3. Single-character identifiers should not be promoted, especially with
>a global scope.

It’s no more “global” than “math.e”. And what about “1j”? (That completes the 
triumvirate of single-letter names from the Euler identity.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 11:50:52 PM UTC+12, BartC wrote:
> Otherwise you can be looking at:
> 
>a b c d e f g h
> 
> (not Scheme) and wondering which are names and which are operators.

I did a language design for my MSc thesis where all “functions” were operators. 
So a construct like “f(a, b, c)” was really a monadic operator “f” followed by 
a single argument, a record constructor “(a, b, c)”.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

Random832 :

> Being able to put any character in a symbol doesn't make those strings
> identifiers, any more than passing them to getattr/setattr (or
> __import__, something's __name__, etc) does in Python.

From R7RS, the newest Scheme standard (p. 61-62):

 7.1.1. Lexical structure
 [...]
 〈vertical line〉 → |
 [...]
 〈identifier〉 → 〈initial〉 〈subsequent〉*
  | 〈vertical line〉 〈symbol element〉* 〈vertical line〉
  | 〈peculiar identifier〉
 〈initial〉 → 〈letter〉 | 〈special initial〉
 〈letter〉 → a | b | c | ... | z
 | A | B | C | ... | Z
 〈special initial〉 → ! | $ | % | & | * | / | : | < | =
 | > | ? | ^ | _ | ~
 〈subsequent〉 → 〈initial〉 | 〈digit〉
 | 〈special subsequent〉
 〈digit〉 → 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
 〈hex digit〉 → 〈digit〉 | a | b | c | d | e | f
 〈explicit sign〉 → + | -
 〈special subsequent〉 → 〈explicit sign〉 | . | @
 〈inline hex escape〉 → \x〈hex scalar value〉;
 〈hex scalar value〉 → 〈hex digit〉 +
 〈mnemonic escape〉 → \a | \b | \t | \n | \r
 〈peculiar identifier〉 → 〈explicit sign〉
 | 〈explicit sign〉 〈sign subsequent〉 〈subsequent〉*
 | 〈explicit sign〉 . 〈dot subsequent〉 〈subsequent〉*
 | . 〈dot subsequent〉 〈subsequent〉*
 〈dot subsequent〉 → 〈sign subsequent〉 | .
 〈sign subsequent〉 → 〈initial〉 | 〈explicit sign〉 | @
 〈symbol element〉 →
 〈any character other than 〈vertical line〉or \〉
 | 〈inline hex escape〉 | 〈mnemonic escape〉 | \|


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote:
> Here's another worm for the can.  Would you rather read this...
> 
> d = sqrt(x**2 + y**2)
> 
> ...or this?
> 
> d = √(x² + y²)

Neither. I would rather see

d = math.hypot(x, y)

Much simpler, don’t you think?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

2016-07-03 Thread Kevin Conway

>> Regardless, all use cases you've listed are already satisfied by use of
>> the static and class method decorators. Methods decorated with these do
>> not require an instance initialization to use.

> And are significantly less easy to use, as the functions MUST refer to
each
> other by their dotted names.

My response to this may come off as a bit glib, but it isn't intended that
way. If the problem with using classes to satisfy the namespace need is
that it's unwieldy to use dot qualified paths then isn't that quite similar
to saying namespaces are unwieldy? Leveraging classes as a nested module
creates a de-facto internal namespace of "cls" for self reference and I'm
unsure of why that is unwanted but "module.namespace.blah" is wanted.

I suppose my issue is not so much that namespace objects are a bad idea as
that the proposal does little to express why the existing tools are
deficient enough to require a new concept.

> For the proponents of namespace, what is deficient in the above example
> that necessitates a language change?

>> It's not a language change.

Perhaps. My argument is that anything that introduces a new class-like
construct and set of lexical scoping rules is a language change. For
example, if this change went into 2.7.13 would Jython suddenly be broken
because it hasn't implemented the new scoping rules?

>> IIRC, classes came about as a "module in a module".

> I'm pretty sure they did not. Object oriented programming (and hence
> classes) came about from simulating real world objects, hence the
> name:

I realize my statement was ambiguous. I didn't mean to suggest that
classes, as an idea and OOP tool, were derived from the concept of a
namespace. I meant to say that the Python implementation of classes is
quite similar to the implementation of modules in the cPython code. The
commit messages from the earlier days (ref: ab5db02) don't carry much
detail so I'm mostly basing my belief of the implementation similarities
and anecdotes from the community. Right or wrong, I don't believe it has
much weight in the namespace discussion and I shouldn't have brought it up.

On Sun, Jul 3, 2016, 00:17 Ethan Furman  wrote:

> On 07/02/2016 08:44 PM, Steven D'Aprano wrote:
>
> > Try getting this behaviour from within a class:
> >
> >
> > class Food(metaclass=Namespace):
> >
> >  # (1) no special decorators required
> >  def spam(n):
> >  return ' '.join(['spam']*n)
> >
> >  # (2) can call functions from inside the namespace
> >  breakfast = spam(5)
> >
> >  # (3) no "cls" or "self" argument
> >  def lunch():
> >  # (4) can access variables using their undotted name
> >  return breakfast + ' and eggs'
> >
> >  def supper():
> >  # (5) likewise functions (a special case of #4)
> >  return lunch() + ' and a fried slice of spam'
> >
> >  def mutate(n):
> >  # global inside the namespace refers to the namespace,
> >  # not the surrounding module
> >  global breakfast
> >  breakfast = spam(5)
>
> > Can you do all of that with an ordinary class?
>
> You can get #2 already, but not the rest (without your spiffy code ;) :
>
> Python 3.5.1+ (3.5:f840608f79da, Apr 14 2016, 12:29:06)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class Huh:
> ...   def blah(text):
> ... print('blah blah %s blah blah blah' % text)
> ...   blah('whatever')
> ...
> blah blah whatever blah blah blah
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Sun, Jul 3, 2016 at 3:17 PM, Lawrence D’Oliveiro
 wrote:
> On Sunday, July 3, 2016 at 11:53:46 PM UTC+12, Ian wrote:
>> On Sat, Jul 2, 2016 at 11:37 PM, Lawrence D’Oliveiro wrote:
>>> That is a function that I am generating, so naturally I want to give it a
>>> useful docstring. Am I “clobbering” any objects passed in by the caller,
>>> or returned by the caller? No, I am not.
>>
>> It isn't useful, though. If somebody writes a docstring for a
>> function, it's because they want that to be the docstring for the
>> function ...
>
> Which I am not “clobbering” at all. Do you get that yet? My docstrings apply 
> to *my* functions, not those supplied or generated by the caller.

Sorry, but you're the one who doesn't seem to get it. Because it's a
decorator, "your" function is replacing the caller's function in the
caller's namespace. If the docstring written in the code for function
m.f is x, but the value of m.f.__doc__ is actually y, then the
docstring x is, for all practical purposes, clobbered. That you're not actually
modifying the original function is irrelevant.

For the purpose of the built-in help, it's the value of m.f.__doc__
that counts. For the purpose of documentation built with pydoc, it's
the value of m.f.__doc__ that counts. If the documentation for every
decorator in a module just reads "generates a decorator which applies
 to the given arguments", that's useless documentation.

Which brings me to the other half of the point I was trying to make:
your decorator_with_args doesn't even *need* a docstring. It's not
part of the public interface. As a nested function that doesn't have
its own name within the module, help() or pydoc won't even include it
in their output. If you want to put something in the code to explain
what it does, that's fine, but use a comment for that. The docstring
doesn't add any value.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Special attributes added to classes on creation

2016-07-03 Thread eryk sun

On Sun, Jul 3, 2016 at 4:02 PM, Steven D'Aprano  wrote:
> Is there any documentation for exactly what keys are added to classes when?

It should be documented that the namespace that's passed to the
metaclass contains __module__ and __qualname__, and optionally __doc__
if the class has a docstring.

These names are also available as local variables while executing the
class body:

>>> class C:
... 'eggs and spam'
... print('__module__:', __module__)
... print('__qualname__:', __qualname__)
... print('__doc__:', __doc__)
...
__module__: __main__
__qualname__: C
__doc__: eggs and spam

This is potentially an (unlikely) issue because the class body
preamble overwrites whatever custom values of these attributes were
added by the metaclass __prepare__ method. For example:

class Meta(type):
@classmethod
def __prepare__(mcls, name, bases, **kwds):
return {'__module__': 'spam',
'__qualname__': 'eggs.spam.' + name,
'__doc__': 'spam spam spam',
'x': 42}

class C(metaclass=Meta):
'docstring'

>>> C.__module__
'__main__'
>>> C.__qualname__
'C'
>>> C.__doc__
'docstring'
>>> C.x
42

I don't think additional documentation is required for the __dict__
and __weakref__ descriptors. They're described with respect to
__slots__. They can't be added until after the metaclass processes
__slots__, if present.

You can begin unraveling how CPython 3.x class creation works by
disassembling the bytecode for the following example:

def f():
class Q(Base, metaclass=Meta):
'example class'
x = 1
def method(self):
__class__ # or use super()

The initial work of defining a class is implemented via
builtins.__build_class__, which is referenced by the bytecode
instruction LOAD_BUILD_CLASS. This built-in function takes two
required positional arguments: the argumentless function that
implements the class body and the class name. Optionally, the base
class(es) are passed as the remaining positional arguments, and the
metaclass is passed as a keyword argument. Additional keyword
arguments can be passed in the class statement, but this requires a
custom metaclass with __new__ and __init__ methods that accept the
extra arguments. The metaclass __prepare__ method also gets passed the
name, bases and extra keyword arguments.

Here's the bytecode setup to call __build_class__ for the above example:

>>> dis.dis(f)
20 LOAD_BUILD_CLASS
 2 LOAD_CONST  1 ()
 4 LOAD_CONST  2 ('Q')
 6 MAKE_FUNCTION   0
 8 LOAD_CONST  2 ('Q')
10 LOAD_GLOBAL 0 (Base)
12 LOAD_CONST  3 ('metaclass')
14 LOAD_GLOBAL 1 (Meta)
16 EXTENDED_ARG1
18 CALL_FUNCTION 259 (3 positional,
  1 keyword pair)
20 STORE_FAST  0 (Q)

22 LOAD_CONST  0 (None)
24 RETURN_VALUE

The locals mapping for the class body comes from the metaclass
__prepare__ method, if defined, and is otherwise an empty dict.
There's a default type.__prepare__, which returns an empty dict:

>>> type.__prepare__(1, 2, 3, spam='whatever')
{}

The code for the class body defines the __module__, __qualname__, and
__doc__ attributes. It also defines the __class__ closure when a class
has methods that use super() or reference __class__.

The return value of the class body is either the __class__ cell
object, if defined, or None. Returning the __class__ closure cell
allows __build_class__  to set the new class as the value of the cell.

Here's the bytecode for the body of class Q:

>>> dis.dis(f.__code__.co_consts[1])
20 LOAD_NAME   0 (__name__)
 2 STORE_NAME  1 (__module__)
 4 LOAD_CONST  0 ('f..Q')
 6 STORE_NAME  2 (__qualname__)
38 LOAD_CONST  1 ('example class')
10 STORE_NAME  3 (__doc__)
4   12 LOAD_CONST  2 (1)
14 STORE_NAME  4 (x)
5   16 LOAD_CLOSURE0 (__class__)
18 BUILD_TUPLE 1
20 LOAD_CONST  3 ()
22 LOAD_CONST  4 ('f..Q.method')
24 MAKE_FUNCTION   8
26 STORE_NAME  5 (method)
28 LOAD_CLOSURE0 (__class__)
30 RETURN_VALUE

>>> f.__code__.co_consts[1].co_cellvars
('__class__',)

The rest of the process is all written in C.

compiler_class, which compiles a class statement to the above bytecode:
https://hg.python.org/cpython/file/v3.6.0a2/Python/compile.c#l1809

builtins.__build_class__:
https://hg.python.org/cpython/file/v3.6.0a2/Python/bltinmodule.c#l53

type.__new__:
https://hg.python.org/cpython/file/v3.6.0a2/Objects/typeobject.c#l2268

In ty

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote:
> If the problem with using classes to satisfy the namespace need is
> that it's unwieldy to use dot qualified paths then isn't that quite similar
> to saying namespaces are unwieldy?

Python has a simple solution to that:

a = mod.a
b = mod.b

etc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
> Sorry, but you're the one who doesn't seem to get it. Because it's a
> decorator, "your" function is replacing the caller's function in the
> caller's namespace.

No it is not. The replacement happens here:

def generated_decorator(func) :
return \
decorator(func, *args, **kwargs)
#end generated_decorator

As you can see, the function being called, “decorator”, is supplied by the 
caller. The function being decorated, “func”, is supplied by the caller (along 
with the additional *args and **kwargs). And the returned function is returned 
*as-is*, so whatever docstring was assigned by the caller is *NOT* “clobbered”.

Once again, the only docstrings I am setting are the ones for functions that 
*I* generate.

Do you understand that yet?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Mon, Jul 4, 2016 at 9:25 AM, Lawrence D’Oliveiro
 wrote:
> On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
>> Sorry, but you're the one who doesn't seem to get it. Because it's a
>> decorator, "your" function is replacing the caller's function in the
>> caller's namespace.
>
> No it is not. The replacement happens here:
>
> def generated_decorator(func) :
> return \
> decorator(func, *args, **kwargs)
> #end generated_decorator
>
> As you can see, the function being called, “decorator”, is supplied by the 
> caller. The function being decorated, “func”, is supplied by the caller 
> (along with the additional *args and **kwargs). And the returned function is 
> returned *as-is*, so whatever docstring was assigned by the caller is *NOT* 
> “clobbered”.
>
> Once again, the only docstrings I am setting are the ones for functions that 
> *I* generate.
>
> Do you understand that yet?

Yes, in a technical sense, you are correct. It's also technically
correct to say that str.upper() doesn't convert its argument to
uppercase - it constructs a completely new string of all uppercase
letters. But in normal usage, people expect "x = x.upper()" to return
*the same string, uppercased*. In the same way, people expect "f =
deco(f)" to return *the same function, decorated*. Technically it's
generally going to be a new function, because functions are immutable
(more-or-less), but it should broadly be the same function.

def require_login(f):
def modified(*a, **kw):
if not logged_in:
return "You must be logged in to do this."
return f(*a, **kw)
return modified

@require_login
def fire_ze_missiles():
raise Exhausted

@require_login
def reboot_server(server):
"""Reboot the specified server"""
server.send_command("sudo reboot")

Tell me, should the docstring for reboot_server be "Reboot the
specified server", or not? If not, why not?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread eryk sun

On Sun, Jul 3, 2016 at 6:58 AM, John Ladasky  wrote:
> The nabla symbol (∇) is used in the naming of gradients. Python isn't having 
> it.
> The interpreter throws a "SyntaxError: invalid character in identifier" when 
> it
> encounters the ∇.

Del is a mathematical operator to take the gradient. It's not part of
the name. For `∇f`, the operator is `∇` and the function name is `f`.
Python lacks a mechanism to add user-defined operators. (R has this
capability.) Maybe this feature could be added. To make parsing
simple, user-defined operators could be limited to non-ASCII symbol
characters (math and other -- Sm, So). That simple option is off the
table if we allow symbol characters in names.

Adding an operator to the language itself requires a PEP. Recently PEP
465 added an `@` operator for matrix products. For example:

>>> x = np.array([1j, 1])
>>> x @ x
0j
>>> x @ x.conj() # Hermitian inner product
(2+0j)

Note that using a non-ASCII operator was ruled out:

http://legacy.python.org/dev/peps/pep-0465/#choice-of-operator
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Monday, July 4, 2016 at 11:39:56 AM UTC+12, Chris Angelico wrote:
> In the same way, people expect "f = deco(f)" to return *the same function,
> decorated*.

I am not changing that in anyway. The decorated function generated by the 
caller is returned *unchanged*.

Once again, the only docstrings I am setting are for the intermediate functions 
*I* generate.

Suppose we have the following:

def try_func(func, arg) :
"sample function to be turned into a decorator."

def result() :
"returns func unchanged."
return \
func()
#end result

#begin try_func
result.__name__ = func.__name__
result.__doc__ = func.__doc__
return \
result
#end try_func

then:

>>> f = decorator_with_args(try_func)
>>> help(f)
Help on function decorate_with_try_func in module decorator_try:

decorate_with_try_func(*args, **kwargs)
generates a decorator which applies try_func to the given arguments

>>> @f(None)
... def g() :
... "my docstring--should be unchanged."
... return \
... 1
... #end g
... 
>>> help(g)
Help on function g in module decorator_try:

g()
my docstring--should be unchanged.

Do you understand now?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lost in descriptor land

2016-07-03 Thread eryk sun

On Sun, Jul 3, 2016 at 3:32 PM, Steven D'Aprano  wrote:
>
> But if you prepare the method ahead of time, it works:
>
> from types import MethodType
> instance.method = MethodType(method, instance)

That's a fine way to bind a method, but in the context of this
"descriptor land" topic, I think it's more insightful to call the
function's __get__ method:

>>> type(method)

>>> instance.method = method.__get__(instance)
>>> type(instance.method)

>>> instance.method.__self__ is instance
True
>>> instance.method.__func__ is method
True
>>> instance.method()
method called from self <__main__.Test object at 0x7faf51d1a198>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Sun, Jul 3, 2016 at 5:25 PM, Lawrence D’Oliveiro
 wrote:
> On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
>> Sorry, but you're the one who doesn't seem to get it. Because it's a
>> decorator, "your" function is replacing the caller's function in the
>> caller's namespace.
>
> No it is not. The replacement happens here:
>
> def generated_decorator(func) :
> return \
> decorator(func, *args, **kwargs)
> #end generated_decorator
>
> As you can see, the function being called, “decorator”, is supplied by the 
> caller. The function being decorated, “func”, is supplied by the caller 
> (along with the additional *args and **kwargs). And the returned function is 
> returned *as-is*, so whatever docstring was assigned by the caller is *NOT* 
> “clobbered”.

I'm talking about the docstring of the *decorator*, not func. I agree
that whatever docstring func has is entirely up to func and the
decorator, not your code. Here again is the example I posted earlier:

>>> @decorator_with_args
... def my_decorator(func, *args, **kwargs):
... """Returns func unmodified."""
... return func
...
>>> my_decorator.__doc__
'generates a decorator which applies my_decorator to the given arguments'

I never made any claim about the docstring of the decorated func.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
> Python lacks a mechanism to add user-defined operators. (R has this
> capability.) Maybe this feature could be added.

That would be neat. But remember, you would have to define the operator 
precedence as well. So you could no longer use a recursive-descent parser.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Mon, Jul 4, 2016 at 9:59 AM, Lawrence D’Oliveiro
 wrote:
> #begin try_func
> result.__name__ = func.__name__
> result.__doc__ = func.__doc__
> return \
> result
> #end try_func

This is the bit we're talking about. You're doing manually what
functools.wraps does for you (and it does other stuff too, to make
help() more useful), and you weren't doing this before.

Your original docstring on result() is completely ignored.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Monday, July 4, 2016 at 12:02:23 PM UTC+12, Ian wrote:
> I'm talking about the docstring of the *decorator*, not func.

*Sigh*. Originally somebody was complaining that the lambda version didn’t 
allow for good (or any) docstrings. So I posted my version, and I went to all 
the effort of ensuring that every generated function had a good docstring. And 
now you are trying to knock me down for that?

What the hell is wrong with you people?!?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of


On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:

On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:

Python lacks a mechanism to add user-defined operators. (R has this
capability.) Maybe this feature could be added.


That would be neat. But remember, you would have to define the operator 
precedence as well. So you could no longer use a recursive-descent parser.


That wouldn't be a problem provided the new operator symbol and its 
precedence is known at a compile time, and defined before use.



--
Bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea


On 04/07/2016 00:21, Lawrence D’Oliveiro wrote:

On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote:

If the problem with using classes to satisfy the namespace need is
that it's unwieldy to use dot qualified paths then isn't that quite similar
to saying namespaces are unwieldy?


Python has a simple solution to that:

a = mod.a
b = mod.b


Except that then

 a = 0

doesn't do the same thing as:

 mod.a = 0

But it'll probably work for things that are not assigned to.

--
Bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Sun, Jul 3, 2016 at 6:06 PM, Lawrence D’Oliveiro
 wrote:
> On Monday, July 4, 2016 at 12:02:23 PM UTC+12, Ian wrote:
>> I'm talking about the docstring of the *decorator*, not func.
>
> *Sigh*. Originally somebody was complaining that the lambda version didn’t 
> allow for good (or any) docstrings. So I posted my version, and I went to all 
> the effort of ensuring that every generated function had a good docstring. 
> And now you are trying to knock me down for that?
>
> What the hell is wrong with you people?!?

Sorry. I don't know who that was or what they wrote, because your post
is the first mention of docstrings that I see in this thread. Maybe
you're thinking of some other thread. I don't read more than a
fraction of what gets posted to this list.

But I read your post and I saw a way to improve the code in it, so I
suggested it. Next time I won't bother.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

On Monday, July 4, 2016 at 12:06:21 PM UTC+12, Chris Angelico wrote:
> On Mon, Jul 4, 2016 at 9:59 AM, Lawrence D’Oliveiro wrote:
>> #begin try_func
>> result.__name__ = func.__name__
>> result.__doc__ = func.__doc__
>> return \
>> result
>> #end try_func
> 
> This is the bit we're talking about.

This isn’t part of my decoration mechanism, this is just an example of it in 
use.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 12:17:47 PM UTC+12, BartC wrote:
>
> On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
>>
>> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
>>>
>>> Python lacks a mechanism to add user-defined operators. (R has this
>>> capability.) Maybe this feature could be added.
>>
>> That would be neat. But remember, you would have to define the operator
>> precedence as well. So you could no longer use a recursive-descent parser.
> 
> That wouldn't be a problem provided the new operator symbol and its 
> precedence is known at a compile time, and defined before use.

That is how it is normally done. (E.g. Algol 68.)

But you still couldn’t use a recursive-descent parser.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of


On 04/07/2016 01:24, Lawrence D’Oliveiro wrote:

On Monday, July 4, 2016 at 12:17:47 PM UTC+12, BartC wrote:


On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:


On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:


Python lacks a mechanism to add user-defined operators. (R has this
capability.) Maybe this feature could be added.


That would be neat. But remember, you would have to define the operator
precedence as well. So you could no longer use a recursive-descent parser.


That wouldn't be a problem provided the new operator symbol and its
precedence is known at a compile time, and defined before use.


That is how it is normally done. (E.g. Algol 68.)

But you still couldn’t use a recursive-descent parser.


Why not?

The structure of such a parser doesn't need to exactly match the grammar 
with a dedicated block of code for each operator precedence. It can be 
table-driven so that an operator precedence value is just an attribute.


--
Bartc



--
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote:
> The structure of such a parser doesn't need to exactly match the grammar 
> with a dedicated block of code for each operator precedence. It can be 
> table-driven so that an operator precedence value is just an attribute.

Of course. But that’s not a recursive-descent parser any more.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lost in descriptor land

On Mon, 4 Jul 2016 09:59 am, eryk sun wrote:

> On Sun, Jul 3, 2016 at 3:32 PM, Steven D'Aprano 
> wrote:
>>
>> But if you prepare the method ahead of time, it works:
>>
>> from types import MethodType
>> instance.method = MethodType(method, instance)
> 
> That's a fine way to bind a method, but in the context of this
> "descriptor land" topic, I think it's more insightful to call the
> function's __get__ method:

Sure, so long as you remember that in real code you shouldn't be calling
dunder methods directly. I don't know whether Python does any pre- or
post-processing of a descriptor's __get__ method, but it could (if not now,
but in the future).

-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Random832

On Sun, Jul 3, 2016, at 20:00, Lawrence D’Oliveiro wrote:
> That would be neat. But remember, you would have to define the operator
> precedence as well. So you could no longer use a recursive-descent
> parser.

You could use a recursive-descent parser if you monkey-patch the parser
when adding a new operator.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

2016-07-03 Thread Random832

On Sun, Jul 3, 2016, at 21:15, Lawrence D’Oliveiro wrote:
> On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote:
> > The structure of such a parser doesn't need to exactly match the grammar 
> > with a dedicated block of code for each operator precedence. It can be 
> > table-driven so that an operator precedence value is just an attribute.
> 
> Of course. But that’s not a recursive-descent parser any more.

It's still recursive descent if it, for example, calls the _same_ block
of code recursively with arguments to tell it which operator is being
considered. This would be analogous to, in Python, implementing a
recursive-descent parser with arbitrary callable objects instead of
simple functions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Mon, 4 Jul 2016 10:17 am, BartC wrote:

> On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
>> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
>>> Python lacks a mechanism to add user-defined operators. (R has this
>>> capability.) Maybe this feature could be added.
>>
>> That would be neat. But remember, you would have to define the operator
>> precedence as well. So you could no longer use a recursive-descent
>> parser.
> 
> That wouldn't be a problem provided the new operator symbol and its
> precedence is known at a compile time, and defined before use.

You're still having problems with the whole Python-as-a-dynamic-language
thing, aren't you? :-)

In full generality, you would want to be able to define unary prefix, unary
suffix and binary infix operators, and set their precedence and whether
they associate to the left or the right. That's probably a bit much to
expect.

But if we limit ourselves to the boring case of binary infix operators of a
single precedence and associtivity, there's a simple approach: the parser
can allow any unicode code point of category "Sm" as a legal operator, e.g.
x ∇ y. Pre-defined operators like + - * etc continue to call the same
dunder methods they already do, but anything else tries calling:

x.__oper__('∇', y)
y.__roper__('∇', x)

and if neither of those exist and return a result other than NotImplemented,
then finally raise a runtime TypeError('undefined operator ∇').

But I don't think this will ever be part of Python.

-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of