Re: [Python-ideas] Add an optional type file for Type Annotation

On Tue, Jun 26, 2018 at 08:59:22PM -0700, 李者璈 wrote: > I'm inspired by TypeScript. > > TypeScript allows people to add **.d.ts* *to annotate ECMAScript's type. So > this can expand the TypeScript's scenes to be used。 I'm sorry, I do not understand what you mean by this. Unless you mean stub

Re: [Python-ideas] random.sample should work better with iterators

[Abe Dillon] > Randomly sampling from some population is often done because the entire > > population is impractically large which is also a motivation for using > > iterators, so it seems natural that one would be able to sample from an > > iterator. A naive implementation could use a heap

[Python-ideas] Add an optional type file for Type Annotation

I'm inspired by TypeScript. TypeScript allows people to add **.d.ts* *to annotate ECMAScript's type. So this can expand the TypeScript's scenes to be used。 So I think can we add an optional mechanism to allow people add the extra file to annotate the existing code. Type Annotation can be used

Re: [Python-ideas] random.sample should work better with iterators

Steven D'Aprano writes: > > I don't know if Python Ideas is the right channel for this, but this seems > > overly constrained. The inability to handle dictionaries is especially > > puzzling. > > Puzzling in what way? Same misconception, I suppose. > If sample() supported dicts, should

Re: [Python-ideas] random.sample should work better with iterators

On Tue, Jun 26, 2018 at 05:36:51PM -0700, Abe Dillon wrote: > The docs on random.sample indicate that it works with iterators: > > > To choose a sample from a range of integers, use a range() > > object as an > > argument. This is

[Python-ideas] random.sample should work better with iterators

The docs on random.sample indicate that it works with iterators: > To choose a sample from a range of integers, use a range() > object as an > argument. This is especially fast and space efficient for sampling from a > large population:

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

On 6/26/18 11:34 AM, Franklin? Lee wrote: > > It is not possible to handle `key` without figuring out if a function > is monotonic (a Turing-complete problem in general) or anti-monotonic > (if that is a real term), so you MUST fall back on full iteration if a > key is provided. > Monotonic (in

Re: [Python-ideas] Allow mutable builtin types (optionally)

Hi Guido, I would like to be sure that the lack of support would not be the result of my inability to sum-up my use case. This is why I gave some links to illustrate -the reason why the behavior was changed a decade ago -that such a possibility was actually needed by other

Re: [Python-ideas] Allow mutable builtin types (optionally)

some literature: https://mail.python.org/pipermail/python-dev/2008-February/077180.html https://mail.python.org/pipermail/python-dev/2008-February/077169.html where it is stated that python C struct type should not be able

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

On Tue, Jun 26, 2018 at 11:34 AM, Franklin? Lee wrote: > On Wed, Jun 20, 2018, 00:05 Serhiy Storchaka wrote: >> >> 19.06.18 22:18, James Edwards пише: >> > I've only recently looked for these special methods, so that in and of >> > itself may be the reason these methods aren't exposed, but I

Re: [Python-ideas] Allow mutable builtin types (optionally)

On Thu, Jun 21, 2018, 12:27 Eloi Gaudry, wrote: > This request didn't have a lot of traction, but I still consider this is > something that would need to be supported > Please be careful about using the word "need" as it comes off as demanding instead of as a suggestion. -Brett (2 lines of

Re: [Python-ideas] Allow mutable builtin types (optionally)

Hey Eloi, I think you need to just give up on this. Nobody here seems to support or understand your use case. At this point you are repeating yourself (again claiming there is no good reason for the prohibition and that it's only a few lines of code to change) and you can be assured that the

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

On Wed, Jun 20, 2018, 00:05 Serhiy Storchaka wrote: > 19.06.18 22:18, James Edwards пише: > > I've only recently looked for these special methods, so that in and of > > itself may be the reason these methods aren't exposed, but I could think > > of objects that may wish to implement __min__ and

Re: [Python-ideas] Allow mutable builtin types (optionally)

the origin of this feature disappearing for built-in types: http://bugs.jython.org/issue1058 ''' object.__set/delattr__ allow modification of built in types, this is known as the Carlo Verre hack: Jython 2.3a0+ (trunk:4630:4631M, Jun 14 2008, 20:07:38) [Java HotSpot(TM) Client VM (Apple

Re: [Python-ideas] datetime.timedelta literals

I found it fun to be able to write minutes(50) alongside with 50 * minutes so I did that : from datetime import date, time, datetime, timedelta class CallableTimedelta(timedelta): def __call__(self, x): return self * x seconds, milliseconds, microseconds, days, hours, minutes,