I have wanted this and suggested it before for use with typing.
Defining protocols is obnoxiously verbose for "struct" like data and
keyword
arguments to subscript could help alleviate that.
I often want to write type hint like this:
```
def foo(x: Protocol[id=int, name=str]):
bar(x)
Random832 writes:
> I was asking for the current Unpickler class, which currently has a
> whitelist hook for loading globals,
Callables are globals in this sense. So overriding
Unpickler.find_class will allow you to restrict to specified
callables. It's not clear to me why you would want more
Steven D'Aprano writes:
> But if I'm distributing my code to others, the responsible thing to do
> is to think of the potential security risks about using pickle in my
> app, or library. What if they use it in ways that I didn't foresee, ways
> which *ought to be* safe except for my choice
Michael A. Smith writes:
> It seems to me that obj.encode("json") and str.decode("json"), for example,
> would be a powerful feature,
This idea comes up a lot in various forms. The most popular lately is
an optional __json__ dunder, which really would avoid the complication
of working with cus
Right now in str.format(), we have !s, !r, and !a to allow us to call str(),
repr(), and ascii() respectively on the given expression.
I'm proposing that we add a !p conversion to have pprint.pformat() be called to
convert the given expression to a 'pretty' string.
Calling
```
print(f"My dict:
Re: manylinux wheels in Alpine docker (musl (with glibc optionally also
installed))
"Clarify that pip wheels are incompatible with alpine-based images"
https://github.com/docker-library/docs/issues/904
"Install manylinux wheel although it's not officially supported by the host"
https://github.com
On Wed, Jul 15, 2020, at 21:16, Chris Angelico wrote:
> Are you sure of that? I don't have any examples to hand, but are you
> able to pickle something identified as pkg.module.cls(x)?
This produces find_class('pkg.module', 'cls').
Doing pkg.module.cls.method produces find_class('builtins',
'
On Tue, Jul 14, 2020, at 17:55, Rob Cliffe wrote:
> > What if "instead of a special kind of if clause that can only be placed
> > after a loop", we simply defined these three special expressions [usable in
> > any if/elif statement] to reference special boolean flags that are set
> > after exiti
On Wed, Jul 15, 2020, at 07:40, Steven D'Aprano wrote:
> On Tue, Jul 14, 2020 at 09:47:15PM -0400, Random832 wrote:
>
> > I was asking for the current Unpickler class, which currently has a
> > whitelist hook for loading globals, to be modified to also have a
> > whitelist hook so that an applic
On Thu, Jul 16, 2020 at 11:13 AM Random832 wrote:
>
> On Wed, Jul 15, 2020, at 08:14, Chris Angelico wrote:
> > That's fair, but are you actually guaranteeing that it will never read
> > arbitrary attributes from objects?
>
> First of all, reading an attribute of an object in a pickle requires the
On Wed, Jul 15, 2020, at 08:14, Chris Angelico wrote:
> That's fair, but are you actually guaranteeing that it will never read
> arbitrary attributes from objects?
First of all, reading an attribute of an object in a pickle requires the
getattr function. Even currently, you can substitute your o
On Wed, Jul 15, 2020, at 07:54, Edwin Zimmerman wrote:
> The idea that the pickle module can be made "safe" is magical thinking.
> Pickle's attack surface is just too large and too powerful.
I don't think that makes something *inherently* unsafe, it just makes it
difficult to make it safe. The
I was playing with the codecs module and realized that there's untapped
potential to use them for de/serialization. It's easy enough to register a
codec for some case, but very few objects (I think only strings and bytes
and their stream cousins) have native encode/decode methods.
It seems to me t
On Wed, Jul 15, 2020 at 05:45:05AM +, Steve Barnes wrote:
> Can I suggest that for loops the `else` would be a lot clearer if it
> was spelt `finally` as was done for PEP-0341 for try blocks and that
> we might possibly need one or more `on_…` clauses such as `on_break`
> and `on_finish` I
On Wed, Jul 15, 2020 at 9:37 PM Steven D'Aprano wrote:
>
> On Wed, Jul 15, 2020 at 11:24:17AM +1000, Chris Angelico wrote:
> > So if you're distributing your code, then maybe you don't use pickle.
>
> Sure. What do I use to serialise my complex data structure? I guess I
> could write out the repr
Random832 [mailto:random...@fastmail.com] wrote:
> On Tue, Jul 14, 2020, at 21:24, Chris Angelico wrote:
> > I actively oppose it because it isn't possible. Anything that is safe
> > will not have all of pickle's functionality. A nerfed version of
> > pickle that can only unpickle a tiny handful of
On Tue, Jul 14, 2020 at 09:47:15PM -0400, Random832 wrote:
> I was asking for the current Unpickler class, which currently has a
> whitelist hook for loading globals, to be modified to also have a
> whitelist hook so that an application can provide a function that
> looks at a callable and its
On Wed, Jul 15, 2020 at 11:24:17AM +1000, Chris Angelico wrote:
> It's correct far more often than you might think. There's a LOT of
> code out there where the Python source code has the exact same
> external access permissions as its config files - often because
> there's no access to either.
Um
On Wed, 15 Jul 2020 09:45:06 +1000
Steven D'Aprano wrote:
>
> And that's the risk: can I guarantee that there is no clever scheme by
> which an attacker can fool me into unpickling malicious code? I need to
> be smarter than the attacker, and more imaginative, and to have thought
> as long and
I'm really glad that Олег Комлев has posted this suggestion to the list.
Thank you!
I found myself using this construction, and in December 2019 (that seems a
long time ago) I discussed it face-to-face with Paul Piwek. He found this
highly relevant article
https://stackoverflow.com/questions/99799
The point is that `for-else` reads like "do this for loop ELSE (or but if
you can't loop) do this", i.e. roughly equivalent to this:
> try:
> loop_entered = False
> for loop_entered, elem in enumerate(iterable, start=1):
>pass
> assert loop_entered
> except AssertionError:
>
But `finally` with a `for` loop is redundant since the code can be
placed just after the loop. For `try/except` it's a different situation
since the exception might bubble up, so "normal" code after the `try`
won't be reached.
Also `on_break` doesn't seem really important since that code can be
e
22 matches
Mail list logo
