Rustom Mody writes:
> Subscripts OTOH as part of identifier-lexemes doesn't seem to have any
> issues
They have the general issue that one might *want* them interpreted as
indexes, so that a₁ would mean the same as a[1].
Mathematical symbols face similar issues. One would not *want* them all
be
On Monday, July 4, 2016 at 8:03:47 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote:
>
> > 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
Hello,
I have a query regarding the support of decompression for Unix compressed .Z
files in Python's gzip module. The gzip system utility supports this using the
'-d' switch, but the python module does not.
Obviously this isn't an actual bug, as the Python module is an implementation
of the z
On 07/03/2016 03:02 PM, Kevin Conway wrote:
>At some point earlier Ethan Furman declared:
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.
On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote:
> 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
>
>
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
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
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 n
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
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
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
capa
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
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
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) docstrin
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 oper
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?
P
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 ensurin
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.
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
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
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
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 docstring
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. I
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
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
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 =
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.
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
>> 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 dot
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
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
[...
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,
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 cus
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 call
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 t
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 philosop
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 ch
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=proc
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
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
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 T
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/py
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
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
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
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
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_
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?
More
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.
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 o
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:/
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 mos
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 inste
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: P
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/l
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
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
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 deli
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
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 =
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 th
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
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 b
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
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.
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
66 matches
Mail list logo
