bpy.context.scene.statistics no longer exists in the Python API #79816

New Issue

Ethan Simon · 2020-08-16T05:06:19+02:00

Ethan Simon commented

2020-08-16 05:06:19 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.77

Blender Version
Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-14 20:34, hash: c300fc56c3
Worked: (newest version of Blender that worked as expected)

Short description of error
So I actually read from the string that bpy.context.scene.statistics returns in one of my add-ons, but in 2.9 it seems that they are gone. This may not be a bug, but I feel like removing it entirely is just going to destroy parts of my script for seemingly no reason. If there is a better way to collect that information I would be appreciative, I know this isn't a place for add-on creation help but some of the code seems deprecated now.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.77 **Blender Version** Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-14 20:34, hash: `c300fc56c3` Worked: (newest version of Blender that worked as expected) **Short description of error** So I actually read from the string that bpy.context.scene.statistics returns in one of my add-ons, but in 2.9 it seems that they are gone. This may not be a bug, but I feel like removing it entirely is just going to destroy parts of my script for seemingly no reason. If there is a better way to collect that information I would be appreciative, I know this isn't a place for add-on creation help but some of the code seems deprecated now.

Ethan Simon commented

2020-08-16 05:06:19 +02:00

Added subscriber: @razed

Jesse Yurkovich commented

2020-08-16 07:52:05 +02:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2020-08-16 07:52:05 +02:00

I also feel like this was an unnecessary breaking change. It's not listed in the Release Notes either. I haven't got much traction in getting it put back in when I bring this up on occasion but maybe this bug will change some minds.

Ethan Simon commented

2020-08-16 16:26:45 +02:00

This roadmap also explicitly states zero breakage in the API, when it obviously isn't true.

This roadmap also explicitly states zero breakage in the API, when it obviously isn't true. ![image.png](https://archive.blender.org/developer/F8785946/image.png)

Hans Goudey commented

2020-08-16 17:25:38 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2020-08-16 17:25:38 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2020-08-16 17:25:38 +02:00

I think the reason it was removed is that you can now toggle which settings to display. Maybe these settings could be overriden though.

I asked the UI team about this, the result will be either of these options, not sure which right now:

Change is documented in the release notes and we have an asterisk on "No API breakage"
We find some way to restore the function

I think the reason it was removed is that you can now toggle which settings to display. Maybe these settings could be overriden though. I asked the UI team about this, the result will be either of these options, not sure which right now: 1. Change is documented in the release notes and we have an asterisk on "No API breakage" 2. We find some way to restore the function

Ethan Simon commented

2020-08-16 18:32:57 +02:00

If there isn't a way to restore the function is there any alternative route I can take? I ended up using this bit of the API because I was unable to find any other efficient way of getting total selected vertices. I would rather not loop through every vertex in a scene.

Jose commented

2020-08-16 23:59:20 +02:00

Added subscriber: @Dogway

Himanshi Kalra commented

2020-08-17 09:47:33 +02:00

Added subscriber: @Calra

Hans Goudey was assigned by Dalai Felinto

2020-08-17 09:53:47 +02:00

Dalai Felinto commented

2020-08-17 19:36:06 +02:00

Added subscribers: @JulianEisel, @dfelinto

Dalai Felinto commented

2020-08-17 19:36:06 +02:00

I think this API change should be reverted, there is little reason for this to break the API. @JulianEisel said he will look into its feasibility and see with @HooglyBoogly who can tackle this.

Julian Eisel commented

2020-08-17 19:48:38 +02:00

Added subscriber: @Harley

Julian Eisel commented

2020-08-17 19:48:38 +02:00

We can bring back the old API function. The only reason why this needs to be called via the screen currently, is that the screen holds the string buffer of the returned string. We can move that buffer back to the View Layer, where it was before.
@Harley are you available to work on this before bcon4 (Wednesday)? Otherwise I'll pass this on to @HooglyBoogly.

A note on the No API breakage thing:
For every release there are smaller changes done to the API - an argument renamed here, a value changed from a boolean to an enum there, etc. For the 2.90 release there are a few such changes too . These should be avoided if that can be done in a clean way, but they are usual.*No API breakage// was meant to say there are no changes planned, but I find that a bit of a misleading way to put that. Small changes may still happen.
They must be documented in the release notes in any case though.

We can bring back the old API function. The only reason why this needs to be called via the screen currently, is that the screen holds the string buffer of the returned string. We can move that buffer back to the View Layer, where it was before. @Harley are you available to work on this before bcon4 (Wednesday)? Otherwise I'll pass this on to @HooglyBoogly. --- A note on the *No API breakage* thing: For every release there are smaller changes done to the API - an argument renamed here, a value changed from a boolean to an enum there, etc. For the 2.90 release [there are a few such changes too ](https:*wiki.blender.org/wiki/Reference/Release_Notes/2.90/Python_API#Compatibility). These should be avoided if that can be done in a clean way, but they are usual.*No API breakage// was meant to say there are no changes **planned**, but I find that a bit of a misleading way to put that. Small changes may still happen. They **must** be documented in the release notes in any case though.

Harley Acheson commented

2020-08-17 20:32:59 +02:00

Trying to remember the history of this thing, which is complex only because it had a few detours along the way. LOL.

At the beginning my idea was to have the 3DView overlay stats be just a new option, without changing or removing the footer stats - which is how it ended up in the end. But...

When I first showed this off it was then Brecht's opinion that either the code duplication be fixed or the footer stats removed. William's preference was to remove the footer stats. The other (important) comment is that we would eventually want the overlay stats to show local stats, not just overall scene stats. This is why the stats were removed from scene. There was only the one set of stats (as a 3DView overlay) and those would (eventually) not only be only per-scene, but would be able to differ per-view.

Later we backtracked and we (for good reason) went back to my original idea that the overlay stats could be enabled separately from the footer stats. So we'd now have two versions, one in the footer that would remain per-scene and the overlay could move toward showing local stats.

I can't think of any reasons off the top of my head on why the footer stats can't be from bpy.context.scene.statistics as they were before. Seems reasonable.

@JulianEisel - are you available to work on this before bcon4 (Wednesday)?

Sorry no. I probably won't have much time to spare for Blender stuff for about a month or so, then will have piles of time through the winter.

Trying to remember the history of this thing, which is complex only because it had a few detours along the way. LOL. At the beginning my idea was to have the 3DView overlay stats be just a new option, without changing or removing the footer stats - **which is how it ended up in the end**. But... When I first showed this off it was then Brecht's opinion that either the code duplication be fixed or the footer stats removed. William's preference was to remove the footer stats. The other (important) comment is that we would eventually want the overlay stats to show local stats, not just overall scene stats. This is why the stats were removed from scene. There was only the one set of stats (as a 3DView overlay) and those would (eventually) not only be only per-scene, but would be able to differ per-view. Later we backtracked and we (for good reason) went back to my original idea that the overlay stats could be enabled separately from the footer stats. So we'd now have two versions, one in the footer that would remain per-scene and the overlay could move toward showing local stats. I can't think of any reasons off the top of my head on why the **footer stats** can't be from bpy.context.scene.statistics as they were before. Seems reasonable. > @JulianEisel - are you available to work on this before bcon4 (Wednesday)? Sorry no. I probably won't have much time to spare for Blender stuff for about a month or so, then will have piles of time through the winter.

Hans Goudey commented

2020-08-17 20:38:32 +02:00

In #79816#997442, @Harley wrote:
Sorry no. I probably won't have much time to spare for Blender stuff for about a month or so, then will have piles of time through the winter.

No worries! I'll post a patch today or tomorrow. Thanks for the context.

> In #79816#997442, @Harley wrote: > Sorry no. I probably won't have much time to spare for Blender stuff for about a month or so, then will have piles of time through the winter. No worries! I'll post a patch today or tomorrow. Thanks for the context.

Ethan Simon commented

2020-08-17 21:24:41 +02:00

Hans do you think it would be possible to return bpy.context.scene.statistics as something other than just a string (maybe a list) so it is easier to access? Currently I need to split the strings

Hans Goudey commented

2020-08-17 21:30:39 +02:00

In #79816#997494, @razed wrote:
Hans do you think it would be possible to return bpy.context.scene.statistics as something other than just a string (maybe a list) so it is easier to access? Currently I need to split the strings

Since the goal is to avoid the API breakage I don't think we'll work on that now, but that might be a good improvement in the future.

> In #79816#997494, @razed wrote: > Hans do you think it would be possible to return bpy.context.scene.statistics as something other than just a string (maybe a list) so it is easier to access? Currently I need to split the strings Since the goal is to avoid the API breakage I don't think we'll work on that now, but that might be a good improvement in the future.

Ethan Simon commented

2020-08-17 21:34:11 +02:00

Should I make a feature request for it? Not sure where I would go to request something for the Python API. I can think of some more put together ideas for improvements regarding it.

Jesse Yurkovich commented

2020-08-17 21:38:54 +02:00

+1 The important bit right now is that the API exists at all. Returning a proper "Stat" structure/dictionary back to python would be nice but that could happen later esp. considering the proximity to release right now.

Perhaps the Stat change could be done at the same time as supporting local view more properly, if/when that occurs that is, since that might break the api again anyhow.

+1 The important bit right now is that the API exists at all. Returning a proper "Stat" structure/dictionary back to python would be nice but that could happen later esp. considering the proximity to release right now. Perhaps the Stat change could be done at the same time as supporting local view more properly, if/when that occurs that is, since that might break the api again anyhow.

Hans Goudey commented

2020-08-17 22:25:09 +02:00

As far as I know the 3D view stats are completely separate now, so that shouldn't be a problem in the future. A detailed feature request could go on right click select, and maybe end up in a design task. But a patch would be best : )