# UV Layout Export: use 'bpy.data.meshes.new_from_object()'AbandonedPublicActions

Authored by Philipp Oeser (lichtwerk) on Jun 21 2019, 3:29 PM.

# Details

Reviewers
 Jacques Lucke (JacquesLucke) Sergey Sharybin (sergey)
Summary

this is so temporary meshes can be freed without messing up other addons
that might have called UV Layout Export [and used ob.to_mesh()]

followup to T65990 / rBA1c08d210faf6 (also see D5112 for reasoning)

# Diff Detail

Repository
Branch
master
Build Status
 Buildable 3907 Build 3907: arc lint + arc unit

### Event Timeline

Haven't tested it, but seems fine.

This revision is now accepted and ready to land.Jun 21 2019, 3:41 PM

would still like to hear @Sergey Sharybin (sergey) 's opinion, still sounds like bpy.data.meshes.new_from_object() is not meant for temporary usage.
Still the case presented in D5112 [other addons calling this as well -- that might also have called ob_eval.to_mesh()] sounds like it would apply to many addons?
Should all relevant addons use meshes.new_from_object()+ meshes.remove() as opposed to ob.to_mesh() + ob.to_mesh_clear() then?

meshes.new_from_object() is indeed not meant for temporary usage, but historically it was used as such.

I am not sure what you mean by would apply to many addons.

meshes.new_from_object() is indeed not meant for temporary usage, but historically it was used as such.
I am not sure what you mean by would apply to many addons.

What I mean is we have a couple of addon-operators calling ob.to_mesh_clear().
If these are called from other addons that also use ob.to_mesh(), this would make the other calling code's meshes invalid, right?
(see @Jacques Lucke (JacquesLucke) 's inline comment in D5112)

To me this does not justify pollution of main database with a temporary objects. It's the same as operator storing point to ID/data and calling an operator which modifies that ID/operator.

So I guess we'll leave this "as is" [unless @Jacques Lucke (JacquesLucke) has objections?]