Why does an empty string in Python sometimes take up 49 bytes and sometimes 51?












9














I tested sys.getsize('') and sys.getsize(' ') in three environments, and in two of them sys.getsize('') gives me 51 bytes (one byte more than the second) instead of 49 bytes:



Screenshots:



Win8 + Spyder + CPython 3.6:



sys.getsizeof('') == 49 and sys.getsizeof(' ') == 50



Win8 + Spyder + IPython 3.6:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



Win10 (VPN remote) + PyCharm + CPython 3.7:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



First edit



I did a second test in Python.exe instead of Spyder and PyCharm (These two are still showing 51), and everything seems to be good. Apparently I don't have the expertise to solve this problem so I'll leave it to you guys :)



Win10 + Python 3.7 console versus PyCharm using same interpreter:



enter image description here



Win8 + IPython 3.6 + Spyder using same interpreter:



enter image description here










share|improve this question




















  • 6




    My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
    – roganjosh
    5 hours ago






  • 2




    @roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
    – Nicholas Humphrey
    5 hours ago






  • 1




    My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
    – roganjosh
    5 hours ago






  • 3




    @AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
    – Nicholas Humphrey
    5 hours ago






  • 2




    The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
    – Davis Herring
    4 hours ago
















9














I tested sys.getsize('') and sys.getsize(' ') in three environments, and in two of them sys.getsize('') gives me 51 bytes (one byte more than the second) instead of 49 bytes:



Screenshots:



Win8 + Spyder + CPython 3.6:



sys.getsizeof('') == 49 and sys.getsizeof(' ') == 50



Win8 + Spyder + IPython 3.6:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



Win10 (VPN remote) + PyCharm + CPython 3.7:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



First edit



I did a second test in Python.exe instead of Spyder and PyCharm (These two are still showing 51), and everything seems to be good. Apparently I don't have the expertise to solve this problem so I'll leave it to you guys :)



Win10 + Python 3.7 console versus PyCharm using same interpreter:



enter image description here



Win8 + IPython 3.6 + Spyder using same interpreter:



enter image description here










share|improve this question




















  • 6




    My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
    – roganjosh
    5 hours ago






  • 2




    @roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
    – Nicholas Humphrey
    5 hours ago






  • 1




    My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
    – roganjosh
    5 hours ago






  • 3




    @AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
    – Nicholas Humphrey
    5 hours ago






  • 2




    The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
    – Davis Herring
    4 hours ago














9












9








9


5





I tested sys.getsize('') and sys.getsize(' ') in three environments, and in two of them sys.getsize('') gives me 51 bytes (one byte more than the second) instead of 49 bytes:



Screenshots:



Win8 + Spyder + CPython 3.6:



sys.getsizeof('') == 49 and sys.getsizeof(' ') == 50



Win8 + Spyder + IPython 3.6:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



Win10 (VPN remote) + PyCharm + CPython 3.7:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



First edit



I did a second test in Python.exe instead of Spyder and PyCharm (These two are still showing 51), and everything seems to be good. Apparently I don't have the expertise to solve this problem so I'll leave it to you guys :)



Win10 + Python 3.7 console versus PyCharm using same interpreter:



enter image description here



Win8 + IPython 3.6 + Spyder using same interpreter:



enter image description here










share|improve this question















I tested sys.getsize('') and sys.getsize(' ') in three environments, and in two of them sys.getsize('') gives me 51 bytes (one byte more than the second) instead of 49 bytes:



Screenshots:



Win8 + Spyder + CPython 3.6:



sys.getsizeof('') == 49 and sys.getsizeof(' ') == 50



Win8 + Spyder + IPython 3.6:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



Win10 (VPN remote) + PyCharm + CPython 3.7:



sys.getsizeof('') == 51 and sys.getsizeof(' ') == 50



First edit



I did a second test in Python.exe instead of Spyder and PyCharm (These two are still showing 51), and everything seems to be good. Apparently I don't have the expertise to solve this problem so I'll leave it to you guys :)



Win10 + Python 3.7 console versus PyCharm using same interpreter:



enter image description here



Win8 + IPython 3.6 + Spyder using same interpreter:



enter image description here







python






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 5 hours ago

























asked 6 hours ago









Nicholas Humphrey

337418




337418








  • 6




    My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
    – roganjosh
    5 hours ago






  • 2




    @roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
    – Nicholas Humphrey
    5 hours ago






  • 1




    My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
    – roganjosh
    5 hours ago






  • 3




    @AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
    – Nicholas Humphrey
    5 hours ago






  • 2




    The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
    – Davis Herring
    4 hours ago














  • 6




    My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
    – roganjosh
    5 hours ago






  • 2




    @roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
    – Nicholas Humphrey
    5 hours ago






  • 1




    My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
    – roganjosh
    5 hours ago






  • 3




    @AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
    – Nicholas Humphrey
    5 hours ago






  • 2




    The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
    – Davis Herring
    4 hours ago








6




6




My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
– roganjosh
5 hours ago




My burning question is "why does it matter?". But anyway, Spyder will also be throwing that into a shared namespace
– roganjosh
5 hours ago




2




2




@roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
– Nicholas Humphrey
5 hours ago




@roganjosh Actually I think it doesn't matter because my job as a data analyst doesn't ask me to dig deep into the object model, but I'm scratching my head to understand the why behind this. I wish I have other OS e.g. Linux to test this. BTW does this have something to do with the "shared namespace" you said?
– Nicholas Humphrey
5 hours ago




1




1




My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
– roganjosh
5 hours ago




My job is also data scientist/data analyst. This behaviour is inconsequential, but I don't want to invalidate your question (curiosity is fine). Spyder has a complex namespace, you must have observed how things are available in the console from your main scripts...
– roganjosh
5 hours ago




3




3




@AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
– Nicholas Humphrey
5 hours ago




@AndreyTyukin No I just want to see if someone else has encountered this weird thing before, and more importantly, if an empty string does have 1 more byte than a string with one char, it means that my understanding of the string object could be totally wrong. If you think this is normal, then sorry, because I'm not professional software developer and this is indeed weird to me. For now I'm settled with this issue as a second test with Python.exe console shows 49.
– Nicholas Humphrey
5 hours ago




2




2




The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
– Davis Herring
4 hours ago




The most likely candidate seems to be that strings cache a version encoded with UTF-8 when first required.
– Davis Herring
4 hours ago












2 Answers
2






active

oldest

votes


















3














This sounds like something is retrieving the wchar representation of the string object. As of CPython 3.7, the way the CPython Unicode representation works out, an empty string is normally stored in "compact ASCII" representation, and the base data and padding for a compact ASCII string on a 64-bit build works out to 48 bytes, plus one byte of string data (just the null terminator). You can see the relevant header file here.



For now (this is scheduled for removal in 4.0), there is also an option to retrieve a wchar_t representation of a string. On a platform with 2-byte wchar_t, the wchar representation of an empty string is 2 bytes (just the null terminator again). The wchar representation is cached on the string on first access, and str.__sizeof__ accounts for this extra data when it exists, resulting in a 51-byte total.






share|improve this answer

















  • 1




    the getsizeof() does refer to sizeof internally. This is the correct answer
    – Abhishek Dujari
    38 mins ago












  • Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
    – Nicholas Humphrey
    8 mins ago










  • @NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
    – user2357112
    5 mins ago



















1














https://docs.python.org/3.5/library/sys.html#sys.getsizeof



sys is system specific so it can easily differ. This is often overlooked by everyone. All system specific stuff in python has been dumped in the sys package for years. For e.g sys.getwindowsversion() is not portable by definition but its there. It like the bottomless pit of rejects in the perfect world of cross platform coding. What you see is one of the interesting nuggets of Python.



from getsizeof docs:



Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.
getsizeof() calls the object’s sizeof method and adds an additional garbage collector overhead if the object is managed by the garbage collector.



When Garbage collection is in use the OS will add those extra bits. If you read Python and GC Q & A When are objects garbage collected in python? the folks have gone into excruciating detail expoundign the GC and how it will affect the memory/refcount and bits blah blah.



I hope that explains where this coming from. If you don't use system level attributes but more pythonic attributes then you will get consistent sizes.






share|improve this answer

















  • 1




    It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
    – user2357112
    44 mins ago






  • 1




    Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
    – Abhishek Dujari
    41 mins ago











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53899931%2fwhy-does-an-empty-string-in-python-sometimes-take-up-49-bytes-and-sometimes-51%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














This sounds like something is retrieving the wchar representation of the string object. As of CPython 3.7, the way the CPython Unicode representation works out, an empty string is normally stored in "compact ASCII" representation, and the base data and padding for a compact ASCII string on a 64-bit build works out to 48 bytes, plus one byte of string data (just the null terminator). You can see the relevant header file here.



For now (this is scheduled for removal in 4.0), there is also an option to retrieve a wchar_t representation of a string. On a platform with 2-byte wchar_t, the wchar representation of an empty string is 2 bytes (just the null terminator again). The wchar representation is cached on the string on first access, and str.__sizeof__ accounts for this extra data when it exists, resulting in a 51-byte total.






share|improve this answer

















  • 1




    the getsizeof() does refer to sizeof internally. This is the correct answer
    – Abhishek Dujari
    38 mins ago












  • Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
    – Nicholas Humphrey
    8 mins ago










  • @NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
    – user2357112
    5 mins ago
















3














This sounds like something is retrieving the wchar representation of the string object. As of CPython 3.7, the way the CPython Unicode representation works out, an empty string is normally stored in "compact ASCII" representation, and the base data and padding for a compact ASCII string on a 64-bit build works out to 48 bytes, plus one byte of string data (just the null terminator). You can see the relevant header file here.



For now (this is scheduled for removal in 4.0), there is also an option to retrieve a wchar_t representation of a string. On a platform with 2-byte wchar_t, the wchar representation of an empty string is 2 bytes (just the null terminator again). The wchar representation is cached on the string on first access, and str.__sizeof__ accounts for this extra data when it exists, resulting in a 51-byte total.






share|improve this answer

















  • 1




    the getsizeof() does refer to sizeof internally. This is the correct answer
    – Abhishek Dujari
    38 mins ago












  • Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
    – Nicholas Humphrey
    8 mins ago










  • @NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
    – user2357112
    5 mins ago














3












3








3






This sounds like something is retrieving the wchar representation of the string object. As of CPython 3.7, the way the CPython Unicode representation works out, an empty string is normally stored in "compact ASCII" representation, and the base data and padding for a compact ASCII string on a 64-bit build works out to 48 bytes, plus one byte of string data (just the null terminator). You can see the relevant header file here.



For now (this is scheduled for removal in 4.0), there is also an option to retrieve a wchar_t representation of a string. On a platform with 2-byte wchar_t, the wchar representation of an empty string is 2 bytes (just the null terminator again). The wchar representation is cached on the string on first access, and str.__sizeof__ accounts for this extra data when it exists, resulting in a 51-byte total.






share|improve this answer












This sounds like something is retrieving the wchar representation of the string object. As of CPython 3.7, the way the CPython Unicode representation works out, an empty string is normally stored in "compact ASCII" representation, and the base data and padding for a compact ASCII string on a 64-bit build works out to 48 bytes, plus one byte of string data (just the null terminator). You can see the relevant header file here.



For now (this is scheduled for removal in 4.0), there is also an option to retrieve a wchar_t representation of a string. On a platform with 2-byte wchar_t, the wchar representation of an empty string is 2 bytes (just the null terminator again). The wchar representation is cached on the string on first access, and str.__sizeof__ accounts for this extra data when it exists, resulting in a 51-byte total.







share|improve this answer












share|improve this answer



share|improve this answer










answered 46 mins ago









user2357112

150k12156246




150k12156246








  • 1




    the getsizeof() does refer to sizeof internally. This is the correct answer
    – Abhishek Dujari
    38 mins ago












  • Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
    – Nicholas Humphrey
    8 mins ago










  • @NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
    – user2357112
    5 mins ago














  • 1




    the getsizeof() does refer to sizeof internally. This is the correct answer
    – Abhishek Dujari
    38 mins ago












  • Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
    – Nicholas Humphrey
    8 mins ago










  • @NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
    – user2357112
    5 mins ago








1




1




the getsizeof() does refer to sizeof internally. This is the correct answer
– Abhishek Dujari
38 mins ago






the getsizeof() does refer to sizeof internally. This is the correct answer
– Abhishek Dujari
38 mins ago














Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
– Nicholas Humphrey
8 mins ago




Thanks! Although I don't get the full pic this seems to explain the source of 51-byte. Just curious, why does Spyder with CPython give me 49-byte but shows 51-byte for IPython on the same PC? I figured from your answer that it has something to do with the size of wchar, and in turn the IDEs get 2 bytes because it's OS-specified, but I think it should be the same for all interpreters? Anyway I may misunderstand your answer...
– Nicholas Humphrey
8 mins ago












@NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
– user2357112
5 mins ago




@NicholasHumphrey: Something is retrieving the wchar representation in your IPython tests. (Also, your IPython tests are also using CPython; CPython is the interpreter implementation IPython runs on.)
– user2357112
5 mins ago













1














https://docs.python.org/3.5/library/sys.html#sys.getsizeof



sys is system specific so it can easily differ. This is often overlooked by everyone. All system specific stuff in python has been dumped in the sys package for years. For e.g sys.getwindowsversion() is not portable by definition but its there. It like the bottomless pit of rejects in the perfect world of cross platform coding. What you see is one of the interesting nuggets of Python.



from getsizeof docs:



Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.
getsizeof() calls the object’s sizeof method and adds an additional garbage collector overhead if the object is managed by the garbage collector.



When Garbage collection is in use the OS will add those extra bits. If you read Python and GC Q & A When are objects garbage collected in python? the folks have gone into excruciating detail expoundign the GC and how it will affect the memory/refcount and bits blah blah.



I hope that explains where this coming from. If you don't use system level attributes but more pythonic attributes then you will get consistent sizes.






share|improve this answer

















  • 1




    It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
    – user2357112
    44 mins ago






  • 1




    Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
    – Abhishek Dujari
    41 mins ago
















1














https://docs.python.org/3.5/library/sys.html#sys.getsizeof



sys is system specific so it can easily differ. This is often overlooked by everyone. All system specific stuff in python has been dumped in the sys package for years. For e.g sys.getwindowsversion() is not portable by definition but its there. It like the bottomless pit of rejects in the perfect world of cross platform coding. What you see is one of the interesting nuggets of Python.



from getsizeof docs:



Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.
getsizeof() calls the object’s sizeof method and adds an additional garbage collector overhead if the object is managed by the garbage collector.



When Garbage collection is in use the OS will add those extra bits. If you read Python and GC Q & A When are objects garbage collected in python? the folks have gone into excruciating detail expoundign the GC and how it will affect the memory/refcount and bits blah blah.



I hope that explains where this coming from. If you don't use system level attributes but more pythonic attributes then you will get consistent sizes.






share|improve this answer

















  • 1




    It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
    – user2357112
    44 mins ago






  • 1




    Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
    – Abhishek Dujari
    41 mins ago














1












1








1






https://docs.python.org/3.5/library/sys.html#sys.getsizeof



sys is system specific so it can easily differ. This is often overlooked by everyone. All system specific stuff in python has been dumped in the sys package for years. For e.g sys.getwindowsversion() is not portable by definition but its there. It like the bottomless pit of rejects in the perfect world of cross platform coding. What you see is one of the interesting nuggets of Python.



from getsizeof docs:



Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.
getsizeof() calls the object’s sizeof method and adds an additional garbage collector overhead if the object is managed by the garbage collector.



When Garbage collection is in use the OS will add those extra bits. If you read Python and GC Q & A When are objects garbage collected in python? the folks have gone into excruciating detail expoundign the GC and how it will affect the memory/refcount and bits blah blah.



I hope that explains where this coming from. If you don't use system level attributes but more pythonic attributes then you will get consistent sizes.






share|improve this answer












https://docs.python.org/3.5/library/sys.html#sys.getsizeof



sys is system specific so it can easily differ. This is often overlooked by everyone. All system specific stuff in python has been dumped in the sys package for years. For e.g sys.getwindowsversion() is not portable by definition but its there. It like the bottomless pit of rejects in the perfect world of cross platform coding. What you see is one of the interesting nuggets of Python.



from getsizeof docs:



Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.
getsizeof() calls the object’s sizeof method and adds an additional garbage collector overhead if the object is managed by the garbage collector.



When Garbage collection is in use the OS will add those extra bits. If you read Python and GC Q & A When are objects garbage collected in python? the folks have gone into excruciating detail expoundign the GC and how it will affect the memory/refcount and bits blah blah.



I hope that explains where this coming from. If you don't use system level attributes but more pythonic attributes then you will get consistent sizes.







share|improve this answer












share|improve this answer



share|improve this answer










answered 51 mins ago









Abhishek Dujari

1,2072440




1,2072440








  • 1




    It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
    – user2357112
    44 mins ago






  • 1




    Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
    – Abhishek Dujari
    41 mins ago














  • 1




    It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
    – user2357112
    44 mins ago






  • 1




    Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
    – Abhishek Dujari
    41 mins ago








1




1




It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
– user2357112
44 mins ago




It's not GC data. String objects are never tracked by the GC; they don't have that data. Also, the same objects would have GC data on all the configurations the questioner tested.
– user2357112
44 mins ago




1




1




Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
– Abhishek Dujari
41 mins ago




Then I stand to be corrected. it may not be GC. However the difference in representation still applies and is system specific. It could be OS+runtime
– Abhishek Dujari
41 mins ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53899931%2fwhy-does-an-empty-string-in-python-sometimes-take-up-49-bytes-and-sometimes-51%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Ellipse (mathématiques)

Quarter-circle Tiles

Mont Emei