[Python-ideas] Re: venv.EnvBuilder environmental variable hooks
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 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 fairly common requirement for python packages is to edit some
> environmental variable e.g., DJANGO_SETTINGS_MODULE=.
>
> Which leaves developers with two options set the variables globally or
> manually edit the activate script. Granted the activate script has been
> fairly static for the past few years, so a patch file can be used after
> manually editing once but its not the most elegant solution. Further,
> there is no guarantee that activate script will be static going forward.
> In my mind there is a very simple solution, allow EnvBuilder to extend the
> set of variables which are set and restored on activate / deactivate (or
> more generally have activate / deactivate hooks).
>
> In the cpython implementation of venv there is a number of template
> parameters in the skeleton activate scripts which are filled by the
> EnvBuilder (__VENV_DIR__, __VENV_NAME__, ...). A simple solution would be
> to extend these with __VENV_ACTIVATE_EXTRAS__ and
> __VENV_DEACTIVATE_EXTRAS__ where by default
> ```
> #Let env_vars: Dict[str, str] be the custom environmental variables
> __VENV_ACTIVATE_EXTRAS__ = ''.join(f'''
> _OLD_VIRTUAL_{key}="${key}"
> {key}="{value}"
> export {key}
> ''' for key,value in env_vars.items())
>
> __VENV_DEACTIVATE_EXTRAS__ = ''.join(f'''
> if [ -n "${{_OLD_VIRTUAL_{key}:-}}" ] ; then
> {key}="${{_OLD_VIRTUAL_{key}:-}}"
> export {key}
> unset _OLD_VIRTUAL_{key}
> fi
> ''' for key in env_vars)
> ```
>
> With __VENV_ACTIVATE_EXTRAS__ at
>
> https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L46
> and __VENV_DEACTIVATE_EXTRAS__ at
>
> https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L16
>
> Full activate / deactivate hooks could be achieved by setting
> __VENV_*_EXTRAS__ to be arbitrary shell commands.
>
> Caleb Donovick
>
> ___
> 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-ideas@python.org/message/MJNFEFT4GBVBEETJWZUQM5SS6C34PT3K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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-ideas@python.org/message/IFDZX73T6PA3ALXAXCFRYK6TEHJ3IIOX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] venv.EnvBuilder environmental variable hooks
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 fairly common requirement for python packages is to edit some
environmental variable e.g., DJANGO_SETTINGS_MODULE=.
Which leaves developers with two options set the variables globally or
manually edit the activate script. Granted the activate script has been
fairly static for the past few years, so a patch file can be used after
manually editing once but its not the most elegant solution. Further,
there is no guarantee that activate script will be static going forward.
In my mind there is a very simple solution, allow EnvBuilder to extend the
set of variables which are set and restored on activate / deactivate (or
more generally have activate / deactivate hooks).
In the cpython implementation of venv there is a number of template
parameters in the skeleton activate scripts which are filled by the
EnvBuilder (__VENV_DIR__, __VENV_NAME__, ...). A simple solution would be
to extend these with __VENV_ACTIVATE_EXTRAS__ and
__VENV_DEACTIVATE_EXTRAS__ where by default
```
#Let env_vars: Dict[str, str] be the custom environmental variables
__VENV_ACTIVATE_EXTRAS__ = ''.join(f'''
_OLD_VIRTUAL_{key}="${key}"
{key}="{value}"
export {key}
''' for key,value in env_vars.items())
__VENV_DEACTIVATE_EXTRAS__ = ''.join(f'''
if [ -n "${{_OLD_VIRTUAL_{key}:-}}" ] ; then
{key}="${{_OLD_VIRTUAL_{key}:-}}"
export {key}
unset _OLD_VIRTUAL_{key}
fi
''' for key in env_vars)
```
With __VENV_ACTIVATE_EXTRAS__ at
https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L46
and __VENV_DEACTIVATE_EXTRAS__ at
https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L16
Full activate / deactivate hooks could be achieved by setting
__VENV_*_EXTRAS__ to be arbitrary shell commands.
Caleb Donovick
___
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-ideas@python.org/message/MJNFEFT4GBVBEETJWZUQM5SS6C34PT3K/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: unittest block
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 switch is passed. > > > Write "" or ## above a unittest to include it in generated > documentation. > Introducing a keyword that would make it impossible to import an existing stdlib module seems like a nonstarter. ___ 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-ideas@python.org/message/KOEKTC7M7WCEPOOQ63NIXE5CXIG3DYGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?
> 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 most Pythonistas would find satisfactory.
I have found a way to make a pretty DSL, as I stated earlier in the thread
I rewrite the AST. From a user standpoint the problem is mostly moot.
>From a developer standpoint rewriting the AST is an incredibly painful way
to operate.
> So far the request for an in-place update operator seems to fail on
> both counts. "Need" fails for lack of examples. "Broad benefit"
> could be implied by "need" and a bit of imagination applied to
> concrete examples, but on the face of it seems unlikely because of the
> lack of persistent voices to date, and "need" itself hasn't been
> demonstrated.
Both Yanghao and I have provided examples, what precisely do you want in an
example? Do you want my DSL code? Do you want the implementation of the AST
rewriter?
As far broader impact a whole range of common operations could be unified
by an assign in place (stealing some form that thread)
```
context_var.set(val) # possibly the most glaring place in the standard
library where an assign operator would be beautiful
lst[:] = new_list # while a common python idiom, this certainly isn't the
most obvious syntax and only works on lists
dct.clear(); dct.update(new_dict) # to achieve the same thing as above with
a dict or set.
numpy.copyto(array, new_array) # to achieve the same as above, note
array[:] = new_array is an error
```
If we want to extend discussion beyond assign in place to be a write
operator we can add to the list
```
coroutine.send(args)
process.communicate(args)
file.write(arg)
```
Caleb Donovick
On Tue, Jun 18, 2019 at 3:43 PM nate lust wrote:
> 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
> historical decisions and backward compatibility). Our system makes use of
> nested chains of objects and descriptors and proxy object to manage where
> state is actually stored. The whole system could collapse down nicely if
> there were assignment overloading. However, this works OK most of the time,
> but sometimes at the end of the chain things can become quite complicated.
> I was new to this code base and tasked with making some additions to it,
> and wished for an assignment operator, but knew the data binding model of
> python was incompatible from p.
>
> This got me thinking. I didnt actually need to overload assignment
> per-say, data binding could stay just how it was, but if there was a magic
> method that worked similar to how __get__ works for descriptors but would
> be called on any variable lookup (if the method was defined) it would allow
> for something akin to assignment. For example:
>
> class Foo:
> def __init__(self):
> self.value = 6
> self.myself = weakref.ref(self)
> def important_work(self):
> print(self.value)
> def __get_self__(self):
> return self.myself
> def __setattr__(self, name, value):
> self.value = value
>
> foo = Foo() # Create an instance
> foo # The interpreter would return foo.myself
> foo.value # The interpreter would return foo.myself.value
> foo = 19 # The interpreter would run foo.myself = 6 which would invoke
> foo.__setattr__('myself', 19)
>
> I am being naive is some way I am sure, possibly to how the interpreter
> could be made to do this chaining, but I figured I would weight in in case
> this message could spark some thought.
>
> On Tue, Jun 18, 2019 at 5:41 AM Yanghao Hua wrote:
>
>> 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 spelling of "<:" seems usable for "update",
>> > even though in that thread it's a comparison operator). But both
>> > would require a lot of luck IMO.
>>
>> I must have overlooked it ... <: seems good to me. I do agree with you
>> this needs more materialized evidence, I am working on it, in a few
>> areas more than just DSL/HDL.
>>
>> For now I have abandoned my local change to cpython and settled with
>> list assignment signal[:] = thing. This in most case does not conflict
>> with numeric operations, nor list operations. (HDL signals are both
>> numbers and a list of individual signals). And it aligns with what it
>> means with the general python list.
>>
>> Though, I am really looking forward to the success of <: operator as well
>> ;-)
>>
[Python-ideas] Fwd: unittest block
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 feature. -- Jonathan ___ 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-ideas@python.org/message/BLGRJB22HWRCTWGIBSL5AWK6YGHZC5US/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?
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
historical decisions and backward compatibility). Our system makes use of
nested chains of objects and descriptors and proxy object to manage where
state is actually stored. The whole system could collapse down nicely if
there were assignment overloading. However, this works OK most of the time,
but sometimes at the end of the chain things can become quite complicated.
I was new to this code base and tasked with making some additions to it,
and wished for an assignment operator, but knew the data binding model of
python was incompatible from p.
This got me thinking. I didnt actually need to overload assignment per-say,
data binding could stay just how it was, but if there was a magic method
that worked similar to how __get__ works for descriptors but would be
called on any variable lookup (if the method was defined) it would allow
for something akin to assignment. For example:
class Foo:
def __init__(self):
self.value = 6
self.myself = weakref.ref(self)
def important_work(self):
print(self.value)
def __get_self__(self):
return self.myself
def __setattr__(self, name, value):
self.value = value
foo = Foo() # Create an instance
foo # The interpreter would return foo.myself
foo.value # The interpreter would return foo.myself.value
foo = 19 # The interpreter would run foo.myself = 6 which would invoke
foo.__setattr__('myself', 19)
I am being naive is some way I am sure, possibly to how the interpreter
could be made to do this chaining, but I figured I would weight in in case
this message could spark some thought.
On Tue, Jun 18, 2019 at 5:41 AM Yanghao Hua wrote:
> 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 spelling of "<:" seems usable for "update",
> > even though in that thread it's a comparison operator). But both
> > would require a lot of luck IMO.
>
> I must have overlooked it ... <: seems good to me. I do agree with you
> this needs more materialized evidence, I am working on it, in a few
> areas more than just DSL/HDL.
>
> For now I have abandoned my local change to cpython and settled with
> list assignment signal[:] = thing. This in most case does not conflict
> with numeric operations, nor list operations. (HDL signals are both
> numbers and a list of individual signals). And it aligns with what it
> means with the general python list.
>
> Though, I am really looking forward to the success of <: operator as well
> ;-)
> ___
> 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-ideas@python.org/message/VB4ETTBFY24ENOFHS2JJAAM7PGQD6COA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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-ideas@python.org/message/SK2DFXFBG2YOIKNH3ZGO6HF422VC3Q5R/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] unittest block
# 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 include it in generated documentation. ___ 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-ideas@python.org/message/WCB4WBK3UPLGX2MZ2QO7DIWW5IOPQQ5F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?
> 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 <- operator in existing plus by overriding __lt__ and the unary negative sign. Same goes for <~. Perhaps you should propose an unary postfix - operator. That would let you create the -> operator in user space. ___ 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-ideas@python.org/message/FBTDXE7GTT7QIA2SEOC4APGT4UXPNJ6V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
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 thing
with the collection of all 2^64-bit bit patterns, with addition
defined by a 2^64 x 2^64 tables with rows and columns indexed by the
bit patterns and the results in the table cells. So a type is a tuple
of a set and operations, which can also be defined as sets of the
above form. Floats would have the same underlying set and different
tables.
> For example, in what sense is the type list a collection of
> instances of lists?
This involves infinite sets, but in principle can be thought of in the
same way.
> In my mind, a type is a description/container/shortand for a
> collection of properties or behaviors of instances of that type.
That's one way to think about it, of course. But the strong
intuitions about the numeric tower (a natural number *is* an integer,
an integer *is* a real number, and so on) as well as some useful but
(intuitively) more artificial ideas such as a bool *is* a natural
number are just as well expressed as set inclusions. This is useful
in type theory, but explaining "how" is way beyond the scope of this
post (and this whole list, in fact).
___
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-ideas@python.org/message/I4CGSIWZZ5GRCHLOI7Y6TEXZ5F5EKHFF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
;-) ___ 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-ideas@python.org/message/XSTQDXNVWVBJQSTFDAOEEFAAY4K4QMLR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
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.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-ideas@python.org/message/GVQPS43UAKXPNXIEQO5IQXLIFEHNB3SD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
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 when you care about types. The feature will only be useful when you care about types. The syntax will only help/hurt readability when the code cares about types. And Python programmers rarely care about types -- that's why we use Python.d I'm pretty sure that Python programmers *frequently* care about types. I know I do. How else do you avoid TypeErrors and AttributeErrors, if you don't care what type of data you're using? What they might not be doing is *explicitly* type-checking using isinstance or issubclass, but that doesn't mean they don't care about types. Whether we duck-type, or LBYL with an explicit test, or EAPF with a try...except block, or just rely on the caller never passing the wrong thing to our functions, we still care about types. I second on that, a lot of people who uses Python or Ruby, end up writing their own type system Really? I can honestly say I have never felt the need to invent a type system for Python. The one occasion I have made use of type annotations even caused me more trouble than it was worth (it caught one error that would have come out in testing after I spent hours working out how to break the circular dependencies that arose from trying to formalise duck-typing). (which is a major reason why language like scala becomes more and more popular and its user base has a lot of former dynamic language users). The impression that I'm getting from colleagues is that Scala is busily shooting itself in the foot at the moment, so I'm wary of taking lessons from it. Disclaimer: none of us are habitual Scala programmers, so take our collective opinions with a small mountain of salt. This is especially true for library and framework developers, where you want to capture issues early, e.g. by forcing policies and make sure user defined class is deriving from a common base class and some magic happens behind the scene. Python isn't a language that does forcing easily or well. Please correct me if I'm wrong, but I've always thought that was to a large extent deliberate. It may be unpopular in general computing right now, but we've always dealt with such potential problems with documentation. (I may be slightly bitter at the moment. I had to spend far too long yesterday reading the code of a C library because the limited documentation failed to mention quite a lot of things, and the examples of how to use it managed to be both trivial and misleading.) -- Rhodri James *-* Kynesim Ltd ___ 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-ideas@python.org/message/A7IRL26KBRATDSIQATDHWPJ53U7L3IY7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
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 about types. The feature will only be useful > > > when you care about types. The syntax will only help/hurt readability > > > when the code cares about types. > > > > > > > And Python programmers rarely care about types -- that's why we use Python.d > > I'm pretty sure that Python programmers *frequently* care about types. I > know I do. How else do you avoid TypeErrors and AttributeErrors, if you > don't care what type of data you're using? > > What they might not be doing is *explicitly* type-checking using > isinstance or issubclass, but that doesn't mean they don't care about > types. Whether we duck-type, or LBYL with an explicit test, or EAPF with > a try...except block, or just rely on the caller never passing the wrong > thing to our functions, we still care about types. I second on that, a lot of people who uses Python or Ruby, end up writing their own type system (which is a major reason why language like scala becomes more and more popular and its user base has a lot of former dynamic language users). This is especially true for library and framework developers, where you want to capture issues early, e.g. by forcing policies and make sure user defined class is deriving from a common base class and some magic happens behind the scene. ___ 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-ideas@python.org/message/HDUXDNGPIJ27DFGKSSTEZUGNAHCJITE3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Comparison operator support (>= and <=) for type
`<:` 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 Guido pointed out. And, we have operator support for set() as you can see here https://docs.python.org/3/library/stdtypes.html#set `set <= other` With this logic, since Python has its own way of being practical and predictable in some ways, I would except to have an operator like `<:`, which some other languages already possess. A <: B against issubclass(A, B) looks more elegant, and purpose driven syntax like most of other types. I see that there is also `issubset` method which is equivalent to `set <= other`. Therefore I find this a little bit inconsistent that we don't apply the similar logic for issubclass. I don't know if we could achieve same performance of issubclass itself with the operator (I think we can) but even it's not the case, people who uses Python to write their scripts very fast, that would be a lovely addition. ___ 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-ideas@python.org/message/BPDNTSZRRKBIXYJVKHNPG6EFZGDX4ZRX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?
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 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 most Pythonistas would find satisfactory. It's easy to understand why NumPy wanted an additional operator: it's well-known and easily verified by looking at any numerical analysis textbook that matrices can benefit from having notation for a special multiplication operation as well as for all elementwise numerical operations. Making NumPy's job easier makes Python better for literally millions of Python users. So far the request for an in-place update operator seems to fail on both counts. "Need" fails for lack of examples. "Broad benefit" could be implied by "need" and a bit of imagination applied to concrete examples, but on the face of it seems unlikely because of the lack of persistent voices to date, and "need" itself hasn't been demonstrated. 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 spelling of "<:" seems usable for "update", even though in that thread it's a comparison operator). But both would require a lot of luck IMO. Steve ___ 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-ideas@python.org/message/5WEIXEGMXP2FZOSTUU3TOWM42HEJS4AQ/ Code of Conduct: http://python.org/psf/codeofconduct/
