On Mon, Jul 13, 2020 at 12:03 PM Edwin Zimmerman
wrote:
> I would have interest in it.
>
OK -- I'll see what I can do about pulling it out and putting it on gitHub.
Not sure I'll have the time to clean it up and make a nice package out of
it, but maybe there's some ideas in there worth
On 07/11/2020 09:16 PM, Rob Cliffe via Python-ideas wrote:
My gut feeling (backed by no evidence) is that dealing with the case of zero
iterations is not needed frequently enough to cater for it.
My personal experience is that the case of no iterations is frequent enough,
and a big enough
> On 11/07/2020 06:22, Олег Комлев wrote:
> > ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause
> > instead:
>
> if COND:
> ...
> [elif COND:
> ...]
> [else:
> ...]
>
> This IF-clause like must be immediately after FOR- or WHILE-cycle (only
> comment allowed between).
On Sat, Jul 11, 2020, at 20:15, Greg Ewing wrote:
> The set of callables that can be considered "safe" depends
> on the application, so there can't really be a generic
> "safe" option. If that were possible, it would no doubt
> already exist and be the default.
My main concern is wanting to make
On 2020-07-13 5:12 p.m., Joao S. O. Bueno wrote:
You know you can simply pass functions as parameters, right?
def lock(func, *args):
# ...setup
result = func(*args)
#... teardown
return result.
And then, with 3 more lines you do a decorator out of that
def locked(func):
#
You know you can simply pass functions as parameters, right?
def lock(func, *args):
# ...setup
result = func(*args)
#... teardown
return result.
And then, with 3 more lines you do a decorator out of that
def locked(func):
# <'lock' body as above>
return lock
in the end:
Today I think about lambda in Python and what if we introduce the new syntax:
```python
def lock(*args, closure):
# Do some stuff
closure() # Call closure
# Finish stuff
if __name__ == '__main__':
lock():
# Do some things here is thread safe
```
This feature could be very
On Mon, 13 Jul 2020 at 19:39, Christopher Barker wrote:
>
> On Mon, Jul 13, 2020 at 7:44 AM Guido van Rossum wrote:
>>
>> I think you all should get together and come up with a good implementation,
>
> In any case, a good implementation would be a lot easier to evaluate for
> inclusion.
>
>> Or
I would have interest in it.
--Edwin
I'm no security expert, but we've got a big pile of serialization code that is
kind of like JSON-pickly, but it will only deserialize known objects. it's a
bit of pain to declare what you want to work with, but it seems safer.
I also have a
Is there ANY chance of setting the default reply-to to the list? I know
everyone else thinks that's a bid idea, but I doubt this was actually
intended just for me.
If it was, I apologize for bringing it back on the list.
On Sun, Jul 12, 2020 at 10:12 PM Inada Naoki wrote:
> On Mon, Jul 13,
I'm no security expert, but we've got a big pile of serialization code that
is kind of like JSON-pickly, but it will only deserialize known objects.
it's a bit of pain to declare what you want to work with, but it seems
safer.
I also have a newer system (built on top of dataclasses) that
On Mon, Jul 13, 2020 at 11:15 AM Rob Cliffe
wrote:
> On 13 Jul 2020, at 05:55, Christopher Barker wrote:
>
> In fact, I doubt there are many uses at all for dict.keys() -- most uses
> can jsut use the dict.
>
> But you could use items() instead:
> for name, val in sorted(dict.items()):
>
On Mon, Jul 13, 2020 at 7:44 AM Guido van Rossum wrote:
> I think you all should get together and come up with a good
> implementation,
>
+1
> and then petition Raymond Hettinger.
Is this Raymond's turf? I would think it belongs more in the random module
than itertools, or is that Raymond's
>> I doubt there are many uses at all for dict.keys() -- most uses can
jsut use the dict.
> >
> > I use key() all the time to sort the keys before printing.
> >
> > for name in sorted(dict.key()):
> > print(name, dict[name)
>
> Why not just use sorted(dict)?
Thanks for so nicely making my
On Mon, 13 Jul 2020 at 18:42, Barry Scott wrote:
> On 13 Jul 2020, at 05:55, Christopher Barker wrote:
>
> well, sure, though I have to say that I think that that's an unfortunate
> confusing thing about python dicts. IN fact, I doubt there are many uses at
> all for dict.keys() -- most uses
> On Mon, Jul 13, 2020, 7:53 AM Oscar Benjamin
> wrote:
>>
>> I posted this in the thread about indexing dict items but it seems to
>> have been buried there so I'm starting a new thread.
>>
>> Maybe there could be a function in the random module for making a
>> random choice from an arbitrary
> On 13 Jul 2020, at 05:55, Christopher Barker wrote:
>
> well, sure, though I have to say that I think that that's an unfortunate
> confusing thing about python dicts. IN fact, I doubt there are many uses at
> all for dict.keys() -- most uses can jsut use the dict.
I use key() all the time
Looks like pyro4 (python remote objects) has moved to the serpent library
(as.literal_eval) [1]
> defaults to a safe serializer (serpent
https://pypi.python.org/pypi/serpent ) that supports many Python data types.
> supports different serializers (serpent, json, marshal, msgpack, pickle,
I think you all should get together and come up with a good implementation,
and then petition Raymond Hettinger. Or maybe there is an existing open
source 3rd party project that has code you can copy? I don’t recall if
random has a C accelerator, but if it does, you should come up with C code
as
If we get this function (which I would like), the version with k items
(default 1) is much better. Some iterators cannot be repeated at all, so
not only is it slower to call multiple times if you need k>1, it's
impossible.
On Mon, Jul 13, 2020, 8:37 AM David Mertz wrote:
> This is an
This is an inefficient reservoir sampling. The optimized version does not
need to call a random inclusion switch on every element, but can skip a
geometrically ordered collection of (random) skip lengths to avoid most
random inclusion decisions.
Obviously, all items must be iterated over no
On Mon, Jul 13, 2020 at 8:58 PM Edwin Zimmerman wrote:
>
> On 7/11/2020 11:17 PM, Greg Ewing wrote:
>
> On 12/07/20 1:01 pm, Edwin Zimmerman wrote:
>
> As I see it, the unsafe callables (eval, exec, os.system, etc) are generally
> functions, and safe ones(int, list, dict) are generally classes,
I posted this in the thread about indexing dict items but it seems to
have been buried there so I'm starting a new thread.
Maybe there could be a function in the random module for making a
random choice from an arbitrary (finite) iterable. This implementation
can choose a random element from an
On 7/11/2020 11:17 PM, Greg Ewing wrote:
> On 12/07/20 1:01 pm, Edwin Zimmerman wrote:
>> As I see it, the unsafe callables (eval, exec, os.system, etc) are generally
>> functions, and safe ones(int, list, dict) are generally classes, though
>> there certainly would be exceptions.
>
> Where
24 matches
Mail list logo
