Re: [Python-ideas] π = math.pi

[Stephan Houben]

Hi Joshua,

> A `op` B
>
> is equivalent to
>
> op(A, B

This can of course be faked in Python.

https://gist.github.com/stephanh42/a4d6d66b10cfecf935c9531150afb247

Now you can do:


@BinopCallable
def add(x, y):
  return x + y

print(3 @add@ 5)
===

Stephan

2017-06-03 7:59 GMT+02:00 Joshua Morton :
> For reference, haskell is perhaps the closest language to providing
> arbitrary infix operators, and it requires that they be surrounded by
> backticks. That is
>
> A `op` B
>
> is equivalent to
>
> op(A, B)
>
> That doesn't work for python (backtick is taken) and I don't think anything
> similar is a good idea.
>
> On Sat, Jun 3, 2017 at 1:56 AM Chris Angelico  wrote:
>>
>> On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy  wrote:
>> > Sorry for probably stupid question! Is something like ->
>> >
>> > class A:
>> > def __oper__(self, '⊞', other):
>> > return something(self.value, other)
>> >
>> > a = A()
>> > a ⊞ 3
>> >
>> > thinkable?
>>
>> No, because operators need to be defined before you get to individual
>> objects, and they need precedence and associativity. So it'd have to
>> be defined at the compiler level.
>>
>> Also, having arbitrary operators gets extremely confusing. It's not
>> easy to reason about code when you don't know what's even an operator.
>>
>> Not a stupid question, but one for which the answer is "definitely not
>> like that".
>>
>> ChrisA
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Pavol Lisy]

On 6/1/17, Serhiy Storchaka  wrote:
> What you are think about adding Unicode aliases for some mathematic
> names in the math module? ;-)
>
> math.π = math.pi
> math.τ = math.tau
> math.Γ = math.gamma
> math.ℯ = math.e
>
> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(

My humble opinion: I would rather like to see something like:

from some_wide_used_scientific_library.math_constants import *

with good acceptance from scientific users before thinking to add it
into stdlib.

PS.
Maybe this could be interesting for some vim users ->
http://gnosis.cx/bin/.vim/after/syntax/python.vim (I am not author of
this file)

If you apply it in vim then vim show lines (where is not cursor)
"translated". Means for example that math.pi is replaced by π.

So you still edit "math.pi" but if you move cursor outside of this
line then you could see formula simplified/prettified. (or more
complicated - because you need a little train your brain to accept new
view)

I am pretty skeptic how popular this conceal technique could be in vim
pythonistas community!

(
why skeptic?
For example I am testing to improve readability of line similar to

   self.a = self.b + self.c

using with this technique and see in vim

   ᐠa = ᐠb + ᐠc

but **I am not sure if it is really useful** (probably I have to add
that I am editing code much more in other editor than vim)

ᐠ U+1420 CANADIAN SYLLABICS FINAL GRAVE
)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Joshua Morton]

For reference, haskell is perhaps the closest language to providing
arbitrary infix operators, and it requires that they be surrounded by
backticks. That is

A `op` B

is equivalent to

op(A, B)

That doesn't work for python (backtick is taken) and I don't think anything
similar is a good idea.

On Sat, Jun 3, 2017 at 1:56 AM Chris Angelico  wrote:

> On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy  wrote:
> > Sorry for probably stupid question! Is something like ->
> >
> > class A:
> > def __oper__(self, '⊞', other):
> > return something(self.value, other)
> >
> > a = A()
> > a ⊞ 3
> >
> > thinkable?
>
> No, because operators need to be defined before you get to individual
> objects, and they need precedence and associativity. So it'd have to
> be defined at the compiler level.
>
> Also, having arbitrary operators gets extremely confusing. It's not
> easy to reason about code when you don't know what's even an operator.
>
> Not a stupid question, but one for which the answer is "definitely not
> like that".
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Chris Angelico]

On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy  wrote:
> Sorry for probably stupid question! Is something like ->
>
> class A:
> def __oper__(self, '⊞', other):
> return something(self.value, other)
>
> a = A()
> a ⊞ 3
>
> thinkable?

No, because operators need to be defined before you get to individual
objects, and they need precedence and associativity. So it'd have to
be defined at the compiler level.

Also, having arbitrary operators gets extremely confusing. It's not
easy to reason about code when you don't know what's even an operator.

Not a stupid question, but one for which the answer is "definitely not
like that".

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Pavol Lisy]

Sorry for probably stupid question! Is something like ->

class A:
def __oper__(self, '⊞', other):
return something(self.value, other)

a = A()
a ⊞ 3

thinkable?

On 6/3/17, Guido van Rossum  wrote:
> OK, I think this discussion is pretty much dead then. We definitely
> shouldn't allow math operators in identifiers, otherwise in Python 4 or 5
> we couldn't introduce them as operators.
>
> On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano 
> wrote:
>
>> On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
>>
>> > Are those characters not considered Unicode letters? Maybe we could add
>> > their category to the allowed set?
>>
>> They're not letters:
>>
>> py> {unicodedata.category(c) for c in '∑√∫∞'}
>> {'Sm'}
>>
>>
>> That's Symbol, Math.
>>
>> One problem is that the 'Sm' category includes a whole lot of
>> mathematical symbols that we probably don't want in identifiers:
>>
>> ∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞  (plus MANY more variations on = < and > operators)
>>
>> including some "Confusables":
>>
>> ∁ ∊ ∨ ∗ ∑ etc
>>
>> C ε v * Σ
>>
>> http://www.unicode.org/reports/tr39/
>>
>> Of course a language can define identifiers however it likes, but I
>> think it is relevant that the Unicode Consortium's default algorithm for
>> determining an identifier excludes Sm.
>>
>> http://www.unicode.org/reports/tr31/
>>
>> I also disagree with Ivan that these symbols would be particularly
>> useful in general, even for maths-heavy code, although I wouldn't say no
>> to special casing ∞ (infinity) and maybe √ as a unary square root
>> operator.
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Greg Ewing]

Steven D'Aprano wrote:

There's not much, if any, benefit to writing:

∫(expression, lower_limit, upper_limit, name)


More generally, there's a kind of culture clash between mathematical
notation and programming notation. Mathematical notation tends to
almost exclusively use single-character names, relying on different
fonts and alphabets, and superscripts and subscripts, to get a large
enough set of identifiers. Whereas in programming we use a much
smaller alphabet and longer names. Having terse symbols for just a
few things, and having to spell everything else out longhand, doesn't
really help.

--
Greg

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Terry Reedy]

On 6/2/2017 7:56 PM, Ivan Levkivskyi wrote:
On 3 June 2017 at 01:29, Guido van Rossum 
> wrote:


Are those characters not considered Unicode letters? Maybe we could
add their category to the allowed set?


Yes, they are not considered letters, they are in category Sm.


I presume that is Symbol - math.

Unfortunately, +, -, |, and other symbol that clearly should not be in 
identifiers are also in this category,
so we cannot add the whole category. It is possible to include 
particular ranges,


Having to test ranges will slow down identifier recognition.


but there should be a discussion
about what exactly can/should be included.


I believe the current python definition of 'identifier' is taken from 
the Unicode Standard for default identifiers.  Any change would have to 
be propagated to regex engines, IDEs, and anything else that parses 
python.  I suggest that you ask Martin Loewis for his opinion on 
changing the identifier definition.


--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Chris Angelico]

On Sat, Jun 3, 2017 at 10:38 AM, Juancarlo Añez  wrote:
> Speaking of which, it would be convenient to be able to build strings with
> non-ascii characters using their Unicode codepoint name:
>
> greek_pi = "\u:greek_small_letter_pi"
>
> Or something like that.

You mean:

>>> greek_pi = "\N{GREEK SMALL LETTER PI}"
>>> greek_pi
'π'

Time machine strikes again :)

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Juancarlo Añez]

On Fri, Jun 2, 2017 at 7:29 PM, Guido van Rossum  wrote:

Are those characters not considered Unicode letters? Maybe we could add
> their category to the allowed set?

Speaking of which, it would be convenient to be able to build strings with
non-ascii characters using their Unicode codepoint name:

greek_pi = "\u:greek_small_letter_pi"

Or something like that.
​
-- 
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

OK, I think this discussion is pretty much dead then. We definitely
shouldn't allow math operators in identifiers, otherwise in Python 4 or 5
we couldn't introduce them as operators.

On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano  wrote:

> On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
>
> > Are those characters not considered Unicode letters? Maybe we could add
> > their category to the allowed set?
>
> They're not letters:
>
> py> {unicodedata.category(c) for c in '∑√∫∞'}
> {'Sm'}
>
>
> That's Symbol, Math.
>
> One problem is that the 'Sm' category includes a whole lot of
> mathematical symbols that we probably don't want in identifiers:
>
> ∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞  (plus MANY more variations on = < and > operators)
>
> including some "Confusables":
>
> ∁ ∊ ∨ ∗ ∑ etc
>
> C ε v * Σ
>
> http://www.unicode.org/reports/tr39/
>
> Of course a language can define identifiers however it likes, but I
> think it is relevant that the Unicode Consortium's default algorithm for
> determining an identifier excludes Sm.
>
> http://www.unicode.org/reports/tr31/
>
> I also disagree with Ivan that these symbols would be particularly
> useful in general, even for maths-heavy code, although I wouldn't say no
> to special casing ∞ (infinity) and maybe √ as a unary square root
> operator.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Steven D'Aprano]

On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:

> Are those characters not considered Unicode letters? Maybe we could add
> their category to the allowed set?

They're not letters:

py> {unicodedata.category(c) for c in '∑√∫∞'}
{'Sm'}


That's Symbol, Math.

One problem is that the 'Sm' category includes a whole lot of 
mathematical symbols that we probably don't want in identifiers:

∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞  (plus MANY more variations on = < and > operators)

including some "Confusables":

∁ ∊ ∨ ∗ ∑ etc

C ε v * Σ

http://www.unicode.org/reports/tr39/

Of course a language can define identifiers however it likes, but I 
think it is relevant that the Unicode Consortium's default algorithm for 
determining an identifier excludes Sm.

http://www.unicode.org/reports/tr31/

I also disagree with Ivan that these symbols would be particularly 
useful in general, even for maths-heavy code, although I wouldn't say no 
to special casing ∞ (infinity) and maybe √ as a unary square root 
operator.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Ivan Levkivskyi]

On 3 June 2017 at 01:29, Guido van Rossum  wrote:

> Are those characters not considered Unicode letters? Maybe we could add
> their category to the allowed set?
>
>
Yes, they are not considered letters, they are in category Sm.
Unfortunately, +, -, |, and other symbol that clearly should not be in
identifiers are also in this category,
so we cannot add the whole category. It is possible to include particular
ranges, but there should be a discussion
about what exactly can/should be included.

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Steven D'Aprano]

On Sat, Jun 03, 2017 at 01:02:12AM +0200, Ivan Levkivskyi wrote:
> On 3 June 2017 at 00:55, Guido van Rossum  wrote:
> 
> > [...]
> > So, I am still in favor of the rule "only ASCII in the stdlib".
> >
> 
> But what about the other question? Currently, integral, sum, infinity,
> square root etc. Unicode symbols are all prohibited in identifiers.
> Is it possible to allow them?

In the last few months, I've been making a lot of use of the TI Nspire 
CAS calculator, and I think that there is very little benefit to 
allowing symbols like ∑ √ ∫ (sum, radical/root, integral) unless you 
have a proper 2-dimensional template system.

There's not much, if any, benefit to writing:

∫(expression, lower_limit, upper_limit, name)

In fact, that's probably *harder* to read than 

integrate(expression, lower_limit, upper_limit, name)

because the important thing, the fact that this is an integral, is 
barely visible. Its only a single character. That's not how 
mathematicians write it!

If we had a 2D template system, like the Nspire, we could write what 
mathematicians do:

(best viewed with a non-proportional font)

   b
 ⌠ 
 ⎮  3  21
 ⎮ x  + 2 x  − ─── dx
 ⎮  x
 ⌡
   a


I say "best", but of course even with a monospaced font, it still looks 
pretty awful. You really need a proper GUI interface and support for 
resizing characters.

I'm not suggesting this be part of Python the language! But It might be 
a nice application written for users of Python, perhaps part of Sage or 
IPython/Jupiter or a GUI interface to Sympy. You don't need ∫ to be 
legal in identifies for that.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Matthias Bussonnier]

> (Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it 
> is very easy to remember)

IPython dev here. I am the one who implemented (most of) that. We do
support it, but it's not easy to
remember unless you know how to write latex, and know said character.

Question, how would you type the following:

In [3]: ℸ = 1

Hint it's easy it's \CHARACTERNAME, but if you don't know how ℸ
is named[1], you are screwed[3].
It's cute, it's compact, it's extremely useful for some internal code,
but _exporting_ this as an interface is
IMHO an extremely bad idea that hinders readability[2] and usability
of the code.



On Fri, Jun 2, 2017 at 4:29 PM, Guido van Rossum  wrote:
> Are those characters not considered Unicode letters? Maybe we could add
> their category to the allowed set?

+1 on allowing more of math symbols and be more flexible on allowed
identifiers though.
In particular the one mentioned above are part of mathematical operators[4].

It also would be great for some of these to be parsed as infix
operators, but that's another topic :-)

-- 
M

[1]  \daleth
[2] and that's assuming your font support said character.
[3] Tab completion on full unicode character name does work as well so
\GREEK SMALL LETTER GAMMA will give you γ. And \γ will
expand to \gamma, so you can figure it out, but users still struggle
for unknown symbols
[4] 
http://www.fileformat.info/info/unicode/block/mathematical_operators/images.htm

On Fri, Jun 2, 2017 at 4:02 PM, Ivan Levkivskyi  wrote:
> On 3 June 2017 at 00:55, Guido van Rossum  wrote:
>>
>> [...]
>> So, I am still in favor of the rule "only ASCII in the stdlib".
>
>
> But what about the other question? Currently, integral, sum, infinity,
> square root etc. Unicode symbols are all prohibited in identifiers.
> Is it possible to allow them?
>
> (Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it
> is very easy to remember)
>
> --
> Ivan
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

Are those characters not considered Unicode letters? Maybe we could add
their category to the allowed set?

On Jun 2, 2017 4:02 PM, "Ivan Levkivskyi"  wrote:

> On 3 June 2017 at 00:55, Guido van Rossum  wrote:
>
>> [...]
>> So, I am still in favor of the rule "only ASCII in the stdlib".
>>
>
> But what about the other question? Currently, integral, sum, infinity,
> square root etc. Unicode symbols are all prohibited in identifiers.
> Is it possible to allow them?
>
> (Btw IPython just supports normal TeX notations like \pi, \lambda etc, so
> it is very easy to remember)
>
> --
> Ivan
>
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Ivan Levkivskyi]

On 3 June 2017 at 00:55, Guido van Rossum  wrote:

> [...]
> So, I am still in favor of the rule "only ASCII in the stdlib".
>

But what about the other question? Currently, integral, sum, infinity,
square root etc. Unicode symbols are all prohibited in identifiers.
Is it possible to allow them?

(Btw IPython just supports normal TeX notations like \pi, \lambda etc, so
it is very easy to remember)

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

I would love to show how easy it is to write

from math import pi as π, gamma as Γ

but I had to cheat by copying from the OP since I don't know how to type
these (and even if you were to tell me how I'd forget tomorrow). So, I am
still in favor of the rule "only ASCII in the stdlib".

On Fri, Jun 2, 2017 at 3:48 PM, Ivan Levkivskyi 
wrote:

> On 2 June 2017 at 12:17, Giampaolo Rodola'  wrote:
>
>> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka 
>> wrote:
>>
>>> What you are think about adding Unicode aliases for some mathematic
>>> names in the math module? ;-)
>>>
>>> math.π = math.pi
>>> math.τ = math.tau
>>> math.Γ = math.gamma
>>> math.ℯ = math.e
>>>
>>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>>>
>>> [...]
>> * duplicated aliases might make sense if they add readability; in this
>> case they don't unless (maybe) you have a mathematical background. I can
>> infer what "math.gamma" stands for but not being a mathematician math.Γ
>> makes absolutely zero sense to me.
>>
>>
> There is a significant number of scientific Python programmers (21%
> according to PyCharm 2016), so it is not that rare to meet someone who
> knows what is Gamma function.
> And for many of them π is much more readable than np.pi. Also there is
> another problem, confusion between Gamma function and Euler–Mascheroni
> constant, the first one is Γ,
> the second one is γ (perfectly opposite to PEP 8 capitalization rules :-),
> while both of them are frequently denoted as just gamma (in particular
> math.gamma follows the PEP8 rules,
> but is counter-intuitive for most scientist).
>
> All that said, I agree that these problems are easily solved by a custom
> import from. Still there is something in (or related to?) this proposal
> I think is worth considering: Can we also allow identifiers like ∫ or √.
> This will make many expressions more similar to usual TeX,
> plus it will be useful for projects like SymPy.
>
> --
> Ivan
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Ivan Levkivskyi]

On 2 June 2017 at 12:17, Giampaolo Rodola'  wrote:

> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka 
> wrote:
>
>> What you are think about adding Unicode aliases for some mathematic names
>> in the math module? ;-)
>>
>> math.π = math.pi
>> math.τ = math.tau
>> math.Γ = math.gamma
>> math.ℯ = math.e
>>
>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>>
>> [...]
> * duplicated aliases might make sense if they add readability; in this
> case they don't unless (maybe) you have a mathematical background. I can
> infer what "math.gamma" stands for but not being a mathematician math.Γ
> makes absolutely zero sense to me.
>
>
There is a significant number of scientific Python programmers (21%
according to PyCharm 2016), so it is not that rare to meet someone who
knows what is Gamma function.
And for many of them π is much more readable than np.pi. Also there is
another problem, confusion between Gamma function and Euler–Mascheroni
constant, the first one is Γ,
the second one is γ (perfectly opposite to PEP 8 capitalization rules :-),
while both of them are frequently denoted as just gamma (in particular
math.gamma follows the PEP8 rules,
but is counter-intuitive for most scientist).

All that said, I agree that these problems are easily solved by a custom
import from. Still there is something in (or related to?) this proposal
I think is worth considering: Can we also allow identifiers like ∫ or √.
This will make many expressions more similar to usual TeX,
plus it will be useful for projects like SymPy.

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Security: remove "." from sys.path?

[Nick Coghlan]

On 2 June 2017 at 20:02, Victor Stinner  wrote:
> 2017-06-02 9:12 GMT+02:00 Greg Ewing :
>> Why do you want to change it?
>
> To make Python more secure. To prevent untrusted modules hijacking
> stdlib modules on purpose to inject code for example.

As long as user site packages are enabled, folks are pretty much hosed
on that front (drop a *.pth file in there and you can run arbitrary
code at startup).

Hence isolated mode and the system-python idea (which can potentially
be implemented even while PEP 432 is still a private API, although it
would require several more config settings to be migrated to the new
structure first).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Giampaolo Rodola']

On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka 
wrote:

> What you are think about adding Unicode aliases for some mathematic names
> in the math module? ;-)
>
> math.π = math.pi
> math.τ = math.tau
> math.Γ = math.gamma
> math.ℯ = math.e
>
> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>

* it duplicates functionality

* I have no idea how to write those chars on Linux; if I did, I'm not sure
it'd be the same on OSX and Windows (probably not)

* duplicated aliases might make sense if they add readability; in this case
they don't unless (maybe) you have a mathematical background. I can infer
what "math.gamma" stands for but not being a mathematician math.Γ makes
absolutely zero sense to me.

* if you really want to do that you can simply do "from math import gamma
 as Γ" but it's something I wouldn't like if I were to read your code

* I generally dislike any non-ASCII API; the fact that Python 3 allows you
to do that should not be an incentive to promote such habit in the stdlib
or anywhere else except in the end-user code, and it's something I still
wouldn't like it except if in comments or docstrings

-1

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Security: remove "." from sys.path?

[Victor Stinner]

2017-06-02 9:12 GMT+02:00 Greg Ewing :
> Why do you want to change it?

To make Python more secure. To prevent untrusted modules hijacking
stdlib modules on purpose to inject code for example.

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Security: remove "." from sys.path?

[Niki Spahiev]

On  1.06.2017 19:46, Chris Angelico wrote:

On Fri, Jun 2, 2017 at 2:30 AM, Victor Stinner  wrote:

Perl 5.26 succeeded to remove the current working directory from the
default include path (our Python sys.path):

https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-(%22.%22)-from-@INC

Would it technically possible to make this change in Python? Or would
it destroy the world? Sorry, it's a naive question (but honestly, I
don't know the answer.)


(AIUI, the *current directory* is never on Python's path, but the
*script directory* is. They're the same thing a lot of the time.)

All it'd take is one tiny change to Python, and then one tiny change
to any multi-file non-package Python app.

1) Make the script directory implicitly function as a package. In
effect, assume that there is an empty __init__.py in the same
directory as the thing you just ran.

2) Any time a Python app wants to import from its own directory, it
needs to "from . import blah" instead of simply "import blah".

Then the removal you suggest could be done, without any loss of
functionality. The change could alternatively be done as an import
hack rather than an actual fake package if that's easier, such that
"from . import blah" means either "import from the script directory"
or "import from the current package" as appropriate.


Hack for tesing this idea:

#!/bin/env python3

__path__ = '.'
import sys; sys.modules[''] = sys.modules['__main__']

# rest of the script

+1

Niki

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Erik Bray]

On Fri, Jun 2, 2017 at 7:52 AM, Greg Ewing  wrote:
> Victor Stinner wrote:
>>
>> How do you write π (pi) with a keyboard on Windows, Linux or macOS?
>
>
> On a Mac, π is Option-p and ∑ is Option-w.

I don't have a strong opinion about it being in the stdlib, but I'd
also point out that a strong advantage to having these defined in a
module at all is that third-party interpreters (e.g. IPython, bpython,
some IDEs) that support tab-completion make these easy to type as
well, and I find them to be very readable for math-heavy code.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Security: remove "." from sys.path?

[Greg Ewing]

Victor Stinner wrote:
You are right, it's the script directory that it added to 
sys.path and I would like to know if it would be possible to change that?


Why do you want to change it?

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Masayuki YAMAMOTO]

Yes, it's correct. I'd show you a link to vim help for ambiguous width
setting.

http://vimdoc.sourceforge.net/htmldoc/options.html#'ambiwidth'

Masayuki

2017-06-02 5:05 GMT+09:00 Ryan Gonzalez :

> I'm slightly confused as to what you mean, but here goes:
>
> So you're saying that:
>
> - Glyphs like pi have an ambiguous width.
> - Most text editors/terminals let you choose between halfwidth (roughly
> normal monospace width?) and fullwidth (double the size).
> - However, many East Asian fonts do NOT have halfwidth support.
>
> Is this correct?
>
> --
> Ryan (ライアン)
> Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
> http://refi64.com
>
> On Jun 1, 2017 2:27 PM, "Masayuki YAMAMOTO" 
> wrote:
>
> Hi Stephan,
>
>
> Nevertheless, I would like to point out that the encoding assumed for a
>> Python3 source file never depends on the locale.
>>
> Yeah, as you pointed out. I'd like to correct my said.
>
>
>> My understanding is that in the default encoding for Python source files
>> (utf-8), East Asian Ambiguous characters must be assumed narrow. Now there
>> are also legacy encodings where they are fullwidth. But it is always
>> determined by the encoding, which in turn is specified or implied in the
>> source file.
>>
> The mapping for ambiguous width assumes on East Asia legacy encodings and
> non East Asia legacy encodings, but not recommend to UTF-8 and other
> Unicode encodings. Displaying ambiguous width characters behave narrow by
> default, it isn't related to encoding. [*]
>
> Let me see... Several softwares have a setting that changes ambiguous
> width to halfwidth or fullwidth regardless for encoding (e.g.
> gnome-terminal, vim). And some fonts that are used in East Asia make glyph
> that is Greek letters and other signs to adjust to fullwidth, they break
> layout under halfwidth settings. It is possible that avoids these fonts,
> and uses multi language support font, yet signs that are only used in East
> Asia don't have halfwidth glyph no matter the ambiguous width. Therefore,
> in case of using East Asia language, it is difficult that set displaying
> Greek letters as halfwidth.
>
> Regards,
> Masayuki
>
> [*] http://unicode.org/reports/tr11/#Recommendations
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/