Hi Antonio,
you may want to have a look at the Alpine images for Python
and this optimized variant:
https://github.com/jfloff/alpine-python
They also come with dev tools installed. Still, they are overall
rather clunky to ship around. On the plus side, you can layer
images in docker, so that app
On Tuesday, 7 April 2020 10:52:36 CEST M.-A. Lemburg wrote:
> Hi Antonio,
>
> you may want to have a look at the Alpine images for Python
> and this optimized variant:
>
> https://github.com/jfloff/alpine-python
>
> They also come with dev tools installed. Still, they are overall
> rather clunky
As the author of one of these third-party libraries, I feel like I can
contribute to this discussion. It can indeed be done very elegantly with
type annotations, and it should for sure be left to the ecosystem.
The only things we need from core Python are good tools for dealing with
run-time type
Would you generate a schema from the type annotations so that other
languages can use the data?
JSON is really not the most efficient data representation for
round-tripping to and from Python. A binary format (or pickle without
arbitrary code execution) would solve for Python object > file > Pytho
On Mon, Apr 6, 2020 at 9:17 PM Greg Ewing
wrote:
>
>
> Something similar could be done in Python using type annotations.
>
sure can -- I've done this wrapping dataclasses -- each object in the
hierarchy knows how to serialize/deserialize itself from JSON -- so there
JSON can be totally standard.
On Tue, Apr 7, 2020 at 11:17 AM Wes Turner wrote:
> Would you generate a schema from the type annotations so that other
> languages can use the data?
>
I haven't done this yet, but it would be pretty cool.
> So, IMHO type annotations are not insufficient and thus redundant and not
elegant.
you
On Apr 7, 2020, at 15:31, Christopher Barker wrote:
>
>> On Tue, Apr 7, 2020 at 11:17 AM Wes Turner wrote:
>
>> Would you generate a schema from the type annotations so that other
>> languages can use the data?
>
> I haven't done this yet, but it would be pretty cool.
This seems like one of
the fact that exception handlers aren't reusable and composable is
really bothering me so I would like to propose something to make them
reusable and composable.
for example, if I have this mess:
def get_property_values(self, prop):
try:
factory = self.get_supported_pro
*That* should read as "are not sufficient".
Stuffing all of those into annotations is going to be cumbersome; resulting
in there being multiple schema definitions to keep synchronized and
validate data according to.
I think generating some amalgamation of JSONLD @context & SHACL and JSON
schema w
On 2020-04-07 10:12 p.m., Soni L. wrote:
the fact that exception handlers aren't reusable and composable is
really bothering me so I would like to propose something to make them
reusable and composable.
for example, if I have this mess:
def get_property_values(self, prop):
try:
On 8/04/20 1:14 pm, Soni L. wrote:
def get_property_values(self, prop):
try:
factory = self.get_supported_properties()[prop]
except KeyError with keyerror_handler;
iterator = factory(self._obj)
try:
first = next(iterator)
Soni L. writes:
> the fact that exception handlers aren't reusable and composable is
> really bothering me so I would like to propose something to make them
> reusable and composable.
>
> for example, if I have this mess:
Looks nice and flat and orderly to me; the semantics are messy, so
BTW, although obviously I don't like the idea much, I think
except BaseException as result with f:
reads better than the original suggestion:
except BaseException with f as result:
in the event this idea gets some takeup.
Steve
___
Python-id
On Apr 7, 2020, at 22:58, Stephen J. Turnbull
wrote:
>
> BTW, although obviously I don't like the idea much, I think
>
>except BaseException as result with f:
>
> reads better than the original suggestion:
>
>except BaseException with f as result:
>
> in the event this idea gets som
14 matches
Mail list logo
