Just found really strange bug in text statement. I'm sure it is really rare bug but I'm also sure it should be fixed ASAP. Let me expain when we can notice this strange bug.
I found this bug when I tried to text string which contain lenght of list . As a result my string displayed wrong lenght of list. I was confused cos I assumed text statement cannot be bugged.
But after few tries to solve my problem I tried to display len(L.copy() ) and bingo copy() method worked well with text statement in this case.
This bug is rare cos it depend on what kind of arguments are in text statement. If text statement contain name of string so in this case we cannot notice this bug .
But if we have string as a literals between " " we can discover this bug.
I found this in RenPy 7.4.4.1489 - i didnt tried catch it in other versions yet.
Let me know guys if you can replicate this bug in this one version or in others.
dude how about showing the code that bugs?? makes it much easier to see if we have the same bug.
also, you could be doing something wrong. we dont know.
as are result the line in RenPy looks like
Files count: 94 94
despite i'm using this code in different directories for actual number of files different than 94
but if I'm using text statement in a bit other way like this below i get correct result
text synaptic + ( " %90s %3d " % ( ' ' , len(f22f) )
# where synaptic is string type - this var contain path to directory with files I'm trying to count
the result looks like
path: 103
where path is actual string like "game\\blablabla\\" - the name of directory with really 103 files in fact
and after slight modification I get correct results in line below too :
text "Files count: " + ( " %3d %3d " % ( len(f22f.copy() ) , len(f22f) ) )
as are result the line in RenPy looks like
Files count: 103 103
# in case directory contain really 103 files
If it wasnt my personal experience I wouldnt believe the text statement is fucked up this mystery way - but in fact it is.
But it is hard to detect cos we need to use literals not string names to see this one bug in action !!!
I hope this code with comments help you now
edit
It is not a critical bug hovewer - it doesnt matter for execution python code. Just sending misleading numbers on the screen - nothing more.
But it is really unpleasant if you dont expect it can really happend for you.
As I said I've found it today in RenPy 7.4.4.1489 - didnt tried found it in other versions yet
What tests have you done to ensure that it's Ren'Py that is "fucked up", and not your test code?
I'm asking this because when I try to replicate the bug on Ren'Py 7.4.4, well I don't get a bug... Therefore, I highly suspect that it's actually not a Ren'Py bug, but a bug in how you use Ren'Py.
Yeah, really hard to detect indeed. Especially knowing that near to no one will use the text statement the way you used it in your "correct" code, because it's not how you're supposed to integrate a variables into a text.
Instead they'll use text "[synaptic] %90s %3d " % ( ' ' , len(f22f) ). Therefore, accordingly to your own words, a syntax that should give them wrong results.
So, there's, perhaps, a bug in a 3 years old version of Ren'py, knowing that the 7.x branch have been updated 20 times since, and is now dead...
And what happen when you write it correctly, text "Files count: %3d %3d " % ( len(f22f) , len(f22f) ) ?
Or, better, when you don't use the outdated syntax but text "Files count: {} {}".format( len(f22f) , len(f22f) ) ?
What tests have you done to ensure that it's Ren'Py that is "fucked up", and not your test code?
I'm asking this because when I try to replicate the bug on Ren'Py 7.4.4, well I don't get a bug... Therefore, I highly suspect that it's actually not a Ren'Py bug, but a bug in how you use Ren'Py.
Yeah, really hard to detect indeed. Especially knowing that near to no one will use the text statement the way you used it in your "correct" code, because it's not how you're supposed to integrate a variables into a text.
Instead they'll use text "[synaptic] %90s %3d " % ( ' ' , len(f22f) ). Therefore, accordingly to your own words, a syntax that should give them wrong results.
As you see i didn't tried any of these 3 syntaxes :
text "Files count: %3d %3d " % ( len(f22f) , len(f22f) )
text "Files count: {} {}".format( len(f22f) , len(f22f) )
text "[synaptic] %90s %3d " % ( ' ' , len(f22f) )
I must check them yet.
All I said is
text synaptic + ( " %90s %3d " % ( ' ' , len(f22f) ) )
syntax is working well for me
but not syntax below:
text "Files count: " + (" %3d %3d " % ( len(f22f) , len(f22f) )
I also have to add - despite it have no effect on the bug - I'm sending synaptic variable type of string as a argument to screen call. Let me give you example:
action Show ( 'testMe2', synaptic="game\\extra\\"+name+"\\" ) , With( Dissolve(0.2))
where name is the name of subdirectory in extra directory.
I also have to explain it wasnt my intention displaying anything else by text statement in line when I wanted display synaptic path.
I just used modified syntax below when i've tried to catch this bug text synaptic + ( " %90s %3d " % ( ' ' , len(f22f) ) )
the original syntax when is first discovered this bug was like below:
text str(len(f22f)) or
text ("%s" % str(len(f22f)) )
it is really simple syntax and I was sure it should give me correct output.
But instead i was forced to use something like that:
text str(len(f22f.copy()))
For me it is very strange and unpleasant behaviour.
If text syntax is limited in some way - so it should be checked by parser and not valid syntax should forcing syntax error report.
But in case of syntax text "Files count: " + (" %3d %3d " % ( len(f22f) , len(f22f) )
nothing wrong is reported despite output is definitely corrupted
the same way like in the syntax below:
text ("%s" % str(len(f22f)) )
So please dont put in my mouth anything else what I said in fact.
edit
BTW I'm trying to write not a big mod for University of Problems and v.15.0 extended is distributed with 7.4.4 RenPy - so it doesnt matter for me how old is this RenPy version until new updates od such fine game as UoP are coming out recently.
It's not me who started a thread to talk about a "rare bug", nor is it me who claim that "the text statement is fucked up".
The only thing I said is that, when trying to replicate the bug by using the exact same syntax than you for the text statement, as well as the same version of Ren'Py, I get the correct values. Something that shouldn't happen if there where actually a "rare bug" in a "fucked up" statement.
I even gave the code I used for the test, so you can try it yourself. Something you apparently haven't done.
I also asked you what tests you used to ensure that it's effectively a bug in Ren'Py's core, and not on your side. Whatever if it's a complex test protocol, or a basic $ print( str( len( f22f ) ) + "\n" + str( f22f ) ) right before the, assumed bugged, text statement. Something to what you decided to not answer.
And I asked this because my decades of experiences proved, more than once, that bugs are insidious and can be triggered by particular values; in your case "103" as integer parameter for the Python old string format syntax.
Now, what I'm saying... It's not me who try to solve an issue I have, nor is it me who loose time trying to fix a bug that perhaps don't exist, and probably don't come from where you are searching it.
Instead they'll use text "[synaptic] %90s %3d " % ( ' ' , len(f22f) ). Therefore, accordingly to your own words, a syntax that should give them wrong results.
I tried similiar but different one : text "synaptic %90s %3d " % ( ' ' , len(f22f) )
and it didnt worked as was designed - and didnt reported any errors - so it is definitely fucked up - no doubt
but now i've checked two more syntaxes and they are bugged as well without any errors reported text "[synaptic] %90s %3d " % ( ' ' , len(f22f) ) text "[synaptic] " + (" %90s %3d " % ( ' ' , len(f22f) ) )
at least in
RenPy 7.4.4.1439
I'm not interested in other versions for now -cos I'm going to finish my mod for thhe game distributed in this one version.
I guess versions 7.x.x will be present with fancy games for many more years still.
I dont see devs hurry up to switch for 8.x.x RenPy
So this discovery of this weird bug is quite actual despite you think otherways.
edit
The only thing I said is that, when trying to replicate the bug by using the exact same syntax than you for the text statement, as well as the same version of Ren'Py, I get the correct values.
these two are similiar but quite different syntaxes - first one is similiar to print syntax cos synaptic is out of quotes and out of square brackets as well
the second one syntax is concatenation of two strings - first one is displayed coreectly but other part is not - this one part is bugged without warnings or errors
to fix this bug we need to change f22f to f22f.copy() - after such formal modification - cos in Python both expressions have exactly the same value RenPy text statement displaying in correct way.
It is hard to detect the bug cos wrong fixed number let say 94 decimal can be exactly the same as correct number if len(f22f) ==94 in some cases
We can notice this bug if txet statemet display 94 but len(f22f) <> 94 - so it is weird bug hard to detect at first glance
edit 2 !!!!
Keep in mind your code dont replicate envinroment of this bug cos you are extending f22f list by list of fixed length.
My code calculating list of files in screen function - the same function in which this value is displayed on the screen
So you have to run with synaptic variable as argument
screen testMe2(synaptic)
synaptic contain actual path to directory with files i have to count.
If you do that and you will check it with many different subdirectories which containg different number of files you will see when this bug is present and when is not present.
Maybe you have decades of experince - i"m not discussing that - but i see you dont have the balls for catching hard bugs - no offence.
As I said, I tested your code, including the two syntax you added in the post I'm answering too and that you present as bugged, with the same version of Ren'Py, and with the same list length than the one you talk about. And the fact is that there's no issue. All the supposed bugged syntax are returning the right value, proof that the text statement is not "fucked up".
The only difference is that my test do not include the tons of code you don't talk about; code that is more than surely the reason of the bug you encounter.
Now, I'm curious to know what is the result of the test I implicitly gave you; do the list really correspond to what you assume? But something tell me that you didn't cared to use it...
In my case it displays "synaptic 94" despite actual length of f22f list can be quite different - let say 75 , 49 or 103 if 103 is your favourite one.
edit !!!
Keep in mind you are not testing my code - you are just testing your code.
Try to add to your last screen this code:
Code:
python:
from os import walk
f22f=[]
for ( dirpath, dirnames,filenames ) in walk (synaptic) :
f22f.extend(filenames)
break
and than try to display all syntaxes of text statement in the same screen function
you should also have function which allow you substitute many different actual paths to synapthic variable - you can change its name to path if you like but in my code its name is synaptic - my code, my choice.
And you overlooked this piece of code below definitely - as you see synaptic is not just blablabla string but actual path to directory with files we need to count.
these filenames filing actual f22f list
Code:
action Show ( 'testMe2', synaptic="game\\extra\\"+name+"\\" ) , With( Dissolve(0.2))
So more files - the longer is f22f list but corrupted and fucked text statment displaying in my case always numeber 94 despite actual length maybe quite different in given case.
In my case it displays "synaptic 94" despite actual length of f22f list can be quite different - let say 75 , 49 or 103 if 103 is your favourite one.
edit !!!
Keep in mind you are not testing my code - you are just testing your code.
Try to add to your last screen this code:
Code:
python:
from os import walk
f22f=[]
for ( dirpath, dirnames,filenames ) in walk (synaptic) :
f22f.extend(filenames)
break
and than try to display all syntaxes of text statement in the same screen function
you should also have function which allow you substitute many different actual paths to synapthic variable - you can change its name to path if you like but in my code its name is synaptic - my code, my choice.
And you overlooked this piece of code below definitely - as you see synaptic is not just blablabla string but actual path to directory with files we need to count.
these filenames filing actual f22f list
Code:
action Show ( 'testMe2', synaptic="game\\extra\\"+name+"\\" ) , With( Dissolve(0.2))
So more files - the longer is f22f list but corrupted and fucked text statment displaying in my case always numeber 94 despite actual length maybe quite different in given case.
did you try the code examples you were given? did they work?
this is why i didnt bother to investigate on my side after your first reply to me because it seems you are more interested in explaining what your code does than show the actual code you're using that is bugging. bugs are not unheard of, obviously, but the most probably cause of the problem is you, not renpy.
if there is too much code to show, then either give the entire file and see if someone wants to look into it, or put together a small code example, WITH THE BUG, and paste it here. you may find you can't replicate the bug with a small code example, and then as you add more to make it more like your original code, you discover what you are doing wrong.
So more files - the longer is f22f list but corrupted and fucked text statment displaying in my case always numeber 94 despite actual length maybe quite different in given case.
You pretend that the text statement is "fucked up", because it don't give the correct value when using this or that syntax. I tested the said statement with the said syntax, period.
Like my tests proved that the said statement is not "fucked up", I stated the obvious: the issue is on the rest of the code...
What you systematically denied, and continue to deny despite all sanity...
If I try by adding "this", then the issue is obviously not the text statement, but the said additional code... But I'll humour you:
Oh, surprise... All the values are the same and, incidentally, correct. The text statement is not "fucked up" due to a "rare bug"...
Tell me, at what moment have you questioned that part of the code, and considered that the values weren't necessarily the ones you expected? No need to answer, I know that it's "never".
And you overlooked this piece of code below definitely - as you see synaptic is not just blablabla string but actual path to directory with files we need to count.
I overlooked nothing. I know how strings works in Python, how strings works in Ren'Py, and how Ren'Py's text interpolation works. Therefore, I know that "blablabla" and a path are exactly the same in the present case.
What change absolutely nothing. If the text statement is "fucked up" when using this or that syntax, it will be "fucked up" whatever the length of the list...
At what time have you considered that if the value is always 94, it's because the content of "f22f" never change?
And don't answer "because my code make it change", because you've no fucking clue about this. Not only you assume it when writing the code but, when facing a result that do not correspond to your expectation, you immediately decided that it's Ren'Py that is bugged, not questioning your code.
All this being said, it was an interesting exercise, but now I'll let you deal with your certitudes...
It's not "my favourite", it's the one you said as being the correct value...
Are you fucking serious?
You pretend that the text statement is "fucked up", because it don't give the correct value when using this or that syntax. I tested the said statement with the said syntax, period.
Like my tests proved that the said statement is not "fucked up", I stated the obvious: the issue is on the rest of the code...
What you systematically denied, and continue to deny despite all sanity...
Yes I'm deadly fucking seriuos since begining of this topic.
I'm not pretending that text alone is fucked up
I just get evidence that text statement with some forms of syntax is fucked up cos giving us wrong output without any warning that this syntax is incorrect .
Your logic is really poor - cos i dont need to change anything else in my code except f22f to f22f.copy() in text statements arguments body expression to see the radical DIFFERENCE - and I'm saying it to you by capitals cos i see you still cant see obvious evidence.
f22f is by DEFINITION the same as a result of method f22f.copy() but for text statement is for some mysterious reason difference.
when I'm using in some cases of syntax f22f expression I get wrong result = 94 but if i change it to f22f.copy() i will get correct 103 or correct 75 or correct anything else in enyone else directory which contain such numer of files inside.
So your logic is really badly twisted by these decades of your experience - sorry , but I'm not going to continue this topic with you at the level illogicality you are trying to forcing here.
If the bug was exclusively in other part of the my code - so as a result i would get wrong output in both cases -
if i use f22f or f22f.copy() cos output of both should be and really is excatly the same in Python never mind the version 2.xx or 3.xx
But in text statement in RenPy 7.4.4.1439 the difference is obvious and radical - under some circumstances at least.
So even if such circumstances triggering this bug in text statement and forcing me to using f22f.copy() instead just f22f object to get right output - so they are just a trigger not a bug itself - bug is in text statement cos RenPy parser dont sending any warning - the syntax is incorrect or different a tiny bit than 100% purely correct syntax.
maybe i missed you saying it, but how do you know this problem is related to text and not the value of f22f itself? did you ever try to check the value of f22f and f2ff.copy() in some other way than using text?
maybe i missed you saying it, but how do you know this problem is related to text and not the value of f22f itself? did you ever try to check the value of f22f and f2ff.copy() in some other way than using text?
For sure you missed - so let me explain this part of code again.
I duplicated len(f22f) expression inside for some reason you will see obvious in next example of this part of code.
The code belowe displaying fixed string and two wrong numbers not related to real length of f22f list.
Output of this code after such tiny modification is radically different - as are result we get two right numbers.
So if anything with object f22f was wrong at Python level so after such cosmetics it would stay wrong still cos using method copy() in one expression has no influence or shouldnt have in not fucked code interpreter for the second one expression which is still unchanged.
So going to conclussions - in first case we get twice 94 94 wrong numbers , but in 2nd case we get both 75 75 correct numbers. Isnt it a mystery itself ??? ( How much text statement is fucked up in this one version of RenPy at least )
Despite second term/expression is still exactly the same ???
Logically thinking human being dont need even a week of experience with Python to see blatant evidence of some fucking bug here , dont even mention decades of experience in IT business or programming in Python and RenPy.
I dont deny - maybe some hidden trigger are here outside of this kind of code - but RIGHT parser of RenPy should detect such danger and should issue warrnings that using len(f22f) is risky but len(f22f.copy() ) would be safe in such case.
But even in such case it would be RenPy fault not Python fault cos Python see always right values of len(f22f).
So issuing the warning would be an evident weakness such version of RenPy but still much safer than undetected and unreported bug here in this one case.
If you have reasonable arguments why RenPy Parser is totally silent in the case when RenPy text statement acting such polarly different on f22f and f22f.copy() I'm really curious to learn.
But dont tell me again the reason of bug is in quite different place cos everything is OK and method copy() can return quite different object than real copy of his own parent object.
If it is not blatant sign of fucked weird bug , so I'm totally brainless idiot here.
Best Regards
I just get evidence that text statement with some forms of syntax is fucked up cos giving us wrong output without any warning that this syntax is incorrect .
With some syntax, it give you and so far only you, a result that do not correspond to what you expected. That's all you have, and in no way can be called "evidence", because at no time you have the guaranty that your expectation correspond to what your code is actually doing.
At least it's what I get from the constancy with which you systematically refuse to address the most important point in all this: What fucking test procedure have you followed to ensure that your code is correct ?
And it's not like it's something difficult to do. I, nicely, gave you a one line debug code to check that the content of "f22f" is what you expect, then, in the next post, pointed to it, before I finally, in my last post, included it in all my test code. So, even if, at first, you didn't known how to do that test, you now have no excuse to not do it.
All this while, on my side, I provided in all my posts a test code corresponding to the issue you point, adjusted every time you add more information. Test codes that serve as evidence that that the text statement, with the syntax that you present as bugged, give the expected result.
Your logic is really poor - cos i dont need to change anything else in my code except f22f to f22f.copy() in text statements arguments body expression to see the radical DIFFERENCE - and I'm saying it to you by capitals cos i see you still cant see obvious evidence.
f22f == f22f.copy() is the only case where what you say is necessarily true.
Scopes can make your assertion wrong.
The fact that Python arguments are passed by value can make your assertion wrong.
The use of an AST structure can make your assertion wrong.
The use of a pseudo-cache through object attributes can make your assertion wrong.
And of course, as said by the doc, Ren'Py's screen optimization regarding variables can make your assertion wrong.
Those are, among many others, the rules of Python, as well as the rules of Ren'Py, and I surely forgot some that could also make your assertion wrong.
The fact is that when you write something like str( f22f ) can perfectly address what "f22f" was when the AST entry was created. This while str( f22f.copy() ) can perfectly address the content of "f22f" when the copy will be created, therefore later. What, by definition, imply that "f22f" is not necessarily the same than "f22f.copy()".
It's part of the bases for most scripting languages. And it don't point to a bug in the language, but a misunderstanding of its rules.
Circumstances that only you encounter. But it's obviously Ren'Py's fault, not yours...
It can't be due to the fact that you fill "f22f" directly into the screen, that is refreshed around every 0.2 seconds.
It can't be due to the fact that screens have their own local scope.
It can't be due to the fact that Ren'Py create an object for every single statement, and store its parameter values at creation time.
No, it's necessarily text that is bugged, and bugged only for you...
[...] bug is in text statement cos RenPy parser dont sending any warning - the syntax is incorrect or different a tiny bit than 100% purely correct syntax.
I now have a strong guess (90%) regarding your issue.
You declare "f22f" into a python block, therefore it will never be included in the "not_constant" list.
Not being seen as a none constant value, according to its optimization rules regarding screens, and as said in the doc, Ren'Py will only evaluate it once.
Therefore "f22f" will systematically correspond to the very first value assigned to the list. This will "f22f.copy()" will force a real time copy of the list, and therefore correspond to its actual value.
[/spoiler]
You dont have to guess Mrs/Mr Experienced by decades - I send this piece of code more than 4 hours ago.
Since start I was telling you you just running your own code not mine.
working well without needs to use method copy() of f22f object declared in Python block.
so if cache of f22f object contain wrong old value it should use it in this kind of syntax as well.
But this syntax forcing in mystery way cache to use actual present value
So i dont care what you call optimization rule or other way . Cos for me it acting like blatant bug.
Ideas behind of Python were to free us of memory management like we had to bother in C or C++.
And now you blatanly call such evident bug and weakness as an result of optimisation rule .
Great very funny indeed.
You just should start with that your Majesty Experienced.
Right written text statement in RenPy should force to use actual value or issue visible warning the incorrect value could be displayed cos of "optimization" rules. It is really shitty excuse imho. Like "halucinations" of LLMs.
For sure you missed - so let me explain this part of code again.
I duplicated len(f22f) expression inside for some reason you will see obvious in next example of this part of code.
The code belowe displaying fixed string and two wrong numbers not related to real length of f22f list.
Output of this code after such tiny modification is radically different - as are result we get two right numbers.
So if anything with object f22f was wrong at Python level so after such cosmetics it would stay wrong still cos using method copy() in one expression has no influence or shouldnt have in not fucked code interpreter for the second one expression which is still unchanged.
So going to conclussions - in first case we get twice 94 94 wrong numbers , but in 2nd case we get both 75 75 correct numbers. Isnt it a mystery itself ??? ( How much text statement is fucked up in this one version of RenPy at least )
Despite second term/expression is still exactly the same ???
Logically thinking human being dont need even a week of experience with Python to see blatant evidence of some fucking bug here , dont even mention decades of experience in IT business or programming in Python and RenPy.
I dont deny - maybe some hidden trigger are here outside of this kind of code - but RIGHT parser of RenPy should detect such danger and should issue warrnings that using len(f22f) is risky but len(f22f.copy() ) would be safe in such case.
But even in such case it would be RenPy fault not Python fault cos Python see always right values of len(f22f).
So issuing the warning would be an evident weakness such version of RenPy but still much safer than undetected and unreported bug here in this one case.
If you have reasonable arguments why RenPy Parser is totally silent in the case when RenPy text statement acting such polarly different on f22f and f22f.copy() I'm really curious to learn.
But dont tell me again the reason of bug is in quite different place cos everything is OK and method copy() can return quite different object than real copy of his own parent object.
If it is not blatant sign of fucked weird bug , so I'm totally brainless idiot here.
Best Regards
all that text and you didnt bother to take a few seconds to actually answer me. so no, you havent checked the values of f22f and f22f.copy() any other way apparently. not even a simple if f22f == f2ff.copy(). you didnt for a second care to investigate that the copy could change something, as AON already explained - which was one possible explanation from the start instead of blaming text. is it the answer? i dont know since you wont test it, but my guess is yes
all that text and you didnt bother to take a few seconds to actually answer me. so no, you havent checked the values of f22f and f22f.copy() any other way apparently. not even a simple if f22f == f2ff.copy(). you didnt for a second care to investigate that the copy could change something, as AON already explained - which was one possible explanation from the start instead of blaming text. is it the answer? i dont know since you wont test it, but my guess is yes
I see you dont understand my objections at all.
And you dont understand AON's explanations as well.
Cos i dont have any problems with f22f object in my code .
When I'm in for loop like this one
Code:
for yy, name in enumerate(f22f):
I dont have any issues despite f22f was declared in python: block.
It is mutable variable type of list. The issue is with calculating actual length of this object. Not for me - but for RenPy - or I should said BugPy in this blatant case.
so checking if f22f == f22f.copy() have no sense at all in this case - cos in every different instance of text statement of BugPy expression like len(f22f) can be interpreted in different way - accordingly to bugged rules of "optimizations" of BugPy.
So to forcing BugPy to keep its bug for itself we need to use method copy() of the object to calculate its actual length for example . Some kind od syntax like
still working well without using copy () metod but if we dont want bother which syntax is interpreted this way and which one in radically different one we have to use copy() method to avoid such surprizes of BugPy.
Blatant incoherence in the treatment of the same expression in different instances of text statement telling me everything.
The same expression should give the same output by DEFINITION - but not in BugPy. Here you can see 94 in one instance and correct 75 in the next one text instance and again wrong number 94 in another following text instance.
It is not a problem of Python itself - it is colour and smell of BugPy .
edit
Keep in mind Python didnt lose it ability to return actual lenth of given object - it is just BugPy which dont care to call right request to Python in every case.
In some cases as you were given above BugPy indeed calling Python for actual length but in other instances with sligtly different syntax it dont bother and as are result displaying bugged 94 - which still takes place in memory. Keeping such bugs in memory in BugPy it is called optimization. )
So her Majesty AON's explanations are the same way incoherent as BugPy treatment of its variables.
I see you dont understand my objections at all.
And you dont understand AON's explanations as well.
Cos i dont have any problems with f22f object in my code .
When I'm in for loop like this one
Code:
for yy, name in enumerate(f22f):
I dont have any issues despite f22f was declared in python: block.
It is mutable variable type of list. The issue is with calculating actual length of this object. Not for me - but for RenPy - or I should said BugPy in this blatant case.
so checking if f22f == f22f.copy() have no sense at all in this case - cos in every different instance of text statement of BugPy expression like len(f22f) can be interpreted in different way - accordingly to bugged rules of "optimizations" of BugPy.
So to forcing BugPy to keep its bug for itself we need to use method copy() of the object to calculate its actual length for example . Some kind od syntax like
still working well without using copy () metod but if we dont want bother which syntax is interpreted this way and which one in radically different one we have to use copy() method to avoid such surprizes of BugPy.
Blatant incoherence in the treatment of the same expression in different instances of text statement telling me everything.
The same expression should give the same output by DEFINITION - but not in BugPy. Here you can see 94 in one instance and correct 75 in the next one text instance and again wrong number 94 in another following text instance.
It is not a problem of Python itself - it is colour and smell of BugPy .
edit
Keep in mind Python didnt lose it ability to return actual lenth of given object - it is just BugPy which dont care to call right request to Python in every case.
In some cases as you were given above BugPy indeed calling Python for actual length but in other instances with sligtly different syntax it dont bother and as are result displaying bugged 94 - which still takes place in memory. Keeping such bugs in memory in BugPy it is called optimization. )
So her Majesty AON's explanations are the same way incoherent as BugPy treatment of its variables.
ffs just check if f22f == f22f.copy() before the line that bugs. if you see they arent the same, you know that copy changes the value. so nothing to do with text.
this is something simple that you should have been able to bug test and figure out yourself but you're stuck in this one explanation that text bugs and wont even test anything else.
stop writing essays and test the fucking code as suggested. this is so stupid
ffs just check if f22f == f22f.copy() before the line that bugs. if you see they arent the same, you know that copy changes the value. so nothing to do with text.
this is something simple that you should have been able to bug test and figure out yourself but you're stuck in this one explanation that text bugs and wont even test anything else.
stop writing essays and test the fucking code as suggested. this is so stupid
Sorry my friend - I see you are trying to help but you dont understand the issue at all.
copy() method dont have any influence on f22f content.
It is interacting with BugPy in quite diffrent way - now even obvious for decades experienced AONs.
By invoking copy() method of f22f object BugPy is forced to check actual state of this variable which is in Python's domain.
BugPy dont using old content (not actual ) of f22f object in its code - it is using actual content without beeing forced by invoking copy() method. So there is no reason to check state of the content of f22f object.
What going wrong is the way BugPy wasteing its memory for keeping old atribute of old state of f22f variable. This atribute is just length - so BugPy is blatantly incoherent in treatment of len(f22f) expression.
In one instance syntax of text statement forcing BuPy to call Python to return of actual length of this object but in another instance it is using its bugged value from its own wasted this way memory location.
This mechanism has nothing common with content of f22f object. This content is always located in memory where BugPy have access by right interaction with Python at python's level of execution.
At this level Python is responsible of memory management so in every case it returning right actual values of all actual elements in f22f list object.
You dont understand - cos you are assuming I dont see what is the content of f22f object. But it is blatantly wrong assumption cos other part of my code just printing on the screen right values of content - all file names are displayed right without invoking copy() method at all , so i dont have any logical reason to check this condition once again !!!
I will tell you once again despite you are closed for logical thinking - enumeration working very well with pure f22f object old or actual.
But you are stubborn i need to check it again
You should ask not me but BugPy core progrmmers to check this condition if it is any logical reason to waste this way precious resorces . But even blatantly bugged BugPy dont have such kind of issues what is proved by code and displayed very correct.
edit
In fact I even dont care if BugPy wasteing its own emory for keeping whole content of old state of f22f list. It is not my problem snuffing on BugPy wich way its wasteing its own memory cache - until it is doing what i'm asking for in my code.
Cos enueration working very well - since first to last element od the list f22f so i dont have any reason to check this again by other way you asking for.
For me what i see in every 75 cases of each elements of the list is 75 times more trustable than checking it once again by the way you are asking for.
Even if the result would be not true but false - it wouldnt be any better for BugPy or any worse for me , As long as BugPy doing enumeration in loop right way.
