[Python-ideas] Re: venv.EnvBuilder environmental variable hooks

2019-06-18 Thread Brett Cannon
Just an FYI that I actually plan to try and make the activation scripts (at least under PowerShell) completely static so they can be signed. On Tue, Jun 18, 2019 at 3:31 PM Caleb Donovick wrote: > Currently EnvBuilder allows for a number of customizations of virtual > environments, changing whic

[Python-ideas] venv.EnvBuilder environmental variable hooks

2019-06-18 Thread Caleb Donovick
Currently EnvBuilder allows for a number of customizations of virtual environments, changing which python is used, automatically installing libraries, etc... However, it does not allow for any modifications of the activate script itself (unless one wants to rewrite it completely). However, a fairl

[Python-ideas] Re: unittest block

2019-06-18 Thread Geoffrey Spear
On Tue, Jun 18, 2019 at 3:37 PM James Lu wrote: > # regular code > unittest: > # test code goes here > > This code would be run when the runtime -unittest flag is passed. It would > function as test usages and example client code. The code within the block > would remain in .pyc, unless the -O s

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread Caleb Donovick
> And what I'm asking for is a justification for that. Python in > general has done fine without it for almost 3 decades. I believe you > that you have so far not found a way to make a pretty DSL without it, > and similarly for Yanghao's HDL. But it's far from obvious that none > exists that mo

[Python-ideas] Fwd: unittest block

2019-06-18 Thread Jonathan Fine
Hi James Something similar can already be done, say via from somewhere import unittest @unittest def f(): # test code goes here As it's your idea, I suggest you create and put up an implementation on PyPi, and post again to this list when you have some real-world examples of the use of this

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread nate lust
I have been following this discussion for a long time, and coincidentally I recently started working on a project that could make use of assignment overloading. (As an aside it is a configuration system for a astronomical data analysis pipeline that makes heavy use of descriptors to work around his

[Python-ideas] unittest block

2019-06-18 Thread James Lu
# regular code unittest: # test code goes here This code would be run when the runtime -unittest flag is passed. It would function as test usages and example client code. The code within the block would remain in .pyc, unless the -O switch is passed. Write "" or ## above a unittest to in

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread James Lu
> python is not build for speed Yes, but it scales to speed, letting you speed up your code easily when you need it. Consider Cython and Nuitka. Consider GraalPython. Consider... consider that C dylibs can be loaded and used from within Python without any wrappers. You can create the <- operato

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Stephen J. Turnbull
Dan Sommers writes: > How would I "think of types as collections of their instances"? The canonical example of a type as a collection of instances is an enumeration, the simplest (useful) example of which is bool = {False, True}. In pre-big-integer Python, in principle you could do the same thi

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Stéphane Wirtel
;-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-id

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Christian Heimes
On 17/06/2019 16.47, Guido van Rossum wrote: > Type theorists apparently have chosen to use the <: notation, and > presumably for the same reason. Can we call it "party hat operator", please? <:-) Christian ___ Python-ideas mailing list -- python-ideas@

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Rhodri James
On 18/06/2019 11:06, Yanghao Hua wrote: On Sun, Jun 16, 2019 at 7:41 PM Steven D'Aprano wrote: On Sun, Jun 16, 2019 at 08:04:44AM -0700, Christopher Barker wrote: On Sun, Jun 16, 2019 at 6:08 AM Franklin? Lee wrote: The proposed feature is for expressing type relations, which only matters

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Yanghao Hua
On Sun, Jun 16, 2019 at 7:41 PM Steven D'Aprano wrote: > > On Sun, Jun 16, 2019 at 08:04:44AM -0700, Christopher Barker wrote: > > On Sun, Jun 16, 2019 at 6:08 AM Franklin? Lee > > > > wrote: > > > > > The proposed feature is for expressing type relations, which only > > > matters when you care

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread Yanghao Hua
On Tue, Jun 18, 2019 at 10:57 AM Stephen J. Turnbull wrote: > Maybe you'll persuade enough committers without examples. Maybe the > problem will be solved en passant if the "issubclass needs an > operator" thread succeeds (I've already suggested to Yanghao offlist > that Guido's suggested spellin

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Emin Bugra Saral via Python-ideas
`<:` kind of notation would look more clear, I agree. My proposition came after thinking the wording used in Python. issubclass() - is subclass? By definition, subclass reminds me set theory. https://en.wikipedia.org/wiki/Subclass_(set_theory) which also has a relativity with Subtyping as Gui

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread Stephen J. Turnbull
Caleb Donovick writes: > I don't really want to change the semantic of =. What Yanghao and > I are asking for is an in-place update/assign operator which isn't > burdened with numeric meaning. And what I'm asking for is a justification for that. Python in general has done fine without it for

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-18 Thread Serhiy Storchaka
17.06.19 17:47, Guido van Rossum пише: Indeed it would work the same way as set comparison does, if you interpret a type as the set of its instances. But I imagine that many Python users are not so familiar with this abstraction level (even if they use isinstance() and issubclass() all day lo