Comments (9)
Ok, so going through documentation, one solution for me would be to use init_fields
(Can't use make_init
since I have a custom constructor - my main reason I preferred this lib over attrs
)
However, the problem is that in my usecase these fields really are lazily initialised and may not really exist in the object. I have a bunch of enrichers which add these fields as the object passes through a pipeline. Until then I really want them to be None or Empty.
init_fields
with default=None also doesn't work (Since it does validation)
I realize that this may be a very custom usecase - so I need a proper eq maybe?
from python-pyfields.
Ah, I guess defaulting to None was the problem :) Not using that solves my problem.
Sorry for creating unnecessary issue.
One reason why I was defaulting to None. My class is something like:
class A:
field1: int = field(check_type=True, default=None)
def __eq__(self, other):
return type(self) is type(other) and self.__dict__ == other.__dict__
# derived field
@property
def derived_field(self):
return 50-self.field1 if self.field1 else None
I guess now I have to do a try except MandatoryFieldInitError
if someone accesses the derived field? They can't simply do a None check?
Btw, One clean way which would solve my issue is adding a nullable
param in the field definition. Does that make sense? If it does I can open an issue for the same and happy to contribute a PR for the same (time permitting)
from python-pyfields.
Thanks @devashishshankar for digging on this !
Let's backtrack a little bit on your initial need, not on the workarounds that you have found so far. If I understand your problem correctly,
-
you wish to have a base field
field1
that is optional (users do not have to provide a value) -
your initial need was to be able to compare objects. For this you would need the same kind of feature than
attrs
on top of the fields. I will soon updateautoclass
so that it can do this, you will be able to use either@autodict
or@autoclass
on your class for this. Stay tuned: smarie/python-autoclass#28 -
you wish to create a derived property on top of the field. If the field is optional it works out of the box: you will get
None
in the field value
So based on the above, your need should be solved by @autodict
/ @autoclass
, with a "more intelligent" __eq__
.
Except that you seem to be talking about validation. Here comes the nullable
need. If you use python 3.5+ the best solution for now is to declare the type of your field as Optional[int]
. But it could make sense to have an explicit nullable
argument in field
though, I'll open a dedicated issue.
from python-pyfields.
Thank you! Optional works perfectly for me. For me nullable and Optional mean the same thing, I don't see why nullable would be useful if typing already has support for Optional
Autoclass and Autodict look great! Will definitely use it in future. In this case, though, pyfields works better for me since I am inheriting from a superclass (which is in a common lib I don't want to change right now). Don't know if autoclass is compatible with inheritance.
from python-pyfields.
For me nullable and Optional mean the same thing
indeed they do, that's why many of us asked for a rename (Nonable
was my actual favorite, see whole discussion).
The open issue #44 is mostly for compatibility with versions of python that do not have typing
or do not wish to use it, and also to make the value validators (another feature of pyfields) skip validation in case None
is passed.
Concerning autoclass (or its subtasks autodict, autohash, etc.), it sources its attribute list today from the constructor signature. Tomorrow I will have it detect pyfields and therefore source the list from the list of fields. It shoud support inheritance, yes.
Shall we close this ticket then ?
from python-pyfields.
indeed they do, that's why many of us asked for a rename (Nonable was my actual favorite, see whole discussion).
Yeah, correct. Optional can refer to fields with default values (which need not be passed while constructing the object). I guess here I've made my fields both Nonable and Optional (by setting default to None) - which serves my case quite well. I don't want to differentiate between field not being set, and and field set to None, so I set them to None by default. A side effect of this is also a simpler __eq__
The open issue #44 is mostly for compatibility with versions of python that do not have typing or do not wish to use it, and also to make the value validators (another feature of pyfields) skip validation in case None is passed.
Okay, I guess typing
has been backported to python2? So a user can pass Optional[int] as a type_hint
? But nullable
makes sense if they don't want to install/use typing.
Concerning autoclass (or its subtasks autodict, autohash, etc.), it sources its attribute list today from the constructor signature. Tomorrow I will have it detect pyfields and therefore source the list from the list of fields. It shoud support inheritance, yes.
Ah okay. How will it be different from just using pyfield's init_fields()
or make_init()
? It would provide additional things like autodict
and autohash
? pyfields looks very similar to autoprops
to me except that fields are not sourced from the constructor.
Shall we close this ticket then ?
Yes, closing it.
from python-pyfields.
Ah okay. How will it be different from just using pyfield's init_fields() or make_init()? It would provide additional things like autodict and autohash?
Exactly. Using @autoclass
on a class using pyfields will perform @autodict
and @autohash
only (and these two will be modified so that they automatically source the attribute list from fields)
pyfields looks very similar to autoprops to me except that fields are not sourced from the constructor.
Indeed ! You can consider pyfields
as a much more efficient version of autoprops
. When I wrote autoclass
3 years ago I was not as expert in python as I am now, so I found that this was "good enough". With the brand new pyfields
I was able to greatly improve both style/compactness and performance.
Thanks again for all the feedback ! I'll work on fixing all this today and tomorrow
from python-pyfields.
For information: version 0.13.0
brings nonable
feature. I hope that will do the trick for you. (if not feel free to open another ticket !)
from python-pyfields.
Great! Like that it infers it is nonable if default=None
from python-pyfields.
Related Issues (20)
- `get_fields`, `yield_fields`, `get_field_values` should have an optional argument to include properties, descriptors, and vars
- Validate after setting multiple fields at once HOT 3
- Getting type hints in `Field.__set_name__` can cause `RuntimeError` HOT 3
- `Optional` type hint is not correctly interpreted by `@autofields` HOT 1
- Provide a simplified `@autoclass` shortcut in this package
- `@autofields` does not take definition order into account HOT 1
- `@autofields` and order 2
- Add `check_type=True` option to `@autoclass` and the like
- Get rid of `autoclass` dependency
- "Missing required positional argument" for default field HOT 5
- Separate makers for hash, dict, eq, and repr HOT 3
- Incorrect work of lists in fields. HOT 2
- `TypeError: can't pickle _abc_data objects` when a class made with pyfields inherits from an ABC HOT 2
- Feature request: Option for keyword-only constructor in `make_init` and friends HOT 3
- `has_fields` leads to `AttributeError: __mro__` when the argument provided is a `typing.Union`
- Typeguard 3.0.0 incompatibility
- Remove the bandit version constraint when not needed anymore in the flake8-requirements
- TypeError "Neither typeguard not pytypes is installed"... but typeguard is installed HOT 1
- Type hints from annotations are not correct since python 3.10
- Migrate CI to virtualenv to support python 3.10-3.12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-pyfields.