aad23112b4289579ea2cb211c540fe8fa4551b13
[blender.git] / doc / python_api / rst / info_gotcha.rst
1 *******
2 Gotchas
3 *******
4
5 This document attempts to help you work with the Blender API in areas that can be troublesome and avoid practices that are known to give instability.
6
7
8 .. _using_operators:
9
10 Using Operators
11 ===============
12
13 Blender's operators are tools for users to access, that python can access them too is very useful nevertheless operators have limitations that can make them cumbersome to script.
14
15 Main limits are...
16
17 * Can't pass data such as objects, meshes or materials to operate on (operators use the context instead)
18
19 * The return value from calling an operator gives the success (if it finished or was canceled),
20   in some cases it would be more logical from an API perspective to return the result of the operation.
21
22 * Operators poll function can fail where an API function would raise an exception giving details on exactly why.
23
24
25 Why does an operator's poll fail?
26 ---------------------------------
27
28 When calling an operator gives an error like this:
29
30    >>> bpy.ops.action.clean(threshold=0.001)
31    RuntimeError: Operator bpy.ops.action.clean.poll() failed, context is incorrect
32
33 Which raises the question as to what the correct context might be?
34
35 Typically operators check for the active area type, a selection or active object they can operate on, but some operators are more picky about when they run.
36
37 In most cases you can figure out what context an operator needs simply be seeing how it's used in Blender and thinking about what it does.
38
39
40 Unfortunately if you're still stuck - the only way to **really** know whats going on is to read the source code for the poll function and see what its checking.
41
42 For python operators it's not so hard to find the source since it's included with Blender and the source file/line is included in the operator reference docs.
43
44 Downloading and searching the C code isn't so simple, especially if you're not familiar with the C language but by searching the operator name or description you should be able to find the poll function with no knowledge of C.
45
46 .. note::
47
48    Blender does have the functionality for poll functions to describe why they fail, but its currently not used much, if you're interested to help improve our API feel free to add calls to ``CTX_wm_operator_poll_msg_set`` where its not obvious why poll fails.
49
50       >>> bpy.ops.gpencil.draw()
51       RuntimeError: Operator bpy.ops.gpencil.draw.poll() Failed to find Grease Pencil data to draw into
52
53
54 The operator still doesn't work!
55 --------------------------------
56
57 Certain operators in Blender are only intended for use in a specific context, some operators for example are only called from the properties window where they check the current material, modifier or constraint.
58
59 Examples of this are:
60
61 * :mod:`bpy.ops.texture.slot_move`
62 * :mod:`bpy.ops.constraint.limitdistance_reset`
63 * :mod:`bpy.ops.object.modifier_copy`
64 * :mod:`bpy.ops.buttons.file_browse`
65
66 Another possibility is that you are the first person to attempt to use this operator in a script and some modifications need to be made to the operator to run in a different context, if the operator should logically be able to run but fails when accessed from a script it should be reported to the bug tracker.
67
68
69 Stale Data
70 ==========
71
72 No updates after setting values
73 -------------------------------
74
75 Sometimes you want to modify values from python and immediately access the updated values, eg:
76
77 Once changing the objects :class:`bpy.types.Object.location` you may want to access its transformation right after from :class:`bpy.types.Object.matrix_world`, but this doesn't work as you might expect.
78
79 Consider the calculations that might go into working out the object's final transformation, this includes:
80
81 * animation function curves.
82 * drivers and their pythons expressions.
83 * constraints
84 * parent objects and all of their f-curves, constraints etc.
85
86 To avoid expensive recalculations every time a property is modified, Blender defers making the actual calculations until they are needed.
87
88 However, while the script runs you may want to access the updated values.
89 In this case you need to call :class:`bpy.types.Scene.update` after modifying values, for example:
90
91 .. code-block:: python
92
93    bpy.context.object.location = 1, 2, 3
94    bpy.context.scene.update()
95
96
97 Now all dependent data (child objects, modifiers, drivers... etc) has been recalculated and is available to the script.
98
99 Can I redraw during the script?
100 -------------------------------
101
102 The official answer to this is no, or... *"You don't want to do that"*.
103
104 To give some background on the topic...
105
106 While a script executes Blender waits for it to finish and is effectively locked until its done, while in this state Blender won't redraw or respond to user input.
107 Normally this is not such a problem because scripts distributed with Blender tend not to run for an extended period of time, nevertheless scripts *can* take ages to execute and its nice to see whats going on in the view port.
108
109 Tools that lock Blender in a loop and redraw are highly discouraged since they conflict with Blenders ability to run multiple operators at once and update different parts of the interface as the tool runs.
110
111 So the solution here is to write a **modal** operator, that is - an operator which defines a modal() function, See the modal operator template in the text  editor.
112
113 Modal operators execute on user input or setup their own timers to run frequently, they can handle the events or pass through to be handled by the keymap or other modal operators.
114
115 Transform, Painting, Fly-Mode and File-Select are example of a modal operators.
116
117 Writing modal operators takes more effort than a simple ``for`` loop that happens to redraw but is more flexible and integrates better with Blenders design.
118
119
120 **Ok, Ok! I still want to draw from python**
121
122 If you insist - yes its possible, but scripts that use this hack wont be considered for inclusion in Blender and any issues with using it wont be considered bugs, this is also not guaranteed to work in future releases.
123
124 .. code-block:: python
125
126    bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1)
127
128
129 Modes and Mesh Access
130 =====================
131
132 When working with mesh data you may run into the problem where a script fails to run as expected in edit-mode. This is caused by edit-mode having its own data which is only written back to the mesh when exiting edit-mode.
133
134 A common example is that exporters may access a mesh through ``obj.data`` (a :class:`bpy.types.Mesh`) but the user is in edit-mode, where the mesh data is available but out of sync with the edit mesh.
135
136 In this situation you can...
137
138 * Exit edit-mode before running the tool.
139 * Explicitly update the mesh by calling :class:`bmesh.types.BMesh.to_mesh`.
140 * Modify the script to support working on the edit-mode data directly, see: :mod:`bmesh.from_edit_mesh`.
141 * Report the context as incorrect and only allow the script to run outside edit-mode.
142
143
144 .. _info_gotcha_mesh_faces:
145
146 NGons and Tessellation Faces
147 ============================
148
149 Since 2.63 NGons are supported, this adds some complexity since in some cases you need to access triangles/quads still (some exporters for example).
150
151 There are now 3 ways to access faces:
152
153 * :class:`bpy.types.MeshPolygon` - this is the data structure which now stores faces in object mode (access as ``mesh.polygons`` rather then ``mesh.faces``).
154 * :class:`bpy.types.MeshTessFace` - the result of triangulating (tessellated) polygons, the main method of face access in 2.62 or older (access as ``mesh.tessfaces``).
155 * :class:`bmesh.types.BMFace` - the polygons as used in editmode.
156
157 For the purpose of the following documentation, these will be referred to as polygons, tessfaces and bmesh-faces respectively.
158
159 5+ sided faces will be referred to as ``ngons``.
160
161 Support Overview
162 ----------------
163
164 +--------------+------------------------------+--------------------------------+--------------------------------+
165 |Usage         |:class:`bpy.types.MeshPolygon`|:class:`bpy.types.MeshTessFace` |:class:`bmesh.types.BMFace`     |
166 +==============+==============================+================================+================================+
167 |Import/Create |Bad (inflexible)              |Fine (supported as upgrade path)|Best                            |
168 +--------------+------------------------------+--------------------------------+--------------------------------+
169 |Manipulate    |Bad (inflexible)              |Bad (loses ngons)               |Best                            |
170 +--------------+------------------------------+--------------------------------+--------------------------------+
171 |Export/Output |Good (ngons)                  |Good (When ngons can't be used) |Good (ngons, memory overhead)   |
172 +--------------+------------------------------+--------------------------------+--------------------------------+
173
174
175 .. note::
176
177    Using the :mod:`bmesh` api is completely separate api from :mod:`bpy`, typically you would would use one or the other based on the level of editing needed, not simply for a different way to access faces.
178
179
180 Creating
181 --------
182
183 All 3 datatypes can be used for face creation.
184
185 * polygons are the most efficient way to create faces but the data structure is _very_ rigid and inflexible, you must have all your vertes and faces ready and create them all at once. This is further complicated by the fact that each polygon does not store its own verts (as with tessfaces), rather they reference an index and size in :class:`bpy.types.Mesh.loops` which are a fixed array too.
186 * tessfaces ideally should not be used for creating faces since they are really only tessellation cache of polygons, however for scripts upgrading from 2.62 this is by far the most straightforward option. This works by creating tessfaces and when finished - they can be converted into polygons by calling :class:`bpy.types.Mesh.update`. The obvious limitation is ngons can't be created this way.
187 * bmesh-faces are most likely the easiest way for new scripts to create faces, since faces can be added one by one and the api has features intended for mesh manipulation. While :class:`bmesh.types.BMesh` uses more memory it can be managed by only operating on one mesh at a time.
188
189
190 Editing
191 -------
192
193 Editing is where the 3 data types vary most.
194
195 * polygons are very limited for editing, changing materials and options like smooth works but for anything else they are too inflexible and are only intended for storage.
196 * tessfaces should not be used for editing geometry because doing so will cause existing ngons to be tessellated.
197 * bmesh-faces are by far the best way to manipulate geometry.
198
199 Exporting
200 ---------
201
202 All 3 data types can be used for exporting, the choice mostly depends on whether the target format supports ngons or not.
203
204 * polygons are the most direct & efficient way to export providing they convert into the output format easily enough.
205 * tessfaces work well for exporting to formats which dont support ngons, in fact this is the only place where their use is encouraged.
206 * bmesh-faces can work for exporting too but may not be necessary if polygons can be used since using bmesh gives some overhead because its not the native storage format in object mode.
207
208
209 Upgrading Importers from 2.62
210 -----------------------------
211
212 Importers can be upgraded to work with only minor changes.
213
214 The main change to be made is used the tessellation versions of each attribute.
215
216 * mesh.faces --> :class:`bpy.types.Mesh.tessfaces`
217 * mesh.uv_textures --> :class:`bpy.types.Mesh.tessface_uv_textures`
218 * mesh.vertex_colors --> :class:`bpy.types.Mesh.tessface_vertex_colors`
219
220 Once the data is created call :class:`bpy.types.Mesh.update` to convert the tessfaces into polygons.
221
222
223 Upgrading Exporters from 2.62
224 -----------------------------
225
226 For exporters the most direct way to upgrade is to use tessfaces as with importing however its important to know that tessfaces may **not** exist for a mesh, the array will be empty as if there are no faces.
227
228 So before accessing tessface data call: :class:`bpy.types.Mesh.update` ``(calc_tessface=True)``.
229
230
231 EditBones, PoseBones, Bone... Bones
232 ===================================
233
234 Armature Bones in Blender have three distinct data structures that contain them. If you are accessing the bones through one of them, you may not have access to the properties you really need.
235
236 .. note::
237
238    In the following examples ``bpy.context.object`` is assumed to be an armature object.
239
240
241 Edit Bones
242 ----------
243
244 ``bpy.context.object.data.edit_bones`` contains a editbones; to access them you must set the armature mode to edit mode first (editbones do not exist in object or pose mode). Use these to create new bones, set their head/tail or roll, change their parenting relationships to other bones, etc.
245
246 Example using :class:`bpy.types.EditBone` in armature editmode:
247
248 This is only possible in edit mode.
249
250    >>> bpy.context.object.data.edit_bones["Bone"].head = Vector((1.0, 2.0, 3.0)) 
251
252 This will be empty outside of editmode.
253
254    >>> mybones = bpy.context.selected_editable_bones
255
256 Returns an editbone only in edit mode.
257
258    >>> bpy.context.active_bone
259
260
261 Bones (Object Mode)
262 -------------------
263
264 ``bpy.context.object.data.bones`` contains bones. These *live* in object mode, and have various properties you can change, note that the head and tail properties are read-only.
265
266 Example using :class:`bpy.types.Bone` in object or pose mode:
267
268 Returns a bone (not an editbone) outside of edit mode
269
270    >>> bpy.context.active_bone
271
272 This works, as with blender the setting can be edited in any mode
273
274    >>> bpy.context.object.data.bones["Bone"].use_deform = True
275
276 Accessible but read-only
277
278    >>> tail = myobj.data.bones["Bone"].tail
279
280
281 Pose Bones
282 ----------
283
284 ``bpy.context.object.pose.bones`` contains pose bones. This is where animation data resides, i.e. animatable transformations are applied to pose bones, as are constraints and ik-settings.
285
286 Examples using :class:`bpy.types.PoseBone` in object or pose mode:
287
288 .. code-block:: python
289
290    # Gets the name of the first constraint (if it exists)
291    bpy.context.object.pose.bones["Bone"].constraints[0].name 
292
293    # Gets the last selected pose bone (pose mode only)
294    bpy.context.active_pose_bone
295
296
297 .. note::
298
299    Notice the pose is accessed from the object rather than the object data, this is why blender can have 2 or more objects sharing the same armature in different poses.
300
301 .. note::
302
303    Strictly speaking PoseBone's are not bones, they are just the state of the armature, stored in the :class:`bpy.types.Object` rather than the :class:`bpy.types.Armature`, the real bones are however accessible from the pose bones - :class:`bpy.types.PoseBone.bone`
304
305
306 Armature Mode Switching
307 -----------------------
308
309 While writing scripts that deal with armatures you may find you have to switch between modes, when doing so take care when switching out of editmode not to keep references to the edit-bones or their head/tail vectors. Further access to these will crash blender so its important the script clearly separates sections of the code which operate in different modes.
310
311 This is mainly an issue with editmode since pose data can be manipulated without having to be in pose mode, however for operator access you may still need to enter pose mode.
312
313
314 Data Names
315 ==========
316
317
318 Naming Limitations
319 ------------------
320
321 A common mistake is to assume newly created data is given the requested name.
322
323 This can cause bugs when you add some data (normally imported) then reference it later by name.
324
325 .. code-block:: python
326
327    bpy.data.meshes.new(name=meshid)
328    
329    # normally some code, function calls...
330    bpy.data.meshes[meshid]
331
332
333 Or with name assignment...
334
335 .. code-block:: python
336
337    obj.name = objname
338    
339    # normally some code, function calls...
340    obj = bpy.data.meshes[objname]
341
342
343 Data names may not match the assigned values if they exceed the maximum length, are already used or an empty string.
344
345
346 Its better practice not to reference objects by names at all, once created you can store the data in a list, dictionary, on a class etc, there is rarely a reason to have to keep searching for the same data by name.
347
348
349 If you do need to use name references, its best to use a dictionary to maintain a mapping between the names of the imported assets and the newly created data, this way you don't run this risk of referencing existing data from the blend file, or worse modifying it.
350
351 .. code-block:: python
352
353    # typically declared in the main body of the function.
354    mesh_name_mapping = {}
355    
356    mesh = bpy.data.meshes.new(name=meshid)
357    mesh_name_mapping[meshid] = mesh
358    
359    # normally some code, or function calls...
360    
361    # use own dictionary rather then bpy.data
362    mesh = mesh_name_mapping[meshid]
363
364
365 Library Collisions
366 ------------------
367
368 Blender keeps data names unique - :class:`bpy.types.ID.name` so you can't name two objects, meshes, scenes etc the same thing by accident.
369
370 However when linking in library data from another blend file naming collisions can occur, so its best to avoid referencing data by name at all.
371
372 This can be tricky at times and not even blender handles this correctly in some case (when selecting the modifier object for eg you can't select between multiple objects with the same name), but its still good to try avoid problems in this area.
373
374
375 If you need to select between local and library data, there is a feature in ``bpy.data`` members to allow for this.
376
377 .. code-block:: python
378
379    # typical name lookup, could be local or library.
380    obj = bpy.data.objects["my_obj"]
381
382    # library object name look up using a pair
383    # where the second argument is the library path matching bpy.types.Library.filepath
384    obj = bpy.data.objects["my_obj", "//my_lib.blend"]
385
386    # local object name look up using a pair
387    # where the second argument excludes library data from being returned.
388    obj = bpy.data.objects["my_obj", None]
389
390    # both the examples above also works for 'get'
391    obj = bpy.data.objects.get(("my_obj", None))
392
393
394 Relative File Paths
395 ===================
396
397 Blenders relative file paths are not compatible with standard python modules such as ``sys`` and ``os``.
398
399 Built in python functions don't understand blenders ``//`` prefix which denotes the blend file path.
400
401 A common case where you would run into this problem is when exporting a material with associated image paths.
402
403 >>> bpy.path.abspath(image.filepath)
404
405
406 When using blender data from linked libraries there is an unfortunate complication since the path will be relative to the library rather then the open blend file. When the data block may be from an external blend file pass the library argument from the :class:`bpy.types.ID`.
407
408 >>> bpy.path.abspath(image.filepath, library=image.library)
409
410
411 These returns the absolute path which can be used with native python modules.
412
413
414 Unicode Problems
415 ================
416
417 Python supports many different encodings so there is nothing stopping you from
418 writing a script in ``latin1`` or ``iso-8859-15``.
419
420 See `pep-0263 <http://www.python.org/dev/peps/pep-0263/>`_
421
422 However this complicates matters for Blender's Python API because ``.blend`` files don't have an explicit encoding.
423
424 To avoid the problem for Python integration and script authors we have decided all strings in blend files
425 **must** be ``UTF-8``, ``ASCII`` compatible.
426
427 This means assigning strings with different encodings to an object names for instance will raise an error.
428
429 Paths are an exception to this rule since we cannot ignore the existence of non ``UTF-8`` paths on users file-system.
430
431 This means seemingly harmless expressions can raise errors, eg.
432
433    >>> print(bpy.data.filepath)
434    UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-21: ordinal not in range(128)
435
436    >>> bpy.context.object.name = bpy.data.filepath
437    Traceback (most recent call last):
438      File "<blender_console>", line 1, in <module>
439    TypeError: bpy_struct: item.attr= val: Object.name expected a string type, not str
440
441
442 Here are 2 ways around filesystem encoding issues:
443
444    >>> print(repr(bpy.data.filepath))
445
446    >>> import os
447    >>> filepath_bytes = os.fsencode(bpy.data.filepath)
448    >>> filepath_utf8 = filepath_bytes.decode('utf-8', "replace")
449    >>> bpy.context.object.name = filepath_utf8
450
451
452 Unicode encoding/decoding is a big topic with comprehensive python documentation, to avoid getting stuck too deep in encoding problems - here are some suggestions:
453
454 * Always use utf-8 encoiding or convert to utf-8 where the input is unknown.
455
456 * Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
457
458 * Use ``os.fsencode()`` / ``os.fsdecode()`` rather then the built in string decoding functions when operating on paths.
459
460 * To print paths or to include them in the user interface use ``repr(path)`` first or ``"%r" % path`` with string formatting.
461
462 * **Possibly** - use bytes instead of python strings, when reading some input its less trouble to read it as binary data though you will still need to decide how to treat any strings you want to use with Blender, some importers do this.
463
464
465 Strange errors using 'threading' module
466 =======================================
467
468 Python threading with Blender only works properly when the threads finish up before the script does. By using ``threading.join()`` for example.
469
470 Heres an example of threading supported by Blender:
471
472 .. code-block:: python
473
474    import threading
475    import time
476
477    def prod():
478        print(threading.current_thread().name, "Starting")
479
480        # do something vaguely useful
481        import bpy
482        from mathutils import Vector
483        from random import random
484
485        prod_vec = Vector((random() - 0.5, random() - 0.5, random() - 0.5))
486        print("Prodding", prod_vec)
487        bpy.data.objects["Cube"].location += prod_vec
488        time.sleep(random() + 1.0)
489        # finish
490
491        print(threading.current_thread().name, "Exiting")
492
493    threads = [threading.Thread(name="Prod %d" % i, target=prod) for i in range(10)]
494
495
496    print("Starting threads...")
497
498    for t in threads:
499        t.start()
500
501    print("Waiting for threads to finish...")
502
503    for t in threads:
504        t.join()
505
506
507 This an example of a timer which runs many times a second and moves the default cube continuously while Blender runs **(Unsupported)**.
508
509 .. code-block:: python
510
511    def func():
512        print("Running...")
513        import bpy
514        bpy.data.objects['Cube'].location.x += 0.05
515
516    def my_timer():
517        from threading import Timer
518        t = Timer(0.1, my_timer)
519        t.start()
520        func()
521
522    my_timer()
523
524 Use cases like the one above which leave the thread running once the script finishes may seem to work for a while but end up causing random crashes or errors in Blender's own drawing code.
525
526 So far, no work has gone into making Blender's python integration thread safe, so until its properly supported, best not make use of this.
527
528 .. note::
529
530    Pythons threads only allow co-currency and won't speed up your scripts on multi-processor systems, the ``subprocess`` and ``multiprocess`` modules can be used with Blender and make use of multiple CPU's too.
531
532
533 Help! My script crashes Blender
534 ===============================
535
536 Ideally it would be impossible to crash Blender from python however there are some problems with the API where it can be made to crash.
537
538 Strictly speaking this is a bug in the API but fixing it would mean adding memory verification on every access since most crashes are caused by the python objects referencing Blenders memory directly, whenever the memory is freed, further python access to it can crash the script. But fixing this would make the scripts run very slow, or writing a very different kind of API which doesn't reference the memory directly.
539
540 Here are some general hints to avoid running into these problems.
541
542 * Be aware of memory limits, especially when working with large lists since Blender can crash simply by running out of memory.
543
544 * Many hard to fix crashes end up being because of referencing freed data, when removing data be sure not to hold any references to it.
545
546 * Modules or classes that remain active while Blender is used, should not hold references to data the user may remove, instead, fetch data from the context each time the script is activated.
547
548 * Crashes may not happen every time, they may happen more on some configurations/operating-systems.
549
550 .. note::
551
552    To find the line of your script that crashes you can use the ``faulthandler`` module.
553    See `faulthandler docs <http://docs.python.org/dev/library/faulthandler.html>`_.
554
555    While the crash may be in Blenders C/C++ code, this can help a lot to track down the area of the script that causes the crash.
556
557
558 Undo/Redo
559 ---------
560
561 Undo invalidates all :class:`bpy.types.ID` instances (Object, Scene, Mesh, Lamp... etc).
562
563 This example shows how you can tell undo changes the memory locations.
564
565    >>> hash(bpy.context.object)
566    -9223372036849950810
567    >>> hash(bpy.context.object)
568    -9223372036849950810
569
570    # ... move the active object, then undo
571
572    >>> hash(bpy.context.object)
573    -9223372036849951740
574
575 As suggested above, simply not holding references to data when Blender is used interactively by the user is the only way to ensure the script doesn't become unstable.
576
577
578 Undo & Library Data
579 ^^^^^^^^^^^^^^^^^^^
580
581 One of the advantages with Blenders library linking system that undo can skip checking changes in library data since it is assumed to be static.
582
583 Tools in Blender are not allowed to modify library data.
584
585 Python however does not enforce this restriction.
586
587 This can be useful in some cases, using a script to adjust material values for example.
588 But its also possible to use a script to make library data point to newly created local data, which is not supported since a call to undo will remove the local data but leave the library referencing it and likely crash.
589
590 So it's best to consider modifying library data an advanced usage of the API and only to use it when you know what you're doing.
591
592
593 Edit Mode / Memory Access
594 -------------------------
595
596 Switching edit-mode ``bpy.ops.object.mode_set(mode='EDIT')`` / ``bpy.ops.object.mode_set(mode='OBJECT')`` will re-allocate objects data, any references to a meshes vertices/polygons/uvs, armatures bones, curves points etc cannot be accessed after switching edit-mode.
597
598 Only the reference to the data its self can be re-accessed, the following example will crash.
599
600 .. code-block:: python
601
602    mesh = bpy.context.active_object.data
603    polygons = mesh.polygons
604    bpy.ops.object.mode_set(mode='EDIT')
605    bpy.ops.object.mode_set(mode='OBJECT')
606
607    # this will crash
608    print(polygons)
609
610
611 So after switching edit-mode you need to re-access any object data variables, the following example shows how to avoid the crash above.
612
613 .. code-block:: python
614
615    mesh = bpy.context.active_object.data
616    polygons = mesh.polygons
617    bpy.ops.object.mode_set(mode='EDIT')
618    bpy.ops.object.mode_set(mode='OBJECT')
619
620    # polygons have been re-allocated
621    polygons = mesh.polygons
622    print(polygons)
623
624
625 These kinds of problems can happen for any functions which re-allocate the object data but are most common when switching edit-mode.
626
627
628 Array Re-Allocation
629 -------------------
630
631 When adding new points to a curve or vertices's/edges/polygons to a mesh, internally the array which stores this data is re-allocated.
632
633 .. code-block:: python
634
635    bpy.ops.curve.primitive_bezier_curve_add()
636    point = bpy.context.object.data.splines[0].bezier_points[0]
637    bpy.context.object.data.splines[0].bezier_points.add()
638
639    # this will crash!
640    point.co = 1.0, 2.0, 3.0
641
642 This can be avoided by re-assigning the point variables after adding the new one or by storing indices's to the points rather then the points themselves.
643
644 The best way is to sidestep the problem altogether add all the points to the curve at once. This means you don't have to worry about array re-allocation and its faster too since reallocating the entire array for every point added is inefficient.
645
646
647 Removing Data
648 -------------
649
650 **Any** data that you remove shouldn't be modified or accessed afterwards, this includes f-curves, drivers, render layers, timeline markers, modifiers, constraints along with objects, scenes, groups, bones.. etc.
651
652 The ``remove()`` api calls will invalidate the data they free to prevent common mistakes.
653
654 The following example shows how this precortion works.
655
656 .. code-block:: python
657
658    mesh = bpy.data.meshes.new(name="MyMesh")
659    # normally the script would use the mesh here...
660    bpy.data.meshes.remove(mesh)
661    print(mesh.name)  # <- give an exception rather then crashing:
662
663    # ReferenceError: StructRNA of type Mesh has been removed
664
665
666 But take care because this is limited to scripts accessing the variable which is removed, the next example will still crash.
667
668 .. code-block:: python
669
670    mesh = bpy.data.meshes.new(name="MyMesh")
671    vertices = mesh.vertices
672    bpy.data.meshes.remove(mesh)
673    print(vertices)  # <- this may crash
674
675
676 sys.exit
677 ========
678
679 Some python modules will call ``sys.exit()`` themselves when an error occurs, while not common behavior this is something to watch out for because it may seem as if blender is crashing since ``sys.exit()`` will quit blender immediately.
680
681 For example, the ``optparse`` module will print an error and exit if the arguments are invalid.
682
683 An ugly way of troubleshooting this is to set ``sys.exit = None`` and see what line of python code is quitting, you could of course replace ``sys.exit`` with your own function but manipulating python in this way is bad practice.
684