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"
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
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
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
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
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
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
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.
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
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
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
But in `for...else` the `else` call isn't always called, so changing `else`
for `finally` doesn't make sense. What you're suggesting is replacing `else`
with `on_finish` and adding `finally` and `on_break`.
I agree that having `finally` could make the use cases of `else` clearer,
but I am not
19 matches
Mail list logo
