Comments (9)
I'm not sure that you want attribute accessors, given that the set of CE attributes are unknown a priori due to the possible presence of extensions. Using attribute access may also make iterating over all the attributes, or adding additional methods on the class more difficult.
from sdk-python.
I was thinking about providing an interface from CloudEvent to the existing python properties within the base event class such as:
cloudevent = CloudEvent(attributes, data)
cloudevent.event.specversion
I don't want access properties to the _attribute field if that's what you thought I meant. I acknowledge this will take a bit of refactoring/design decision rework if we agreed to go this route because we'd likely have to instantiate some form of events during the constructor call which will require discussion.
For extensions, which are unknown, you can access them through the above example by doing:
cloudevent.event.extensions['key']
This naming schema feels a tad bit inconvenient so perhaps we can make adjustments here but overall I think it would be nice for users to be able to auto complete fields through python properties, specifically for the required and optional cloudevent metadata fields. It would reduce obscurity during event consumption and make code slightly more verbose in my opinion.
Aside from that we will want to revise the README to have example usage of the getitem overload. I sort of want to overhaul the README in general. I don't think we want to recommend users to use the base event classes atm. I'll issue a follow up PR on README changes but lmk your thoughts on the above @evankanderson
from sdk-python.
All the old base stuff needs to disappear or at least be hidden and not recommended for external use. You'll note that I didn't hold on to the base event in http_events.py
after parsing. I just wasn't quite ready to bite the bullet of restructuring all the parsing code.
One thing I would try to do before declaring a v1
API would be to also separate out the HTTP components from the event class. At the very least, I'd hope to have the following to/from static (non-class) methods:
to_json
- converts to transport-agnostic JSON (for example, if you want to store in a file)to_structured_http
- probably the equivalent of.to_http(converters.TypeStructured)
to_binary_http
- ditto for.to_http(converters.TypeBinary)
from_json
- converts to and from transport-agnostic JSONfrom_http
- handles both structured and binary HTTP; structured will be easy withfrom_json
from sdk-python.
I'm -1 on having a sub-attribute named event
on a CloudEvent. attribute
would be slightly better, but I don't think nested objects is the way to go.
If we want to do attribute access, they should just be top-level properties, since the name data
is (or should be) treated as reserved from an extension PoV -- it would break JSON encoding to try to add a data
extension).
If you do want to be able to use attribute access instead of map-style access, I think the following should be sufficient:
-
Implement
__getattr__
and__setattr__
, probably as described in this StackOverflow post. -
Figure out how you want to handle iterating over the attributes (special method?). Since CloudEvents requires that all attributes be named following
[a-z0-9]{,20}
, including an_
in the method name should be enough to avoid a collision. Sadly, you may also discover that it's hard to handle an attribute like2cool4school
or1
, so we probably need the__getitem__
version as well.
from sdk-python.
The point on autocomplete is interesting -- I haven't looked much at how to hint that in various editors.
from sdk-python.
I'm also -1 on the event name also hence me saying the naming schema I gave above sounds inconvenient. Top level properties rather than nested objects is definitely preferable although marginally more annoying to implement. I further agree we should keep the getitem overload regardless.
The [a-z0-9] naming schema is an interesting point I was unaware of. I would like to know why the spec permits this anyways, although there are no existing attributes where the first character is a number that I know of.
I also agree the http function handles you described should be separate from the event itself. Perhaps we should break this issue up until several smaller issues.
from sdk-python.
What about just adding properties
for the six known attributes (id,type,specversion,source,time,subject)?
I really like dot access more because of IDE completion and type hinting.
from sdk-python.
Also Java or Go sdk allow dot access on the known attributes.
from sdk-python.
@ace-n also mentions a .get('specversion')
option would suffice as a better accessor.
from sdk-python.
Related Issues (20)
- Drop Python 3.6 support
- Evaluate `cibuildwheels`
- optional pydantic support HOT 7
- `_json_or_string` fails on malformed unicode buffers HOT 2
- Encoded JSON data is not set correctly inside data field HOT 2
- Breaking Changes introduced in version 1.6.0 HOT 3
- Add support for CloudEvents v1.0.2 HOT 1
- Kafka protocol support HOT 4
- nested pydantic cloudevent serialization doesn't work HOT 3
- CloudEvent equality is incorrect on none attributes HOT 4
- Invalid constraint error HOT 2
- Method to_structured can't control NON-ASCII chars HOT 5
- cloudevents.kafka.conversion.from_structured incorrectly handles headers tuple HOT 2
- `cloudevents.kafka.to_binary` checks for a `content-type` attribute, which would not be a valid attribute name HOT 5
- `.json()` unable to serialize datetime elements in `data` payload HOT 3
- Support for pydantic v2 HOT 3
- Support for AMQP 0-9-1 protocol - RabbitMQ HOT 1
- Review SDK maintainers activity as of March 21, 2024 HOT 1
- to_json on a pydantic.CloudEvent does not include extension values HOT 4
- example should be examples in Field()? HOT 2
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 sdk-python.