Re: super() in injected methods
On 12/02/21 3:39 pm, Andras Tantos wrote: Now, when a Port gets assigned a NetType, it needs to gain all sorts of new features. It for example should have a 'length' attribute that tells how many bits are needed to represent its possible values. The way I would probably approach this is to have a single Port type with all the methods that might be required, and forward their implementations to the NetType. e.g. class Port: @property def length(self): return self.net_type.length Another possibility might be to change the __class__ of the port object at run time to a subclass of Port having the required features. That would be a lot easier and more efficient than adding individual methods to every Port instance, and super() should work normally. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: mutating a deque whilst iterating over it
On 11Feb2021 20:22, duncan smith wrote: > It seems that I can mutate a deque while iterating over it if I >assign to an index, but not if I append to it. Is this the intended >behaviour? It seems a bit inconsistent. Cheers. I think that just means that the deque didn't _notice_ your change in the former case. Not necessarily that it wouldn't want to. I confess to not being sure that appending to a deque during an iteration should be a bad thing, except that with a bounded deque that might entail discarding the element at your current iteration point. Maybe. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: super() in injected methods
On 2/11/21 1:43 PM, Greg Ewing wrote: On 12/02/21 7:05 am, Andras Tantos wrote: a = B() a.m(41) a.m = MethodType(method, a) a.m(42) Are you sure you really need to inject methods into instances like this? What problem are you trying to solve by doing so? There's almost certainly a better way to approach it. Greg, This is going to be a long a convoluted story, but since, you've asked... I'm developing a library to describe hardware (RTL) in Python and convert it into Verilog (or potentially other languages). In this project, I have two concepts: 1. Ports, which are the connection points on the various netlist entities. These would be the inputs and outputs of an AND gate for example 2. NetTypes, which describe the type of data that can travel through a net (and thus through a Port). One such type would be an 8-bit signed integer, or a simple logic signal. There are derived types of the Port object (for inputs and outputs etc.) as well as of NetType (for signed integers, structs, etc.) An interesting aspect of the problem is that most ports don't need to have a type initially: it can be deduced from the connectivity (netlist) of the circuit described. So, for example the above mentioned AND gate can handle any input as long as they are of the same NetType and produce an output of the same NetType. This is to say, that Ports have an optional NetType, the association between Port and NetType is dynamic and changes during the lifetime of the Port instance. There are two ways I can think of modelling this in Python: 1. A (derived) Port instance uses multiple-inheritance to also inherit from it's (derived) NetType 2. A (derived) Port instance has a member of a (derived) NetType instance I went with #2 in my current implementation. Now, when a Port gets assigned a NetType, it needs to gain all sorts of new features. It for example should have a 'length' attribute that tells how many bits are needed to represent its possible values. The list of these new features (attributes, methods, properties) are known to the NetType and should be injected into the Port when the NetType is assigned to the Port. With #1, the situation is different, but not any less complicated: now, the features are automatically appear in the Port instance (maybe even too much so) but we dynamically mess with the inheritance tree of the type of the Port instance. The example I've written up deals with the problems when I try to inject these new features into the Port instance (say a new method) and the method implementation intends to call back the base-class behavior for some reason. I believe even #1 could have similar problems in different ways though: since I manipulate the inheritance chain dynamically, I don't think there's a guarantee that the statically determined '__class__' cell will be the same as the dynamically expected one. Andras -- https://mail.python.org/mailman/listinfo/python-list
Re: super() in injected methods
Chris,
Thanks for the reply!
On 2/11/21 11:08 AM, Chris Angelico wrote:
On Fri, Feb 12, 2021 at 5:54 AM Andras Tantos
wrote:
Esteemed Python Gurus,
I think, I actually know the answer to this question, but - maybe beyond
reason - I'm hoping there to be some magic. Consider the following code:
from types import MethodType
class A(object):
pass
def m(self, x):
print(f"A.m({x})")
class B(A):
def m(self, x):
print(f"B.m({x})")
ss = super()
ss.m(x)
def method(self, s):
print(f"method({s})")
try:
ss = super() # <-- Complains about __class__ cell not being
found
except:
print("I shouldn't need to do this!")
ss = super(type(self), self) # <-- Works just fine
ss.m(s)
a = B()
a.m(41)
a.m = MethodType(method, a)
a.m(42)
In the function 'method', I try to access the super() class. Now, of
course that makes no sense as a stand-alone function, but it does, once
it gets injected as a method into 'a' below.
The two-parameter version of the call of course works without a hitch.
Be careful: the first parameter is supposed to be the class that
you're currently implementing, which may well NOT be type(self). Given
that you're attaching to an instance, though, it's probably okay to
assume you are looking at the leaf class.
Good point, thanks for raising it. That is the of course the reason it's
not implemented that way by the interpreter. In this particular instance
that happens to be the correct answer, but generally no, it's not the same.
I think I actually understand why this is happening (some interpreter
magic around super() forcing the insertion of __class__, which that
doesn't happen when parsing a stand-alone function). I think I even
understand the rationale for it, which is that super() needs to be
statically evaluated.
What happens in the normal case is that __class__ is accessed via
closure cell from the class block itself. The compiler translates
super() into super(__class__, self) where 'self' is actually 'whatever
the first parameter is'.
Now to the question though: In theory this information (static type of
'self' at the point of method binding to class) is available at the
point of method injection, in this example, the next-to-last line of the
code. So, is there a way to somehow
inject/override/magically-make-it-appear the __class__ cell in 'method'
such that super() starts working as expected again?
Hmm. I don't think it'd work for technical reasons, but in theory, the
MethodType constructor would be the place to do this. But injecting
methods into instances (as opposed to classes) is a sufficiently
unusual thing that it's probably safest to just use the two-arg super
and have done with it.
Yes, MethodType could be a place to deal with this, but - since it
doesn't - I'm looking for any way to do it outside of it. The question
of packaging it up into a neat API can wait for another day.
Andras
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 23:05, Paul Rubin wrote: Mr Flibble writes: "neos" - https://neos.dev/ https://github.com/i42output/neos Good luck, let us know when it is done. What is there doesn't look like a credible start so far, but maybe you will surprise us. Have you actually written any code in the languages you say you are going to support? E.g. Ada, Haskell, Rust. I'd agree that Python is fairly simple compared to those. Not credible? On what do you base that analysis? /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 23:12, Greg Ewing wrote: On 12/02/21 11:33 am, Mr Flibble wrote: neos isn't a Python package so that isn't a problem. It might be a bit confusing if it ever becomes part of the wider Python ecosystem, though. Python is but one language that neos will implement. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 12/02/21 11:33 am, Mr Flibble wrote: neos isn't a Python package so that isn't a problem. It might be a bit confusing if it ever becomes part of the wider Python ecosystem, though. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 22:25, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble wrote: On 11/02/2021 21:13, Dan Stromberg wrote: Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. "neos" - https://neos.dev/ https://github.com/i42output/neos Pypi already appears to have another project named neos: https://pypi.org/project/neos/ neos isn't a Python package so that isn't a problem. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble wrote: > On 11/02/2021 21:13, Dan Stromberg wrote: > > Does your project have a name yet? I'd like to follow it through google > > alerts or an announcement mailing list. > > "neos" - https://neos.dev/ https://github.com/i42output/neos > Pypi already appears to have another project named neos: https://pypi.org/project/neos/ -- https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation
I may be the only one who does not deal well with a condescending attitude. I have to wonder what international standards body ever completes a task in finite time, only to find the real world has moved on. Having standards can be a great idea. When the standard does not properly describe any implementations either because some leave out things and others have partial or enhanced implementations, then it is just a goal. May I ask if the proposed product itself needs standardization? Since it claims to support many (or amusingly ANY) language fully, perhaps they can share their Ada or other version before they do Python, or are they working on all of them at once? Realistically, many languages have chosen various paths and a model that captures them all will have to be fairly complex and perhaps needlessly complex. Does it need multiple ways to deal with issues like scope and perhaps keep track of that if a program crosses several boundaries? Will it be able to handle something like an R program running a package that allows a parallel running of a Python program as they work jointly on the same or copied data structures? I have been writing those lately and in the future may incorporate additional languages to take advantage of the strengths and features of each while avoiding the weaknesses or missing aspects of another. Anyone who considers the task specified to be a small problem is either brilliant or perhaps not well informed. If they can do what they say well, great. But I have seen other such attempts such as finding a way to translate between word processor formats that try to deal with overlapping but different concepts and do imperfect translations. That may of course not be relevant here if what is produced is code that runs and yet follows the expected rules as if it was being interpreted. But a more pleasant attitude may make the same points, not that I am sure what those are and what is being asked. It sounds more like being told. -Original Message- From: Python-list On Behalf Of Mr Flibble Sent: Thursday, February 11, 2021 1:15 PM To: python-list@python.org Subject: Re: New Python implementation On 11/02/2021 18:06, Chris Angelico wrote: > On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble > wrote: >> >> On 11/02/2021 16:31, Dan Stromberg wrote: >>> On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble >>> >>> wrote: >>> Hi! I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform). >>> >>> I'd like to encourage you to give this a go. It's a huge task, but >>> it's needed. >> >> Actually it is a relatively small task due to the neos universal compiler's >> architectural design. If it was a large task I wouldn't be doing it. >> >>> >>> You may be interested in the approaches of Pypy, Cython, Shedskin >>> and Nuitka. >> >> I am not particularly interested in any of the existing implementations as >> they bear no relation to the design of my language agnostic universal >> compiler, runtime, VM and JIT; the only use they will have will be to >> disambiguate certain Python language constructs that I cannot disambiguate >> from documentation alone: this is a natural consequence of Python not being >> standardized; those steering the language need to grow a pair and get Python >> standardized preferably as an ISO Standard. >> > > You keep insulting Python and the Python devs. Put up or shut up - > show some actual code before you make too many boasts. > > Python DOES have a strong language specification. Its semantics are > documented. If you find places where the documentation is lacking, > point them out specifically, don't FUD your way through. For a language to transition from "toy" status it has to be formally standardized. It is unacceptable to define a language in terms of a particular implementation. A git repo of Source code and associated observable dynamic behaviour when that code is compiled and ran is a poor substitute for an official ISO Standard. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 21:13, Dan Stromberg wrote: Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. "neos" - https://neos.dev/ https://github.com/i42output/neos /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: super() in injected methods
On 12/02/21 7:05 am, Andras Tantos wrote: a = B() a.m(41) a.m = MethodType(method, a) a.m(42) Are you sure you really need to inject methods into instances like this? What problem are you trying to solve by doing so? There's almost certainly a better way to approach it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: mutating a deque whilst iterating over it
On 12/02/2021 09.22, duncan smith wrote: > Hello, > It seems that I can mutate a deque while iterating over it if I > assign to an index, but not if I append to it. Is this the intended > behaviour? It seems a bit inconsistent. Cheers. Yes, and no! Agree and disagree. (see how decisive I can be?) Inconsistent when compared with what? A tuple is immutable, but if it contains mutable objects as elements, they are mutable. Consistent! That said, tuples can't be append-ed/extend-ed, so a deque may seem more like a list than a tuple. A list will allow both element and list mutation. Substituting a list in the sample code, the iterator will adjust to include an appended element. Inconsistent! However... what happens if you have a for-loop which processes a list, and within the loop one element is mutated in value and another appended to the list? Oops! Maybe the deque authors wanted to avoid that, or perhaps such is related to the option to bound the length of a deque (by design or side-effect)? Imagine a bounded-deque (completely 'filled') and the code is (overly-simple example) printing its contents. If the deque-element printing-loop also allows deque-mutation, then the first value(s), previously printed, will no longer exist within the queue. I'm enjoying the question: wither inconsistency? Perhaps someone (wiser) will jump in... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, Feb 11, 2021 at 10:21 AM Mr Flibble wrote: > For a language to transition from "toy" status it has to be formally > standardized. It is unacceptable to define a language in terms of a > particular implementation. A git repo of Source code and associated > observable dynamic behaviour when that code is compiled and ran is a poor > substitute for an official ISO Standard. > I'm inclined to agree, though Python has done surprisingly well at fostering multiple implementations despite having a reference implementation for so long. The thing it'd probably help the most with, is slowly down the rate of change in the language. The Core Devs seem to want to improve CPython rapidly, which is not great for the many other implementations - EG Jython and IronPython. Also, "improvements" in CPython are frequently tending toward featuritis, since the complexity of a language tends to grow with the square of its feature count. Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 12/02/2021 08.53, Chris Angelico wrote: > On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list > wrote: >> 3 >> My mind is whirling in an attempt to understand "show me a better time". >> Does this perhaps indicate that @Chris' social life leaves something to >> be desired? Are Python-nerds really the ones to turn-to for dating >> advice, or is that not what @Chris means by "(having) a good time"? > > LOL! I was referring to the fact that my demonstration snippet > included a rudimentary timing bracket, and that, if existing Python > implementations are indeed abysmally slow, it should be possible to > run the same code on a different interpreter and get a lower number - > a "better" time being shorter. Agreed. I've been 'bitten' by running 'the same' interpreter on different hardware/configs and finding that one part of the program[me] ran faster on the dev-machine, and another part faster on the prod-box. Felt a bit like a no-win situation! Timing was an important contribution. However, needing to perform same in-situ was a surprise. 'Gotcha'! There are a lot of variables in the efficiency-game. It's not completely cut-and-dried to say this, but as a general rule-of-thumb one does not select Python for applications/components which have significant execution-time constraints/requirements. However, Python is rarely bettered when it comes to developer-time! Horses for courses... As to being outrageously cheeky: even if COVID travel-restrictions have been lifted, knowing the Tasman Sea remains between us, allowed/emboldened me to go for the prize(?) for finding at least some word-play to laugh-about in this whole conversation. PS my version of bravery is that if you come after me carrying a big stick, I shall run in the opposite direction - very quickly! PPS speaking of travel: have you taken advantage of any of the "vouchers" offered by your (Fed?State) government as an economic stimulus/recovery for the hospitality industry? -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
mutating a deque whilst iterating over it
Hello, It seems that I can mutate a deque while iterating over it if I assign to an index, but not if I append to it. Is this the intended behaviour? It seems a bit inconsistent. Cheers. Duncan >>> from collections import deque >>> d = deque(range(8)) >>> it = iter(d) >>> next(it) 0 >>> d[1] = 78 >>> next(it) 78 >>> d.append(8) >>> next(it) Traceback (most recent call last): File "", line 1, in next(it) RuntimeError: deque mutated during iteration >>> -- https://mail.python.org/mailman/listinfo/python-list
@unittest.skip doesn't print anything in Python <= 3.7
Hi, https://stackoverflow.com/questions/66161394/unittest-skip-doesnt-print-anything-in-python-3-7 We are using Django with unittest. Some tests are skipped with the @unittest.skip decorator. But if I run the tests with Python 3.6 or 3.7, I get a number of tests passed (Ran 993 tests / OK), and if I run the same tests with Python 3.8, I get the same number of tests but with some tests skipped (Ran 993 tests / OK (skipped=4)). I would like to know if the same tests were also skipped with Python 3.6 and 3.7, or only with Python 3.8? And why do I get the skipped output only with Python 3.8? And is the number 993 including the skipped tests or not including them? Is one of the outputs incorrect? Because it doesn't make sense that the output is different for different versions of Python and I don't understand the reason for this difference. I didn't find it documented in the documentation. Our code is open source, and you can see for example a skipped test here. *Update:* I added 4 more tests with the decorator @unittest.skip. When I run all the tests with Python 3.8, I get this output: Ran 997 tests / OK (skipped=8) (with an s for every skipped test, like before). But if I run the tests with Python 3.6 or 3.7, I get this output: Ran 997 tests / OK and there are no s in the output, like before (I get 997 dots). Although I have 4 more tests than before. The tests I added raise an exception, so if they would not be skipped they would fail. I think the skipped tests are skipped in all Python versions, but in Python 3.6 and 3.7 there is no output about them being skipped. Is it a bug? אורי u...@speedy.net -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list wrote: > 3 > My mind is whirling in an attempt to understand "show me a better time". > Does this perhaps indicate that @Chris' social life leaves something to > be desired? Are Python-nerds really the ones to turn-to for dating > advice, or is that not what @Chris means by "(having) a good time"? LOL! I was referring to the fact that my demonstration snippet included a rudimentary timing bracket, and that, if existing Python implementations are indeed abysmally slow, it should be possible to run the same code on a different interpreter and get a lower number - a "better" time being shorter. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 12/02/2021 07.14, Mr Flibble wrote: > On 11/02/2021 18:06, Chris Angelico wrote: >> On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble >> wrote: >>> >>> On 11/02/2021 16:31, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: > I am starting work on creating a new Python implementation from > scratch ... (which isn't a stretch given how poorly they perform). I'd like to encourage you to give this a go. It's a huge task, but it's needed. >>> >>> Actually it is a relatively small task due to the neos universal >>> compiler's architectural design. If it was a large task I wouldn't >>> be doing it. >>> You may be interested in... >>> >>> I am not particularly interested in any of the existing >>> implementations as they bear no relation to the design of my language ...not being standardized; those steering >>> the language need to grow a pair and get Python standardized >>> preferably as an ISO Standard. ... > For a language to transition from "toy" status it has to be formally > standardized. It is unacceptable to define a language in terms of a > particular implementation. A git repo of Source code and associated > observable dynamic behaviour when that code is compiled and ran is a > poor substitute for an official ISO Standard. > > /Flibble When I first met it, one of the concepts I found difficult to 'wrap my head around' was the idea that "open software" allowed folk to fork the original work and 'do their own thing'. My thinking was (probably) "surely, the original is the authoritative version". Having other versions seemed an invitation to confusion and dilution. However, as soon as (open) software is made available, other people start making it 'better' - whatever their own definition of "better". Yes, it is both a joy and a complication. Such is contrary to the principle of "standards". At its extreme, a standard says there is only one way to do the-whatever. This is why many 'standard programming languages' then offer the 'out' of having various levels of 'standard'. For example, despite being one of the longest standardised languages, many COBOL implementations achieve only part of "the standard" - and one has to dive (deep) into the 'small print' to establish which 'bits' are in their particular 'pick and mix'. Yet, they still (quite legally) refer to their product as 'standard'! The second issue with standards is the time and effort it takes to achieve an agreement and thus reach the point of publishing. A third issue, and possibly the reason why attempting a standard is a "losing battle", is that programming and languages are in a constant state of flux - we call it "ongoing development". Even though Python v3.10 is reaching a state of anticipation, there are organisations and libraries that still work using Python 2. Thus, and HTML/"the browser wars" is an example of this, as fast as a standard is discussed, someone (even those contributing to said standards) is doing his/her best to build 'more advanced features' beyond the standard... "Standards" and 'driving development forward' are at least in tension, at worst, complete-opposites. Standards, like "waterfall" project specifications, cannot be 'cast in stone' because the world keeps changing. Standards are insufficiently agile and Agile! Whereas the likes of COBOL had "owners", if not as a point-of-fact, at least in terms of (commercial) 'might' and 'power', Python has its "Python Software Foundation" (https://www.python.org/psf/). Please feel free to approach that group to talk about 'what is Python' and 'standardisation'. Rather than a process of "imposing" a standard, Python has a more 'grass roots' democratic process which involves PEPs (Python Enhancement Proposal). These are 'great ideas', even intentions-to-build or proofs-of-concept, documented, and presented for the community to consider. The better ones make it through and become part of the language and its eco-system. Has the above proposal started on that 'standards path'? Is it 'documented', or merely an idea? Another aspect of open source is its 'meritocracy' - respect for those who have demonstrated their abilities (and commitment). Certain names 'crop-up' on PEPs, and more tellingly, on "accepted" PEPs. Of the three names appearing in this thread, which two have been seen before, and have contributed to PEPs or to this list, in the past? Is there a choice to 'stand on the shoulders of giants', or to 'walk all over ... in hob-nailed boots'? Has this conversation illustrated respect, or (perhaps unintentionally) torn-down others' sweat-and-tears without offering something (better) for consideration/approval/use? Is there any proof that you/I/someone-else can actually "do" better? An applicable saying is "the proof is in the pudding". So, rather than claims, shouldn't we be dealing with facts, eg system-A does better than system-B under the following conditions? A community comprises people who
Re: super() in injected methods
On Fri, Feb 12, 2021 at 5:54 AM Andras Tantos
wrote:
>
> Esteemed Python Gurus,
>
> I think, I actually know the answer to this question, but - maybe beyond
> reason - I'm hoping there to be some magic. Consider the following code:
>
> from types import MethodType
>
> class A(object):
> pass
> def m(self, x):
> print(f"A.m({x})")
> class B(A):
> def m(self, x):
> print(f"B.m({x})")
> ss = super()
> ss.m(x)
>
> def method(self, s):
> print(f"method({s})")
> try:
> ss = super() # <-- Complains about __class__ cell not being
> found
> except:
> print("I shouldn't need to do this!")
> ss = super(type(self), self) # <-- Works just fine
> ss.m(s)
>
> a = B()
> a.m(41)
> a.m = MethodType(method, a)
> a.m(42)
>
>
> In the function 'method', I try to access the super() class. Now, of
> course that makes no sense as a stand-alone function, but it does, once
> it gets injected as a method into 'a' below.
>
> The two-parameter version of the call of course works without a hitch.
Be careful: the first parameter is supposed to be the class that
you're currently implementing, which may well NOT be type(self). Given
that you're attaching to an instance, though, it's probably okay to
assume you are looking at the leaf class.
> I think I actually understand why this is happening (some interpreter
> magic around super() forcing the insertion of __class__, which that
> doesn't happen when parsing a stand-alone function). I think I even
> understand the rationale for it, which is that super() needs to be
> statically evaluated.
What happens in the normal case is that __class__ is accessed via
closure cell from the class block itself. The compiler translates
super() into super(__class__, self) where 'self' is actually 'whatever
the first parameter is'.
> Now to the question though: In theory this information (static type of
> 'self' at the point of method binding to class) is available at the
> point of method injection, in this example, the next-to-last line of the
> code. So, is there a way to somehow
> inject/override/magically-make-it-appear the __class__ cell in 'method'
> such that super() starts working as expected again?
>
Hmm. I don't think it'd work for technical reasons, but in theory, the
MethodType constructor would be the place to do this. But injecting
methods into instances (as opposed to classes) is a sufficiently
unusual thing that it's probably safest to just use the two-arg super
and have done with it.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
super() in injected methods
Esteemed Python Gurus,
I think, I actually know the answer to this question, but - maybe beyond
reason - I'm hoping there to be some magic. Consider the following code:
from types import MethodType
class A(object):
pass
def m(self, x):
print(f"A.m({x})")
class B(A):
def m(self, x):
print(f"B.m({x})")
ss = super()
ss.m(x)
def method(self, s):
print(f"method({s})")
try:
ss = super() # <-- Complains about __class__ cell not being
found
except:
print("I shouldn't need to do this!")
ss = super(type(self), self) # <-- Works just fine
ss.m(s)
a = B()
a.m(41)
a.m = MethodType(method, a)
a.m(42)
In the function 'method', I try to access the super() class. Now, of
course that makes no sense as a stand-alone function, but it does, once
it gets injected as a method into 'a' below.
The two-parameter version of the call of course works without a hitch.
I think I actually understand why this is happening (some interpreter
magic around super() forcing the insertion of __class__, which that
doesn't happen when parsing a stand-alone function). I think I even
understand the rationale for it, which is that super() needs to be
statically evaluated.
Now to the question though: In theory this information (static type of
'self' at the point of method binding to class) is available at the
point of method injection, in this example, the next-to-last line of the
code. So, is there a way to somehow
inject/override/magically-make-it-appear the __class__ cell in 'method'
such that super() starts working as expected again?
Thanks,
Andras Tantos
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:24, Paul Bryan wrote: On Thu, 2021-02-11 at 17:56 +, Mr Flibble wrote: Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. When do you estimate this task will be completed? I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. I take it you don't hope to receive any support from those you're insulting by such a statement? Thanks for the sentiment but I am not relying on luck. By your conduct so far, I think you will also not be relying on the goodwill of this community. Personally I prefer telling it like it is (i.e. the truth) rather than walking on eggshells. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, 2021-02-11 at 17:56 +, Mr Flibble wrote: > Actually it is a relatively small task due to the neos universal > compiler's architectural design. If it was a large task I wouldn't > be doing it. When do you estimate this task will be completed? > I am not particularly interested in any of the existing > implementations as they bear no relation to the design of my language > agnostic universal compiler, runtime, VM and JIT; the only use they > will have will be to disambiguate certain Python language constructs > that I cannot disambiguate from documentation alone: this is a > natural consequence of Python not being standardized; those steering > the language need to grow a pair and get Python standardized > preferably as an ISO Standard. I take it you don't hope to receive any support from those you're insulting by such a statement? > Thanks for the sentiment but I am not relying on luck. By your conduct so far, I think you will also not be relying on the goodwill of this community. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:06, Chris Angelico wrote: On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble wrote: On 11/02/2021 16:31, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: Hi! I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform). I'd like to encourage you to give this a go. It's a huge task, but it's needed. Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. You may be interested in the approaches of Pypy, Cython, Shedskin and Nuitka. I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. You keep insulting Python and the Python devs. Put up or shut up - show some actual code before you make too many boasts. Python DOES have a strong language specification. Its semantics are documented. If you find places where the documentation is lacking, point them out specifically, don't FUD your way through. For a language to transition from "toy" status it has to be formally standardized. It is unacceptable to define a language in terms of a particular implementation. A git repo of Source code and associated observable dynamic behaviour when that code is compiled and ran is a poor substitute for an official ISO Standard. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:03, Chris Angelico wrote: In any case, it's not Python if it can't handle arbitrarily large numbers. Python is an excellent language for mathematics. I am also creating Ada and Haskell implementations which have a similar requirement. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble wrote: > > On 11/02/2021 16:31, Dan Stromberg wrote: > > On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble > > wrote: > > > >> > >> Hi! > >> > >> I am starting work on creating a new Python implementation from scratch > >> using "neos" my universal compiler that can compile any programming > >> language. I envision this implementation to be significantly faster than > >> the currently extant Python implementations (which isn't a stretch given > >> how poorly they perform). > >> > > > > I'd like to encourage you to give this a go. It's a huge task, but it's > > needed. > > Actually it is a relatively small task due to the neos universal compiler's > architectural design. If it was a large task I wouldn't be doing it. > > > > > You may be interested in the approaches of Pypy, Cython, Shedskin and > > Nuitka. > > I am not particularly interested in any of the existing implementations as > they bear no relation to the design of my language agnostic universal > compiler, runtime, VM and JIT; the only use they will have will be to > disambiguate certain Python language constructs that I cannot disambiguate > from documentation alone: this is a natural consequence of Python not being > standardized; those steering the language need to grow a pair and get Python > standardized preferably as an ISO Standard. > You keep insulting Python and the Python devs. Put up or shut up - show some actual code before you make too many boasts. Python DOES have a strong language specification. Its semantics are documented. If you find places where the documentation is lacking, point them out specifically, don't FUD your way through. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Fri, Feb 12, 2021 at 4:52 AM Mr Flibble wrote: > > On 11/02/2021 15:13, Chris Angelico wrote: > > On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble > > wrote: > >> > >> > >> Hi! > >> > >> I am starting work on creating a new Python implementation from scratch > >> using "neos" my universal compiler that can compile any programming > >> language. > > > > Is it your intention to support all of Python's syntax and semantics, > > Yes. > > > or is this an unrelated language with mandatory strict type tags and a > > severely restricted set of data types? For instance, can your neos > > compile this code? > > No. The neos universal compiler itself is language agnostic: a pre-requisite > for the requirement to be able to compile any programming language. > Okay, cool, then I misunderstood the point of neoscript (I thought you would compile Python to neoscript and then neoscript to binary). As Dan says, go for it, give it a go. I think it'll give you a very good demonstration of how CPython, and especially PyPy, are actually highly performant languages :) > You are timing the arithmetic library rather than the interpreter. Hmm, I didn't call on any library functions. The crucial and time-consuming operations were entirely implemented using operators on constants. (I also deliberately reused the name "time" in multiple ways, just to stress-test anything that tries to restrict data types.) In any case, it's not Python if it can't handle arbitrarily large numbers. Python is an excellent language for mathematics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 16:31, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: Hi! I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform). I'd like to encourage you to give this a go. It's a huge task, but it's needed. Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. You may be interested in the approaches of Pypy, Cython, Shedskin and Nuitka. I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. Pypy is a Python written in RPython, where RPython is a restricted subset of Python 2. It can translate RPython to C, or JIT compile pretty full Python code - 2.x or 3.x. It has trouble with C extension modules, as the CPython API for extension modules is pretty leaky. CFFI appears to be the big hope of fixing this problem, but most C extension modules still use the CPython C extension Module API. RPython doesn't interest me. neos will be using libffi for FFI. Cython transpiles a Python-like language to C. It allows you to intermix Python datatypes and C datatypes; the more you use C datatypes, the faster the result is. It can be slower if you aren't careful with your type conversions, but it can be faster if used well. It has a really nice --annotate option that shows how close to C your program is, line by line. I don't agree with the concept of delivering C compilers to end users. The only compilers I think end users should be running are GPU shader compilers and byecode/JIT compilers such as neos. Shedskin transpiles an implicitly static subset of Python 2 to C++. It's a great tool, but sadly it is unlikely to make the jump from Python 2 to Python 3, and Python 3 is definitely the future of Python. Not interested in that (see previous answer replacing "C" with "C++"). Nuitka is a Python -> C/C++ transpiler. I know little about it, but it sounds kind of like what you're proposing. It's been focusing on compatibility first, followed by performance. Bears no relation to neos architecture. Good luck! Thanks for the sentiment but I am not relying on luck. /Flibble -- 😎 -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 15:13, Chris Angelico wrote:
On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
wrote:
Hi!
I am starting work on creating a new Python implementation from scratch using
"neos" my universal compiler that can compile any programming language.
Is it your intention to support all of Python's syntax and semantics,
Yes.
or is this an unrelated language with mandatory strict type tags and a
severely restricted set of data types? For instance, can your neos
compile this code?
No. The neos universal compiler itself is language agnostic: a pre-requisite
for the requirement to be able to compile any programming language.
def power():
return (2**3**4**2) % 10
from time import time
start = time()
print(power())
time = time() - start
print("Took %s seconds" % time)
On my system, I get this from CPython 3.10:
176561152
Took 0.1589798927307129 seconds
And this from PyPy:
176561152
Took 0.0233387947083 seconds
I envision this implementation to be significantly faster than the currently
extant Python implementations (which isn't a stretch given how poorly they
perform).
Riight, yep, all existing Python implementations are terribly
slow. Go ahead then; run the code above, show me a better time, and of
course compare to what a recent off-the-shelf CPython can do on the
same hardware. Then see how PyPy performs at the same job.
You are timing the arithmetic library rather than the interpreter.
Sample neos session (parsing a fibonacci program, neoscript rather than Python
in this case):
Is neoscript an intermediate language like RPython, used only to
implement the compiler, or are you actually transforming Python code
into neoscript?
neoscript is the neos reference language (i.e. not an intermediate language)
and will be unrelated to the Python implementation.
/Flibble
--
😎
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: > > Hi! > > I am starting work on creating a new Python implementation from scratch > using "neos" my universal compiler that can compile any programming > language. I envision this implementation to be significantly faster than > the currently extant Python implementations (which isn't a stretch given > how poorly they perform). > I'd like to encourage you to give this a go. It's a huge task, but it's needed. You may be interested in the approaches of Pypy, Cython, Shedskin and Nuitka. Pypy is a Python written in RPython, where RPython is a restricted subset of Python 2. It can translate RPython to C, or JIT compile pretty full Python code - 2.x or 3.x. It has trouble with C extension modules, as the CPython API for extension modules is pretty leaky. CFFI appears to be the big hope of fixing this problem, but most C extension modules still use the CPython C extension Module API. Cython transpiles a Python-like language to C. It allows you to intermix Python datatypes and C datatypes; the more you use C datatypes, the faster the result is. It can be slower if you aren't careful with your type conversions, but it can be faster if used well. It has a really nice --annotate option that shows how close to C your program is, line by line. Shedskin transpiles an implicitly static subset of Python 2 to C++. It's a great tool, but sadly it is unlikely to make the jump from Python 2 to Python 3, and Python 3 is definitely the future of Python. Nuitka is a Python -> C/C++ transpiler. I know little about it, but it sounds kind of like what you're proposing. It's been focusing on compatibility first, followed by performance. Good luck! -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practices for software architecture in Python
In article , Henning Follmann wrote: >>>Looks like you (the project leader?) needs training, not the >>>software engineers. >>> >>>"Making Things Happen" by Scott Berkun >> >> This looks like a very interesting book to add to my reading list, but >> how do you think it will help the OP with his/her quest? >> >Well the question makes it very obvious that it is a leadership >issue. Does he really think giving all engineers the Gang of 4 >book will magically lead to a well run OOP project. >It all but always is about the leader. >> Of course your answer might just as well be: read the book! But since >> you clearly did that already, what knowledge did you gain that triggered >> this response? >Well this book exemplifies how to brake down the task of >leadership in the context of software development. >For me this seems like a match. But it could be both. You can be a good leader and still look for a good example of how to build a complex piece of software. Granted, it's probably easier to ask for bad examples. ;-) This is why I still don't see how you derived the quality of OP's leadership from this question. -- [J|O|R] <- .signature.gz -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
wrote:
>
>
> Hi!
>
> I am starting work on creating a new Python implementation from scratch using
> "neos" my universal compiler that can compile any programming language.
Is it your intention to support all of Python's syntax and semantics,
or is this an unrelated language with mandatory strict type tags and a
severely restricted set of data types? For instance, can your neos
compile this code?
def power():
return (2**3**4**2) % 10
from time import time
start = time()
print(power())
time = time() - start
print("Took %s seconds" % time)
On my system, I get this from CPython 3.10:
176561152
Took 0.1589798927307129 seconds
And this from PyPy:
176561152
Took 0.0233387947083 seconds
> I envision this implementation to be significantly faster than the currently
> extant Python implementations (which isn't a stretch given how poorly they
> perform).
Riight, yep, all existing Python implementations are terribly
slow. Go ahead then; run the code above, show me a better time, and of
course compare to what a recent off-the-shelf CPython can do on the
same hardware. Then see how PyPy performs at the same job.
> Sample neos session (parsing a fibonacci program, neoscript rather than
> Python in this case):
Is neoscript an intermediate language like RPython, used only to
implement the compiler, or are you actually transforming Python code
into neoscript?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Best practices for software architecture in Python
On 2021-02-11, Oscar wrote: > In article , > Henning Follmann wrote: >>On 2021-02-10, Python wrote: >>> Hi, >>> >>> If you had to train engineers who are used to write >>> Python scripts for image processing, data format conversion, >>> etc. (so they know most the basics of Python types and >>> programming structures except advanced OOP techniques) >>> who now are about to develop quite a big application >>> in the same field (to get rid of some well known proprietary >>> scientific software monoliths), and would like to study in-depth >>> an existing open source application in order to study how >>> to organize classes hierarchy, modules, packages, etc. which >>> one would you recommend ? >>> >>> P. >> >>Looks like you (the project leader?) needs training, not the >>software engineers. >> >>"Making Things Happen" by Scott Berkun > > This looks like a very interesting book to add to my reading list, but > how do you think it will help the OP with his/her quest? > Well the question makes it very obvious that it is a leadership issue. Does he really think giving all engineers the Gang of 4 book will magically lead to a well run OOP project. It all but always is about the leader. > Of course your answer might just as well be: read the book! But since > you clearly did that already, what knowledge did you gain that triggered > this response? Well this book exemplifies how to brake down the task of leadership in the context of software development. For me this seems like a match. -H -- Henning Follmann | hfollm...@itcfollmann.com -- https://mail.python.org/mailman/listinfo/python-list
New Python implementation
Hi!
I am starting work on creating a new Python implementation from scratch using
"neos" my universal compiler that can compile any programming language. I
envision this implementation to be significantly faster than the currently extant Python
implementations (which isn't a stretch given how poorly they perform).
Sample neos session (parsing a fibonacci program, neoscript rather than Python
in this case):
neos 1.0.0.0 ED-209
] help
h(elp)
s(chema)Load language schema
l(oad) Load program
list List program
c(ompile)Compile program
r(un)Run program
![] Evaluate expression (enter interactive
mode if expression omitted)
: Input (as stdin)
q(uit) Quit neos
lc List loaded concept libraries
t(race) <0|1|2|3|4|5> [] Compiler trace
m(etrics)Display metrics for running programs
] lc
[neos.core] (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.ncl)
[neos.boolean]
[neos.language]
[neos.logic]
[neos.math]
[neos.module]
[neos.object]
[neos.string]
[neos.math.universal]
(file:///D:\code\neos\build\win32\vs2019\x64\Release\core.math.universal.ncl)
] s neoscript
Loading schema 'neoscript'...
Language: Default neoGFX scripting language
Version: 1.0.0
Copyright (C) 2019 Leigh Johnston
neoscript] l examples/neoscript/fibonacci.neo
neoscript] list
File 'examples/neoscript/fibonacci.neo':
-- neoscript example: Fibonacci
using neos.string;
using neos.stream;
import fn to_string(x : i32) -> string;
import fn to_integer(s : string) -> i32;
import proc input(s : out string);
import proc print(s : in string);
-- functions are pure
def fn add(x, y : i32) -> i32
{
return x + y;
}
def fn fib(x : i32) -> i32
{
if (x < 2)
return 1;
else
return add(fib(x-1), fib(x-2));
}
-- procedures are impure
def proc main()
s : string;
{
print("Enter a positive "
"integer: ");
input(s);
print("Fibonacci(" + s + ") = " + to_string(fib(to_integer(s))) + "\n");
}
neoscript] t 1
neoscript] c
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.period()
folded: string.utf8(gnirts) <- string.utf8.character.period() =
string.utf8(gnirts.)
folding: string.utf8(gnirts.) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.) <- string.utf8.character.alpha() =
string.utf8(gnirts.s)
folding: string.utf8(gnirts.s) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.s) <- string.utf8.character.alpha() =
string.utf8(gnirts.so)
folding: string.utf8(gnirts.so) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.so) <- string.utf8.character.alpha() =
string.utf8(gnirts.soe)
folding: string.utf8(gnirts.soe) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.soe) <- string.utf8.character.alpha() =
string.utf8(gnirts.soen)
folding: source.package.name() <- string.utf8(gnirts.soen)
folded: source.package.name() <- string.utf8(gnirts.soen) =
source.package.name(neos.string)
folding: source.package.import() <- source.package.name(neos.string)
folded: source.package.import() <- source.package.name(neos.string) =
source.package.import(neos.string)
folding: source.package.import(neos.string) <-
source.package.import(neos.string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded:
Re: Best practices for software architecture in Python
In article , Henning Follmann wrote: >On 2021-02-10, Python wrote: >> Hi, >> >> If you had to train engineers who are used to write >> Python scripts for image processing, data format conversion, >> etc. (so they know most the basics of Python types and >> programming structures except advanced OOP techniques) >> who now are about to develop quite a big application >> in the same field (to get rid of some well known proprietary >> scientific software monoliths), and would like to study in-depth >> an existing open source application in order to study how >> to organize classes hierarchy, modules, packages, etc. which >> one would you recommend ? >> >> P. > >Looks like you (the project leader?) needs training, not the >software engineers. > >"Making Things Happen" by Scott Berkun This looks like a very interesting book to add to my reading list, but how do you think it will help the OP with his/her quest? Of course your answer might just as well be: read the book! But since you clearly did that already, what knowledge did you gain that triggered this response? -- [J|O|R] <- .signature.gz -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable defaults
Thank you, if anybody finds such an example in the wild where using a
mutable default is actually better than a global or closure I would be
happy to learn about it!
About the proposal, this is a quick PoC of the @default decorator:
import inspect
def default(**defaults):
def decorator(func):
def wrapper(*args, **kwargs):
signature = inspect.signature(func)
bound = signature.bind(*args, **kwargs)
for key, value in defaults.items():
if key in bound.arguments:
continue
defaultsig = inspect.signature(value)
defaultargs = {
k: v
for k, v in bound.arguments.items()
if k in defaultsig.parameters
}
bound.arguments[key] = value(**defaultargs)
return func(*bound.args, **bound.kwargs)
return wrapper
return decorator
@default(x=lambda: [], y=lambda x: len(x))
def foo(x=None, y=None):
return x, y
assert foo() == ([], 0)
assert foo([1]) == ([1], 1)
assert foo(y=2) == ([], 2)
assert foo(y=2, x=[2]) == ([2], 2)
It seems pretty obvious to have this shorthand syntax:
def foo (x=default: [], y=default: len(x)):
=default: defines a lambda returning the default value to use for a keyword
argument. We can't use x=lambda: here because that would define a lambda as
default argument, so that's why we *need* another keyword. Also, note that
it gets the any other bound argument as parameter so far from left to
right, which makes y=default: len(x) possible.
=: is the contraction, proposing an even simpler syntax:
def foo (x=:[], y=:len(x)):
Chris, I understand your concerns about having arguments in there, but I'd
like to try to defend y=:len(x) for a bit because I really like your idea,
I think this is pythonic and will contribute to justify this feature and
keep python apart from other languages by offering more powerful and
expressive syntax than alternatives.
Le jeu. 11 févr. 2021 à 08:38, Chris Angelico a écrit :
> On Thu, Feb 11, 2021 at 6:03 PM Ross Wilson wrote:
> >
> > On Thu, 11 Feb 2564 BE at 12:52 Grant Edwards >
> > wrote:
> >
> > > On 2021-02-11, J. Pic wrote:
> > >
> > > > I just meant removing the whole "default value mutating" story, not
> > > > removing mutable variables. Really, I was wondering if there was a
> use
> > > case
> > > > where this actually turns to an advantage,
> > >
> > > I've seen people show how it can be used to provide function-scope
> > > persistent storage -- the equivalent of declaring a static variable in
> > > a C function. I don't think I've seen that done in the wild, though.
> >
> >
> > Not sure this qualifies as "use in the wild", but the memoized naive
> > Fibonacci is very nice when written this way:
> >
> > def fib(n, memo={0: 0, 1: 1}):
> > if n not in memo:
> > memo[n] = fib(n-1) + fib(n-2)
> > return memo[n]
>
> Yep, that's a pretty elegant example of mutable defaults as statics.
> In theory, you could use this for a Fibonacci-like sequence, just by
> passing an appropriate memo dictionary; to make that work, the
> recursive calls would have to pass that down the line.
>
> # What comes next in the sequence 1 3 4 7 11?
> fib(6, {1:1, 2:3})
>
> But otherwise, the memo parameter isn't really being used as a
> parameter, it's just a way to maintain state. It could just as easily
> be a global, a closure cell, or anything else.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
