Submitted alternate patch that supports defering the evaluation and only allocates the string when it's needed: D11001

Having extra optional return values has the down size that you couldn't reliably use a poll function from another operator, if OtherOperator.poll(C): ... would always evaluate to true.

Suggestion for possible 2.0 change:

@Sybren A. Stüvel (sybren) good points, I like your idea.
AFAIK the main reason the operator poll() doesn't take context as const is to be able to set the disabled hint. Eventually I'd like to see this addressed, and not having the Python code rely on this is a good idea I think, might save us some trouble later on.

My concern with this patch is poll functions which are meant to be fast/simple will end up with string creation logic when it's not needed.

I don't think there is other code that requires Python to actually set things in the context, so personally I wouldn't intuitively end up at this solution if I were looking for a way to do this.

_PropertyDeferred exposes the function and keywords via function and keywords attributes.

Thanks,
You mean to turn
lam.pos = Seq_Pos.annotations
into
lam.pos:Seq_Pos.annotations
?
That gives me KeyError

solution is here:

Problem is that this function doesn't cover this case: https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_handlers.c$622-640.
Ideally this could just walk up the RNA path of the property to see if any parent is of a preferences RNA type. But we can't get that path there unfortunately, not sure if there's a way to get it.
Alternatively, when registering custom properties, BPY could flag them as "inside a preferences struct". But this would break when nesting a property group inside a property group inside the add-on preferences...

In T85734#1144826, @nBurn (nBurn) wrote:

As for 0515ff70ec09, I tried a recent build with that commit applied, but it didn't appear to change the situation related needing a constraint applied for "orient_matrix".

The result changed, without constraint the object rotates in the other direction.
I'm not sure if your problem is the same as reported however.

@Germano Cavalcante (mano-wii)!! Thanks for looking into this and for the tip about constraints! I didn't expect changing the "constraint_axis" argument would get my "ops.transform.rotate" code working again in 2.93. I guess I must have given up on that argument after changing it didn't fix this issue in Blender 2.92.0.

Hi,
I have just tested the daily build and the issue still exists.

Since the tickets are merged I am going to answer here.

Thanks a lot. I'll test it with a nightly build when it gets an update.

Although this was closed as resolved, the behavior after rB0515ff70ec09 is not the same as before as there are differences in rotation with and without constraint.

In general proposal LGTM.

Added a separate proposal for type hints: T87333: Proposal for type hint use in Blender's Python scripts

My main concern is avoiding difficult to enforce rules, perhaps tooling could enforce this, although the exact details of modules which are loaded is probably platform spesific.

In T86943#1136542, @Campbell Barton (campbellbarton) wrote:

We could list some exceptions, however I'm wary of complicating rules. If anyone who writes an import needs to consult a table of modules in the wiki (that may change over time) - it risks being impractical to follow.

Extended the definition of startup scripts to include the bpy module it's self.

This example is working, thanks!

@Philipp Oeser (lichtwerk) I've narrowed down the commits where the my test code stopped working.

Ah, good to know, thx @Campbell Barton (campbellbarton)

This still works, the example given relied on an internal representation of properties which was never documented or intended for script authors to depend on.

Looks like a valid usecase, but not sure how to classify.
Will confirm for now though and even dare setting this to High priority -- since I would not be aware of a way around this "new limitation/regression" for now.

This has been discussed and a poc has been made by @Ray molenkamp (LazyDodo): https://devtalk.blender.org/t/blender-user-scripts-and-multiple-paths/10395

Looked into this, and this is another example where execution of an operator fails outside the correct context of the 3DView.

Can confirm, will check.

Interesting usecase, confirming then.

Can confirm.
These might be related:

It might be good to keep an eye on D10874: Nodes: Separate node name and display name in bNodeTreePath. -- or join the discussion there.

In T86871#1137771, @Pratik Borhade (PratikPB2123) wrote:

still getting the crash. tested again with version : 2.93.0 alpha , hash : 9975af5ffa7 , commit date : 2021-03-29
Hi @Pedro A. (povmaniaco) , are you on Windows ??

Closing since this has been implemented

@Philipp Oeser (lichtwerk) can repro, feels like some kind of heap corruption or use after free business, try reproducing with an ASAN build, should pop right up

still getting the crash. tested again with version : 2.93.0 alpha , hash : 9975af5ffa7 , commit date : 2021-03-29
Hi @Pedro A. (povmaniaco) , are you on Windows ??

I tested here in 2.93 alpha and the crash don't happend anymore. Anyone can confirm this?
Cheers..

Resolved rB5ffbe439c609

I did some more testing and It seems like the "orient_matrix" argument in "bpy.ops.transform.rotate" is being ignored entirely. I ran my rotate test code twice, once with an orient_matrix argument and once without and there was no difference in the matrix_world of the transformed object.

In rna_ui.c it clears the PROP_NEVER_NULL flag. Either this needs to be changed to enforce that it is never null or the validation needs to be improved.

I can confirm this crash.

Ah, yeah. I guess there's two contradictory behaviours: Custom properties are usually item keys, but dir() seems to treat them like attributes? Which one is more correct, and does anything rely on the current behaviour of dir()?

can confirm , crash occurs frequently . Still suggest some windows user to test it .

In T86943#1136287, @Sybren A. Stüvel (sybren) wrote:

Delay imports.

I think the practical effect of this is inversely proportional to the commonality of the module. For example, delaying an import of os or addon_utils will hardly have any effect, because the os module is very likely already available in sys.modules['os']. A delayed import only avoids a single dict lookup and name assignment (import os is then equivalent to os = sys.modules['os']). For other, less often used modules, such as webbrowser or rna_xml, I certainly agree with the late import guideline.

I can confirm this crash on the latest 2.93.0 Alpha, branch: master, commit date: 2021-03-25 08:16, hash: rB3b0531154e0d.

Delay imports.

I think the practical effect of this is inversely proportional to the commonality of the module. For example, delaying an import of os or addon_utils will hardly have any effect, because the os module is very likely already available in sys.modules['os']. A delayed import only avoids a single dict lookup and name assignment (import os is then equivalent to os = sys.modules['os']). For other, less often used modules, such as webbrowser or rna_xml, I certainly agree with the late import guideline.

Applied with some edits, LayerCollection will use an ID of Collection, there was a missing message for pose bones.

This feature wasn't implemented for python API functions. There are more differences between what these functions do and what operators do.
I can add fit method as non mandatory argument as it is reasonable to have it for loading files.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Weird, I was sure my rotation test code was throwing an AttributeError earlier when run directly from Blender 2.93's text editor. This is why I wrapped it in an addon. But I just tried it again a few minutes ago and it worked fine when run from 2.93's text editor.

Interesting that 'prop' in dir(ob) returns True.
I don't think the problem is in the rna2xml module, but something involving custom properties.

@Philipp Oeser (lichtwerk) no problem.

Hi, apologies. Had no time to optimize the code. Thank you.

Thx checking, @nBurn (nBurn) !
Will have another look then.

I wrote some basic code to test rotations when I was updating Exact Edit.
I wrapped that code in a basic add-on for ease of use:

In T85803#1133807, @Michael Schnabel (Tarcontar) wrote:

Hey, any updates on this?

I can confirm this issue on the latest 2.93.0 Alpha, branch: master, commit date: 2021-03-22 11:23, hash: rBc4c195672ddd.

Ah, get it now.

@Campbell Barton (campbellbarton) sorry about that, must have missed to compile or something. Patch is updated to master and changed according to what I think you meant..