infrastructure/blender-org
5
4
Fork 1
Code Issues 16 Pull Requests Projects Releases Wiki Activity

Python API Reference for BMesh - not up to date #38144

New Issue
Closed
opened 2014-01-09 22:21:51 +01:00 by Alexander N. · 6 comments
Alexander N. commented 2014-01-09 22:21:51 +01:00
Copy Link

the BMesh API doc page is not up to date.
there are missing / none documented parts...

BMLayerAccessVert

BMLayerAccessEdge

  • freestyle - not documented

BMLayerAccessFace

  • freestyle - not documented
  • tex - still incomplete -> BMTexPoly is marked as (TODO), since release (~2.63),

BMTexPoly

  • not documented at all.
the BMesh API doc page is not up to date. there are missing / none documented parts... ## [BMLayerAccessVert ](http://www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMLayerAccessVert) * **[deform ]]** - where [[ http:*www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMDeformVert | BMDeformVert ](http:*www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMLayerAccessVert.deform) is marked as TODO, but there is already a reference further down for it. * **skin** - (its new for 2.70?) not documented ## [BMLayerAccessEdge ](http://www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMLayerAccessEdge) * **freestyle** - not documented ## [BMLayerAccessFace ](http://www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMLayerAccessFace) * **freestyle** - not documented * **[tex ](http://www.blender.org/documentation/blender_python_api_2_69_release/bmesh.types.html#bmesh.types.BMLayerAccessFace.tex)** - still incomplete -> BMTexPoly is marked as (TODO), since release (~2.63), ## BMTexPoly * not documented at all.
Alexander N. commented 2014-01-09 22:21:51 +01:00
Author
Copy Link

Changed status to: 'Open'

Changed status to: 'Open'
Alexander N. commented 2014-01-09 22:21:51 +01:00
Author
Copy Link

Added subscriber: @beta-tester

Added subscriber: @beta-tester
Brecht Van Lommel commented 2014-01-10 19:32:55 +01:00
Owner
Copy Link

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Brecht Van Lommel self-assigned this 2014-01-10 19:32:55 +01:00
Brecht Van Lommel commented 2014-01-10 19:32:55 +01:00
Owner
Copy Link

There are indeed some undocumented things in the python API, that's not considered a bug though, we accept patches to document these.

There are indeed some undocumented things in the python API, that's not considered a bug though, we accept patches to document these.
Alexander N. commented 2014-01-11 21:03:49 +01:00
Author
Copy Link

i am sorry about that comment.
(it gives me the feel, pushing new functionalities has highest priority, but documentation these has no priority)

i am not the developer who was planing/designing/implementing the api for these missing/undocumented functions/functionalities.
for example, i use the tex-layer that is not documented. by try and error and using dir(...)-method, i was able to find the functionality i was looking for or needed by myself.
but that knowledge is far away from that, to be able to write a patch for a proper and correct documentation.
i think only these persons who was involved with the design and/or implementation are qualified to document functions correctly.
when i would try to write a documentation, it would be very "speculative" and may not reflect the correct meaning of the implementation behind.

i thought, when something new is planed/designed for an API, there exist a kind of documentation as guideline/template for the developer for implementation.
ok, open source and free, toll its price, i know - not all is as well organized as in a big well bureaucratic company.

please do not misunderstand me...
i am very thankful for blender bmesh python and all other blender stuff
but without a proper documentation it is very hard to use functions in an efficient way.

i am sorry about that comment. (it gives me the feel, pushing new functionalities has highest priority, but documentation these has no priority) i am not the developer who was planing/designing/implementing the api for these missing/undocumented functions/functionalities. for example, i use the tex-layer that is not documented. by try and error and using dir(...)-method, i was able to find the functionality i was looking for or needed by myself. but that knowledge is far away from that, to be able to write a patch for a proper and correct documentation. i think only these persons who was involved with the design and/or implementation are qualified to document functions correctly. when i would try to write a documentation, it would be very "speculative" and may not reflect the correct meaning of the implementation behind. i thought, when something new is planed/designed for an API, there exist a kind of documentation as guideline/template for the developer for implementation. ok, open source and free, toll its price, i know - not all is as well organized as in a big well bureaucratic company. please do not misunderstand me... i am very thankful for blender bmesh python and all other blender stuff but without a proper documentation it is very hard to use functions in an efficient way.
Brecht Van Lommel commented 2014-01-12 15:07:20 +01:00
Owner
Copy Link

We know, these really should be documented from the start. However it's just how we organize work here, the bug tracker is for things that were designed to work but are broken somehow, to keep the workload manageable, it's things that we can promise to solve. Other todo issues like can be important but are not strictly considered bugs.

We know, these really should be documented from the start. However it's just how we organize work here, the bug tracker is for things that were designed to work but are broken somehow, to keep the workload manageable, it's things that we can promise to solve. Other todo issues like can be important but are not strictly considered bugs.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
legacy module
Rendering & Cycles

  
legacy module
User Interface

  
legacy project
Cycles

  
legacy project
Documentation

  
legacy project
Infrastructure: blender.org

  
legacy project
Infrastructure: Blender Web Assets

  
legacy project
Infrastructure: Websites

  
legacy project
User Interface

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Report

  
Type
To Do

No Label
legacy module
Rendering & Cycles
legacy module
User Interface
legacy project
Cycles
legacy project
Documentation
legacy project
Infrastructure: blender.org
legacy project
Infrastructure: Blender Web Assets
legacy project
Infrastructure: Websites
legacy project
User Interface
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
Brecht Van Lommel
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/blender-org#38144
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?