BartC :
> Usually anything that is defined can be changed at run-time so that the
> compiler can never assume anything.
The compiler can't assume anything permanent, but it could heuristically
make excellent guesses at runtime. It needs to verify its guesses at the
boundaries of compiled code and
On 04/07/2016 15:46, Ned Batchelder wrote:
On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote:
On 04/07/2016 13:47, Ned Batchelder wrote:
This is a huge change.
I've used a kind of 'weak' import scheme elsewhere, corresponding to C's
'#include'.
I think that could work in Python p
On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote:
> On 04/07/2016 13:47, Ned Batchelder wrote:
> > On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
> >> On 04/07/2016 03:30, Steven D'Aprano wrote:
>
> >>> You're still having problems with the whole Python-as-a-dynamic-language
>
On 04/07/2016 13:47, Ned Batchelder wrote:
On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
On 04/07/2016 03:30, Steven D'Aprano wrote:
You're still having problems with the whole Python-as-a-dynamic-language
thing, aren't you? :-)
Most Pythons seem to pre-compile code before exec
On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
> On 04/07/2016 03:30, Steven D'Aprano wrote:
> > 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 m
On Monday, July 4, 2016 at 3:56:43 PM UTC+5:30, BartC wrote:
> On 04/07/2016 02: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 o
BartC writes:
> A simpler approach is to treat user-defined operators as aliases for
> functions:
>
> def myadd(a,b):
> return a+b
>
> operator ∇:
>(myadd,2,+3) # map to myadd, 2 operands, prio 3, LTR
>
> x = y ∇ z
>
> is then equivalent to:
>
> x = myadd(y,z)
>
> However you will usua
On 04/07/2016 02: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
Lawrence D’Oliveiro writes:
> On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
>> Something could be done, but if the intention is to allow
>> mathematical notation, it needs to be done with care.
>
> Mathematics uses single-character variable names so that
> multiplication c
On 04/07/2016 03:30, Steven D'Aprano wrote:
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 feat
Lawrence D’Oliveiro :
> Mathematics uses single-character variable names so that
> multiplication can be implicit.
I don't think anybody developed mathematical notation systematically.
Rather, over the centuries, various masters came up with personal
abbreviations and shorthand, which spread amon
On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
> Something could be done, but if the intention is to allow
> mathematical notation, it needs to be done with care.
Mathematics uses single-character variable names so that multiplication can be
implicit.
An old, stillborn la
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
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 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 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 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 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 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 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
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
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
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 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
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
49 matches
Mail list logo
