On 24/05/2023 15:37, A KR wrote:
It is perfectly explained in the standards here [1] saying that:
In order to avoid infinite recursion in this method, its implementation should
always call the base class method with the same name to access any attributes
it needs, for example, object
It is perfectly explained in the standards here [1] saying that:
In order to avoid infinite recursion in this method, its implementation should
always call the base class method with the same name to access any attributes
it needs, for example, object.__getattribute__(self, name).
Therefore
Please stay on the list (such that others can help, too)
Ben Hirsig wrote at 2022-7-29 06:53 +1000:
>Thanks for the replies, I'm just trying to understand why this would be
>useful?
>
>E.g. why does max need a min/max/resolution, and why would these attributes
>themselves need a min/max/resolution
les-of-usage-timedelta
>
>
>
>It appears as though the timedelta object recursively adds its own
>attributes (min, max, resolution) as further timedelta objects. I’m not
>sure how deep they go, but presumably hitting the recursion limit.
If you look at the source, you will see that
ge-timedelta
>
> It appears as though the timedelta object recursively adds its own
> attributes (min, max, resolution) as further timedelta objects. I’m not
> sure how deep they go, but presumably hitting the recursion limit.
>
>>from datetime import timedelta
>>year
It appears as though the timedelta object recursively adds its own
attributes (min, max, resolution) as further timedelta objects. I’m not
sure how deep they go, but presumably hitting the recursion limit.
from datetime import timedelta
year = timedelta(days=365)
print(year.max
object recursively adds its own
attributes (min, max, resolution) as further timedelta objects. I’m not
sure how deep they go, but presumably hitting the recursion limit.
>from datetime import timedelta
>year = timedelta(days=365)
>print(year.max)
9 days, 23:59:59.9
On 26/06/2022 23.00, נתי שטרן wrote:
> I FIXED THE CODE
For the benefit of future-readers: how did you go about fixing it? What
was wrong?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
k
> >
> > return sre_compile.compile(
> > pattern, flags | p.state.flags, code,
> > p.state.groups-1,
> > groupindex, tuple(indexgroup)
> > )
>
>
> Why would any code give a recursion error?
>
> With recursion problem
and i ask also what's the problem with this function:
def _code(p, flags):
flags = p.state.flags | flags
code = []
# compile info block
sre_compile._compile_info(code, p, flags)
# compile the pattern
sre_compile._compile(code, p.data, flags)
for k, i in groupindex.items():
> indexgroup[i] = k
>
> return sre_compile.compile(
> pattern, flags | p.state.flags, code,
> p.state.groups-1,
> groupindex, tuple(indexgroup)
> )
Why would any code give a recu
stack trace:
File "\\Weank-fs\users$\NetanelST\ORACLE\RTR.py", line 5387, in
class bottle:
File "\\Weank-fs\users$\NetanelST\ORACLE\RTR.py", line 5694, in bottle
class Router(object):
File "\\Weank-fs\users$\NetanelST\ORACLE\RTR.py", line 5736, in Router
rule_syntax = re.compil
def compile(p, flags=0):
# internal: convert pattern list to internal format
if (isinstance(p,str)):
pattern = p
p = sre_parse.parse(p, flags)
else:
pattern = None
code = _code(p, flags)
if flags & SRE_FLAG_DEBUG:
On Thu, 4 Nov 2021 08:57:14 +0100, ast wrote:
> > li = []
> > li.append(li)
> > li
> [[...]]
>
> >li[0][0][0][0]
> [[...]]
>
> That's funny
After the coming AI upheaval, such cruelty to machines will
be considered punishable and not funny.
--
To email me, substitute nowhere->runbox, invalid->c
> li = []
> li.append(li)
> li
[[...]]
>li[0][0][0][0]
[[...]]
That's funny
--
https://mail.python.org/mailman/listinfo/python-list
ast writes:
>> li = []
>> li.append(li)
>> li
> [[...]]
>
>>li[0][0][0][0]
> [[...]]
>
> That's funny
>
You made a list whose only element is itself.
In [1]: li = []
In [3]: li.append(li)
In [4]: li[0] is li
Out[4]: True
--
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8D
b = [bmax,bmin];
For conceptual clarity we present the algorithm in recursion fashion. Wecomment
on the truncation. The TBiSort recursion goes downward first portioning the
initial data list a all the way to the base level (sublist length 1), then goes
upward with monotonic merges. In TBiMerg
On Tue, 30 May 2017 05:58 pm, Nagy Lc3a1szlc3b3 Zsolt wrote:
>> It was easier than I thought. It seems that zeep has a problem
>> processing a basic WS-Security STS (Security Token Service, plain
>> username+password authentication) document. I have changed the endpoint
>> URL to example.com. Tota
Nagy László Zsolt wrote:
>
>
>> It was easier than I thought. It seems that zeep has a problem
>> processing a basic WS-Security STS (Security Token Service, plain
>> username+password authentication) document. I have changed the endpoint
>> URL to example.com. Total size 11K compressed. I hope
> It was easier than I thought. It seems that zeep has a problem
> processing a basic WS-Security STS (Security Token Service, plain
> username+password authentication) document. I have changed the endpoint
> URL to example.com. Total size 11K compressed. I hope it is okay to
> attach here.
It wa
> There are less than 100 elements defined in the WSDL, so it cannot be
> the problem. It might be a recursive data definition, but then it should
> be handled by zeep instead of entering into an intinite recursion.
>
> Well, I'll be working on an MWE and post it here later.
>> line 259, in signature
>> from zeep.xsd import ComplexType
>> RecursionError: maximum recursion depth exceeded
>>
>> Looks like an infinite recursion to me. Due to a non-disclosure
>> agreement, I'm not able to send you the example wsdl.
> S
Nagy László Zsolt wrote:
> Running this command:
>
> python3.6 -m zeep exmaple.wsdl
This example is no more, we heave ceased to see it, it's gone to meet its
maker... this is an ex-ex-ample.
> line 259, in signature
> from zeep.xsd import ComplexType
> RecursionE
Nagy László Zsolt writes:
> Running this command:
>
> python3.6 -m zeep exmaple.wsdl
>
> I get this (this is only the end of the traceback):
>
...
> from zeep.xsd import ComplexType
> RecursionError: maximum recursion depth exceeded
>
> Looks like an infinite
ocal/lib/python3.6/dist-packages/zeep/xsd/elements/indicators.py",
line 561, in signature
parts.append('{%s: %s}' % (name, element.signature(schema,
standalone=False)))
File
"/usr/local/lib/python3.6/dist-packages/zeep/xsd/elements/element.py",
line 259, in signature
from z
On Wed, 05 Oct 2016 17:30:22 -0700, 380162267qq wrote:
> Google told me Python name is a label attaching to the object.
> But in this recursive function,the name 'a' will point to different
> number object.
>
> def rec(a):
> a+=1 if a<10:
> rec(a)
> print(a)
>
> rec(0)
38016226...@gmail.com wrote:
def rec(a):
a+=1
if a<10:
rec(a)
print(a)
rec(0) gives me 101 normally.Why it works? Because of the stack memory
management?
Yes. There isn't just one 'a' here, there's a different one
each time rec is called.
Thank yo
38016226...@gmail.com writes:
> Google told me Python name is a label attaching to the object.
Well, “Google told me” has no necessary bearing on whether it's true :-)
so that's not a good citation to give.
If you need to know what Python terminology means, the Python
documentation is better.
Google told me Python name is a label attaching to the object.
But in this recursive function,the name 'a' will point to different number
object.
def rec(a):
a+=1
if a<10:
rec(a)
print(a)
rec(0) gives me 101 normally.Why it works? Because of the stack
The version 1.1 of the tco module is released. It is much more owerful since
it now allows nested systems of continuations. The most important is probably
rather that I took the time to write a very detailed presentation of the
module on my blog: http://baruchel.github.io/
Regards, tb.
--
https:/
On Thu, Aug 6, 2015 at 2:51 AM, Rustom Mody wrote:
> And I continue to have no idea what Chris is talking about.
> Here is C printf
from ctypes import *
cdll.LoadLibrary("libc.so.6")
libc = CDLL("libc.so.6")
libc.printf(b"%s", b"Hello")
> 5
> Hello>>>
>
> As far as I can see pr
On Wednesday, August 5, 2015 at 10:11:30 PM UTC+5:30, wrote:
> On Wednesday, August 5, 2015 at 10:29:21 AM UTC-6, Chris Angelico wrote:
> > On Thu, Aug 6, 2015 at 2:10 AM, Rustom Mody wrote:
> > > 1 + x
> > > does not *call* 1 .__add__(x)
> > > It *is* that
> > > [Barring corner cases of radd etc
On Wednesday, August 5, 2015 at 10:29:21 AM UTC-6, Chris Angelico wrote:
> On Thu, Aug 6, 2015 at 2:10 AM, Rustom Mody wrote:
> > 1 + x
> > does not *call* 1 .__add__(x)
> > It *is* that
> > [Barring corner cases of radd etc]
> > IOW I am desugaring the syntax into explicit method-calls so you can
On Thu, Aug 6, 2015 at 2:10 AM, Rustom Mody wrote:
> 1 + x
> does not *call* 1 .__add__(x)
> It *is* that
> [Barring corner cases of radd etc]
> IOW I am desugaring the syntax into explicit method-calls so you can see
> all the calls explicitly
> Then it becomes evident -- visibly and in fact --th
1 PM UTC+5:30, jennyf...@gmail.com
> > > wrote:
> > > > I am trying to learn differences between tail recursion and non tail
> > > > recursion.
> > > >
> > > > Is the following recursive code tail recursive?
> > > > If it is not how
differences between tail recursion and non tail
> > > recursion.
> > >
> > > Is the following recursive code tail recursive?
> > > If it is not how to convert it to tail recursion?
> > > If it is how to convert it to non tail recursion?
> > >
On Wednesday, August 5, 2015 at 9:52:14 AM UTC-6, Chris Angelico wrote:
> On Thu, Aug 6, 2015 at 1:13 AM, wrote:
> > I am trying to learn differences between tail recursion and non tail
> > recursion.
>
> Tail recursion is where you do exactly this:
>
&g
dition function is pretty
pointless. I mean, sure, it's technically a sort of tail call, but
it's definitely not tail recursion, and it's such a trivial operation
(adding one to a probably-small number) that it's hardly even worth
mentioning. The main point of tail recursion is
On Thu, Aug 6, 2015 at 1:13 AM, wrote:
> I am trying to learn differences between tail recursion and non tail
> recursion.
Tail recursion is where you do exactly this:
return some_function(...)
Absolutely nothing is allowed to happen around or after that function,
and that also mea
On Wednesday, August 5, 2015 at 9:21:33 AM UTC-6, Rustom Mody wrote:
> On Wednesday, August 5, 2015 at 8:43:31 PM UTC+5:30, jennyf...@gmail.com
> wrote:
> > I am trying to learn differences between tail recursion and non tail
> > recursion.
> >
> > Is the following
On Wednesday, August 5, 2015 at 8:43:31 PM UTC+5:30, jennyf...@gmail.com wrote:
> I am trying to learn differences between tail recursion and non tail
> recursion.
>
> Is the following recursive code tail recursive?
> If it is not how to convert it to tail recursion?
> If it is
I am trying to learn differences between tail recursion and non tail recursion.
Is the following recursive code tail recursive?
If it is not how to convert it to tail recursion?
If it is how to convert it to non tail recursion?
class CastleDefenseI:
INFINITY = 9
def __init__(self
On 7/28/2015 5:28 PM, Paul Rubin wrote:
Chris Angelico was asking for examples of tail recursion that didn't
have obvious looping equivalents.
Since there is a mechanical procedure for producing the equivalent
*under the assumption that the function name will not be rebound*,
On Jul 28, 2015 1:36 PM, "Paul Rubin" wrote:
>
> Paul Rubin writes:
> > Chris Angelico was asking for examples of tail recursion that didn't
> > have obvious looping equivalents. Here's an Euler problem solution
> > using memoization and (e
Paul Rubin writes:
> Chris Angelico was asking for examples of tail recursion that didn't
> have obvious looping equivalents. Here's an Euler problem solution
> using memoization and (except that Python doesn't implement it) tail
> recursion with an accumulator.
Actu
Chris Angelico was asking for examples of tail recursion that didn't
have obvious looping equivalents. Here's an Euler problem solution
using memoization and (except that Python doesn't implement it) tail
recursion with an accumulator.
# Solution to Euler problem 14, us
Hi Thomas, I like what you've been doing.
I think it would also be great if the "leave the loop" detector would be the
actual stop condition in the recursion, applied to the arguments of the call.
That would of course force you to split the recursive function in two
functions: on
On 10/08/2013 02:22 AM, Steven D'Aprano wrote:
On Mon, 07 Oct 2013 20:27:13 -0700, Mark Janssen wrote:
But even putting that aside, even if somebody wrote such a
description, it would be reductionism gone mad. What possible light
on the problem would be shined by a long, long list of machine co
Alain Ketterlin writes:
> Antoon Pardon writes:
>
> > Op 07-10-13 19:15, Alain Ketterlin schreef:
>
> [...]
> >> That's fine. My point was: you can't at the same time have full
> >> dynamicity *and* procedural optimizations (like tail call opt).
> >> Everybody should be clear about the trade-off.
o have serious short comings that couldn't be remedied easily?
>
> The entire point of tail call optimization requires not keeping the
> intervening stack frames around, in _any_ form, so as to allow
> arbitrarily deep recursion without ever having the possibility of a
> stac
On Mon, 07 Oct 2013 20:27:13 -0700, Mark Janssen wrote:
But even putting that aside, even if somebody wrote such a
description, it would be reductionism gone mad. What possible light
on the problem would be shined by a long, long list of machine code
operations, even if written
Op 08-10-13 01:50, Steven D'Aprano schreef:
> On Mon, 07 Oct 2013 15:47:26 -0700, Mark Janssen wrote:
>
>> I challenge you to get
>> down to the machine code in scheme and formally describe how it's doing
>> both.
>
> For which machine?
>
> Or are you assuming that there's only one machine code
Antoon Pardon writes:
> Op 07-10-13 19:15, Alain Ketterlin schreef:
[...]
>> That's fine. My point was: you can't at the same time have full
>> dynamicity *and* procedural optimizations (like tail call opt).
>> Everybody should be clear about the trade-off.
>
> Your wrong. Full dynamics is not i
the arguments and jump to the top of this
> function". Some people have introduced the idea of _further_
> optimizations, transforming "near" tail recursion (i.e. return self()+1)
> into tail recursion, and _that_ depends on knowing the identity of the
> function (though a
Steven D'Aprano writes:
> Far more useful would be a high-level description of Scheme's
> programming model. If names can be rebound on the fly, how does
> Scheme even tell whether something is a recursive call or not?
>
> def foo(arg):
> do stuff here
> foo(arg-1) # how does Scheme know
random...@fastmail.us writes:
> The entire point of tail call optimization requires not keeping the
> intervening stack frames around, in _any_ form, so as to allow
> arbitrarily deep recursion without ever having the possibility of a
> stack overflow. An implementation which reduced
>> Yeah, and this is where two models of computation have been conflated,
>> creating magical effects, confusing everybody. I challenge you to get
>> down to the machine code in scheme and formally describe how it's
>> doing both.
>
> Which two models of computation are you talking about? And what
>>> But even putting that aside, even if somebody wrote such a description,
>>> it would be reductionism gone mad. What possible light on the problem
>>> would be shined by a long, long list of machine code operations, even
>>> if written using assembly mnemonics?
>>
>> Only that you've got a consi
ll optimization there is no
need to do tail recursion optimization.
--
Piet van Oostrum
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
--
https://mail.python.org/mailman/listinfo/python-list
Mark Janssen writes:
> Yeah, and this is where two models of computation have been conflated,
> creating magical effects, confusing everybody. I challenge you to get
> down to the machine code in scheme and formally describe how it's
> doing both.
Which two models of computation are you talking
On Mon, 07 Oct 2013 17:16:35 -0700, Mark Janssen wrote:
> It's like this: there *should* be one-to-one mappings between the
> various high-level constructs to the machine code, varying only between
> different chips (that is the purpose of the compiler after all), yet for
> some operations, in lan
On Mon, Oct 7, 2013 at 4:50 PM, Steven D'Aprano
wrote:
> On Mon, 07 Oct 2013 15:47:26 -0700, Mark Janssen wrote:
>> I challenge you to get
>> down to the machine code in scheme and formally describe how it's doing
>> both.
>
> For which machine?
Right, I should stop assuming a modern implementati
> Only that you've got a consistent, stable (and therefore,
> formalizable) translation from your language to the machine. That's
> all. Everything else is magic. Do you know that the Warren
> Abstraction Engine used to power the predicate logic in Prolog into
> machien code for a VonNeumann mac
On Mon, 07 Oct 2013 15:47:26 -0700, Mark Janssen wrote:
> I challenge you to get
> down to the machine code in scheme and formally describe how it's doing
> both.
For which machine?
Or are you assuming that there's only one machine code that runs on all
computing devices?
Frankly, asking some
>> That's fine. My point was: you can't at the same time have full
>> dynamicity *and* procedural optimizations (like tail call opt).
>> Everybody should be clear about the trade-off.
>
> Your wrong. Full dynamics is not in contradiction with tail call
> optimisation. Scheme has already done it for
Alain Ketterlin writes:
> BTW, does the original callable object have a ref counter? Is it garbage
> collected in that case? If not, would it be considered a bug?
In CPython ALL objects have ref counters.
--
Piet van Oostrum
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
--
https
On 07/10/2013 18:57, Antoon Pardon wrote:
Op 07-10-13 19:15, Alain Ketterlin schreef:
I want to consider here what it would mean to concretely
implement the abstract notion 'disallow rebinding of function
names' and show what would be behind calling the idea 'not
feasible'.
Again, I'm more con
all optimization requires not keeping the
intervening stack frames around, in _any_ form, so as to allow
arbitrarily deep recursion without ever having the possibility of a
stack overflow. An implementation which reduced but did not eliminate
the space used per call would not be worthwhile because it
ve introduced the idea of _further_
optimizations, transforming "near" tail recursion (i.e. return self()+1)
into tail recursion, and _that_ depends on knowing the identity of the
function (though arguably that could be accounted for at the cost of
including dead code for the path that as
On 10/7/2013 1:15 PM, Alain Ketterlin wrote:
Terry Reedy writes:
3. Python does not mandate how namespaces are implemented. CPython
uses both dicts and, for function local namespaces, internal C arrays.
So 'names' in code can become either string keys for dicts or integer
indexes for arrays.
Op 07-10-13 19:15, Alain Ketterlin schreef:
I want to consider here what it would mean to concretely implement the
abstract notion 'disallow rebinding of function names' and show what
would be behind calling the idea 'not feasible'.
Again, I'm more concerned about the function than about the na
Terry Reedy writes:
> On 10/4/2013 5:49 AM, Alain Ketterlin wrote:
>
>> I think allowing rebinding of function names is extremely strange,
>
> Steven already countered the 'is extremely strange' part by showing
> that such rebinding is common, generally useful, and only occasionally
> dodgy and a
Op 04-10-13 23:14, Terry Reedy schreef:
On 10/4/2013 6:46 AM, Ian Kelly wrote:
On the other hand, if you start optimizing every tail call and not
just the recursive functions, then I can see where that could start to
get problematic for debugging -- as arbitrary functions get removed
from the s
On 10/4/2013 5:49 AM, Alain Ketterlin wrote:
I think allowing rebinding of function names is extremely strange,
Steven already countered the 'is extremely strange' part by showing that
such rebinding is common, generally useful, and only occasionally dodgy
and a candidate for being blocked.
On 10/4/2013 6:46 AM, Ian Kelly wrote:
On the other hand, if you start optimizing every tail call and not
just the recursive functions, then I can see where that could start to
get problematic for debugging -- as arbitrary functions get removed
from the stack traces just because they happened to
Ian Kelly wrote:
> On Fri, Oct 4, 2013 at 4:41 AM, Ian Kelly wrote:
>> There is no doubt that it's a tail call. Whether it is recursion is
>> irrelevant to optimizing it. The reason we talk about "tail call
>> recursion" specifically is because the recursi
if it is just updates the
> >> arguments and jumps to the start of the code block.
> >
> > Tail call optimization doesn't involve verification that the
> > function is calling itself; you just have to verfify that the
> > call is in tail position.
>
&g
On Thursday, October 3, 2013 10:57:48 PM UTC+5:30, Ravi Sahni wrote:
> On Wed, Oct 2, 2013 at 10:46 AM, rusi wrote:
> > 4. There is a whole spectrum of such optimizaitons --
> > 4a eg a single-call structural recursion example, does not need to push
> > return address on the
On Fri, 04 Oct 2013 11:49:26 +0200, Alain Ketterlin wrote:
> I think allowing rebinding of function names is extremely strange,
It's not, it's quite common. Functions in Python are first-class values,
and we can do things like this:
from somelibrary import somethingwithalonglongname as shortnam
On Fri, Oct 4, 2013 at 4:41 AM, Ian Kelly wrote:
> There is no doubt that it's a tail call. Whether it is recursion is
> irrelevant to optimizing it. The reason we talk about "tail call
> recursion" specifically is because the recursive case is the one that
> makes
as the current function and if it is just updates the
>>> arguments and jumps to the start of the code block.
>>
>> Tail call optimization doesn't involve verification that the
>> function is calling itself; you just have to verfify that the
>> call is in tail
d jumps to the start of the code block.
>
> Tail call optimization doesn't involve verification that the
> function is calling itself; you just have to verfify that the
> call is in tail position.
You misunderstood me. As usually implemented tail call recursion doesn't
requ
Mark Janssen writes:
> def fact(n): return 1 if n <= 1 else n * fact(n-1)
>> class Strange:
>> ...
>> def __le__(dummy):
>> global fact
>> fact = someotherfun # this is "binding"
>> return false
>> You cannot prevent this in python.
> No, but you can't prevent a lot of bad
On Thursday, October 3, 2013 5:33:27 AM UTC+8, Terry Reedy wrote:
> On 10/2/2013 8:31 AM, random...@fastmail.us wrote:
>
> > On Tue, Oct 1, 2013, at 17:30, Terry Reedy wrote:
>
> >> Part of the reason that Python does not do tail call optimization is
>
> >&
On Thu, 03 Oct 2013 10:09:25 -0400, random832 wrote:
> Speaking of assumptions, I would almost say that we should make the
> assumption that operators (other than the __i family, and
> setitem/setattr/etc) are not intended to have visible side effects. This
> would open a _huge_ field of potential
On Wed, 02 Oct 2013 22:41:00 -0400, Terry Reedy wrote:
> I am referring to constant-value objects included in the code object.
> >>> def f(): return (1,2,3)
>
> >>> f.__code__.co_consts
> (None, 1, 2, 3, (1, 2, 3))
Okay, now that's more clear. I didn't understand what you meant before.
So lon
random...@fastmail.us writes:
> Hey, while we're on the subject, can we talk about frozen(set|dict)
> literals again? I really don't understand why this discussion fizzles
> out whenever it's brought up on python-ideas.
Can you start us off by searching for previous threads discussing it,
and sum
On 10/2/2013 10:34 PM, Steven D'Aprano wrote:
You are both assuming that LOAD_CONST will re-use the same tuple
(1, 2, 3) in multiple places.
No I did not. To save tuple creation time, a pre-compiled tuple is
reused when its display expression is re-executed. If I had been
interested in multi
On Wed, Oct 2, 2013 at 10:46 AM, rusi wrote:
> 4. There is a whole spectrum of such optimizaitons --
> 4a eg a single-call structural recursion example, does not need to push
> return address on the stack. It only needs to store the recursion depth:
>
> If zero jump to outside ret
On 2013-10-03, Duncan Booth wrote:
>> How do know that either "<=" or "*" didn't rebind the name
>> "fact" to something else? I think that's the main reason why
>> python cannot apply any procedural optimization (even things
>> like inlining are impossible, or possible only under very
>> conservat
Alain Ketterlin wrote:
> Terry Reedy writes:
>
>> Part of the reason that Python does not do tail call optimization is
>> that turning tail recursion into while iteration is almost trivial,
>> once you know the secret of the two easy steps. Here it is.
>>
>&g
On Wed, Oct 2, 2013, at 22:34, Steven D'Aprano wrote:
> You are both assuming that LOAD_CONST will re-use the same tuple
> (1, 2, 3) in multiple places. But that's not the case, as a simple test
> will show you:
>>> def f():
... return (1, 2, 3)
>>> f() is f()
True
It does, in fact, re-use it
On Wed, Oct 2, 2013, at 21:46, MRAB wrote:
> > The difference is that a tuple can be reused, so it makes sense for the
> > comiler to produce it as a const. (Much like the interning of small
> > integers) The list, however, would always have to be copied from the
> > compile-time object. So that
On Wed, Oct 2, 2013, at 17:33, Terry Reedy wrote:
> 5. Conversion of apparent recursion to iteration assumes that the
> function really is intended to be recursive. This assumption is the
> basis for replacing the recursive call with assignment and an implied
> internal goto. Th
On Thu, Oct 3, 2013 at 12:34 PM, Steven D'Aprano
wrote:
> py> def f():
> ... a = (1, 2, 3)
> ... b = (1, 2, 3)
> ... return a is b
> ...
> py> f() # Are the tuples the same object?
> False
That just means the compiler doesn't detect reuse of the same tuple.
But compare:
>>> def f():
an find versions that lack the last item.
--
The language is as conservative about mandating optimizations as the
implementation is about doing them. I consider making None, False, True
be un-rebindable keynames to be an optimization. This is not even for
the other singletons Ellipsis
On 10/2/2013 9:46 PM, MRAB wrote:
On 03/10/2013 02:39, Dave Angel wrote:
On 2/10/2013 21:24, Steven D'Aprano wrote:
On Wed, 02 Oct 2013 18:17:06 -0400, Terry Reedy wrote:
CPython core developers have be very conservative about what
tranformations they put into the compiler. (1,2,3) can alway
On Thu, 03 Oct 2013 02:46:53 +0100, MRAB wrote:
> On 03/10/2013 02:39, Dave Angel wrote:
>> On 2/10/2013 21:24, Steven D'Aprano wrote:
>>
>>> On Wed, 02 Oct 2013 18:17:06 -0400, Terry Reedy wrote:
>>>
CPython core developers have be very conservative about what
tranformations they put in
On 03/10/2013 02:39, Dave Angel wrote:
On 2/10/2013 21:24, Steven D'Aprano wrote:
On Wed, 02 Oct 2013 18:17:06 -0400, Terry Reedy wrote:
CPython core developers have be very conservative about what
tranformations they put into the compiler. (1,2,3) can always be
compiled as a constant, and so
On 2/10/2013 21:24, Steven D'Aprano wrote:
> On Wed, 02 Oct 2013 18:17:06 -0400, Terry Reedy wrote:
>
>> CPython core developers have be very conservative about what
>> tranformations they put into the compiler. (1,2,3) can always be
>> compiled as a constant, and so it is. [1,2,3] might or might
1 - 100 of 570 matches
Mail list logo
