No mention in docs about using default=colander.drop

[tisdall]

You can apparently use a colander.drop as a value for default, but there's no mention in the documents.

Example:

>>> x = colander.SchemaNode(
...     colander.Mapping(),
...     colander.SchemaNode(colander.String(), name="y")
... )
>>> x.serialize({'y':3})
{'y': '3'}
>>> x.serialize({})
{'y': <colander.null>}
>>> x = colander.SchemaNode(
...     colander.Mapping(),
...     colander.SchemaNode(colander.String(), name="y", default=colander.drop)
... )
>>> x.serialize({})
{}

Now, I find this feature very useful for what I'm working on. However, before I work on updating the docs to mention how this works, does anyone have any reasons for this to be labelled a bug?

[tisdall]

Okay, it seems that this is mentioned in the CHANGES.rst but no one has updated the documentation.

[tonthon]

colander.drop should be used as value for missing, not default
http://docs.pylonsproject.org/projects/colander/en/latest/api.html#colander.SchemaNode

missing: The default deserialization value for this node. If it is not provided, the missing value of this node will be the special marker value colander.required, indicating that it is considered ‘required’. When missing is colander.required, the required computed attribute will be True. When missing is colander.drop, the node is dropped from the schema if it isn’t set during serialization/deserialization.

[tisdall]

@tonthon - https://github.com/Pylons/colander/blob/master/CHANGES.rst#features-1 point 2.

[tonthon]

@tisdall - Oh I missed that one, I didn't know colander.drop could be used that way. Thanks for pointing it.

[tisdall]

@tonthon, and do you know why you didn't know? Because it's not in the docs!

[stevepiercy]

Is there a PR that closes this issue? I can merge a PR for the docs only, but not code as I don't have the necessary familiarity.

[tisdall]

@stevepiercy #238 is sort-of docs only... ^_^ But, no, I haven't made anything to update the docs regarding this. I'm not working with colander right now so I likely won't be submitting a PR either so it's open for someone to contribute.

[mmerickel]

A PR improving the docs for this feature is likely to be accepted. Any movement on this?

[lmctv]

Forgot to put a reference to this issue in the pull request #248

[tisdall]

fixed in #248