date:20180626

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

2018-06-26 Thread Steven D'Aprano

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 files? Stub files are already supported.

https://www.python.org/dev/peps/pep-0484/
 

> 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 after Python 3.5. but many lib/framework has to 
> be compatible for the Python 3.0-3.4, they can't use annotation.

Function annotations work in Python 3.0 onwards.

Using comments for annotations work for any version of Python:

x = []# type: List[Employee]

This is also discussed in the PEP.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Tim Peters

[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 queue:
> >
> > import heapq
> > import random
> >
> > def stream():
> > while True: yield random.random()
> >
> > def sample(population, size):
> > q = [tuple()]*size
> > for el in zip(stream(), population):
> > if el > q[0]: heapq.heapreplace(q, el)
> > return [el[1] for el in q if el]
>

[Steven D'Aprano]

> Is that an improvement over:

sample(list(itertools.slice(population, size)))


> and if so, please explain.
>
> Different things entirely.  Your spelling is missing sample's required
second argument, and the difference should be clear if it's supplied:

  sample(list(itertools.slice(population, size)). size)

That is, it merely returns some permutation of the _initial_ `size` items
in the iterable.  The rest of the population is ignored.

In Python today, the easiest way to spell Abe's intent is, e.g.,

>>> from heapq import nlargest # or nsmallest - doesn't matter
>>> from random import random
>>> nlargest(4, (i for i in range(10)), key=lambda x: random())
[75260, 45880, 99486, 13478]
>>> nlargest(4, (i for i in range(10)), key=lambda x: random())
[31732, 72288, 26584, 72672]
>>> nlargest(4, (i for i in range(10)), key=lambda x: random())
[14180, 86084, 22639, 2004]

That also arranges to preserve `sample()'s promise that all sub-slices of
the result are valid random samples too (because `nlargest` sorts by the
randomly generated keys before returning the list).

However, it does _not_ preserve - and nothing can preserve for arbitrary
iterables - `sample()`'s promise to "[leave] the original population
unchanged".  We can't examine an arbitrary iterable's population at all
without exhausting the iterable, and that can be destructive.

So while this can indeed be useful, it would require changing `sample()` to
break that promise in some cases.

BTW, using a heap for this is uncommon.  Search on "reservoir sampling" for
more-common ways   Most common is probably Vitter's "Algorithm R", which
runs in O(len(iterable)) time (no additional log factor for a heap - it
doesn't use a heap).

I'd prefer to leave `sample()` alone, and introduce some spelling of
`possibly_destructive_sample()` for arbitrary iterables - if that's wanted
enough for someone to do the work ;-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread 李者璈

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 after Python 3.5. but many lib/framework has to 
be compatible for the Python 3.0-3.4, they can't use annotation.

If we have this mechanism, the lib/framework can continue to focus on the 
function, and the third group can add the extra type annotation for 
lib/framework

I think it should be OK

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Stephen J. Turnbull

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 it return the keys or the values or 
 > both?

I argue below that *if* we were going to make the change, it should be
to consistently try list() on non-sequences.  But "not every
one-liner" and EIBTI:

d = {'a': 1, 'b': 2}

>>> sample(d.keys(),1)
['a']
>>> sample(d.items(),1)
[('a', 1)]

But this is weird:

>>> sample(d.values(),1)
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/random.py",
 line 314, in sample
raise TypeError("Population must be a sequence or set.  For dicts, use 
list(d).")
TypeError: Population must be a sequence or set.  For dicts, use list(d).

Oh, I see.  Key views are "set-like", item views *may* be set-like,
but value views are *not* set-like.

Since views are all listable, why not try "list" on them?  In general,
I would think it makes sense to define this as "Population must be a
sequence or convertible to a sequence using list()."  And for most of
the applications I can think of in my own use, sample(list(d)) is not
particularly useful because it's a sample of keys.  I usually want
sample(list(d.values())).

The ramifications are unclear to me, but I guess it's too late to
change this because of the efficiency implications Tim describes in
issue33098 (so EIBTI; thanks for the reference!)  On the other hand,
that issue says sets can't be sampled efficiently, so the current
behavior seems to *promote* inefficient usage?

I would definitely change the error message.  I think "Use list(d)" is
bad advice because I believe it's not even "almost always" what you'll
want, and if keys and values are of the same type, it won't be obvious
from the output that you're *not* getting a sample from d.values() if
that's what you wanted and thought you were getting.

 > Don't let the source speak for itself. Explain what it means. I 
 > understand what sample(population, size=100) does. What would 
 > sample(population, ratio=0.25) do?

I assume sample(pop, ratio=0.25) == sample(pop, size=0.25*len(pop)).

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Steven D'Aprano

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 especially fast and space efficient for sampling from a 
> > large population: sample(range(1000),k=60).

That doesn't mention anything about iterators.


> However, when I try to use iterators other than range, like so:

range is not an iterator.

Thinking it is is a very common error, but it certainly is not. It is a 
lazily-generated *sequence*, not an iterator.

The definition of an iterator is that the object must have an __iter__ 
method returning *itself*, and a __next__ method (the "iterator 
protocol"):

py> obj = range(100)
py> hasattr(obj, '__next__')
False
py> obj.__iter__() is obj
False

However, it is a sequence:

py> import collections
py> isinstance(obj, collections.Sequence)
True

(Aside: I'm surprised there's no inspect.isiterator and .isiterable 
functions.)


> random.sample(itertools.product(range(height), range(with)), 
> 0.5*height*width)
> 
> I get:
> 
> TypeError: Population must be a sequence or set. For dicts, use list(d).
> 
> 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?

If sample() supported dicts, should it return the keys or the values or 
both? Also consider this:

https://bugs.python.org/issue33098



> 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 queue: 
>
> import heapq
> import random
> 
> def stream(): 
> while True: yield random.random()
> 
> def sample(population, size):
> q = [tuple()]*size
> for el in zip(stream(), population):
> if el > q[0]: heapq.heapreplace(q, el)
> return [el[1] for el in q if el]

Is that an improvement over:

sample(list(itertools.slice(population, size)))

and if so, please explain.


 
> It would also be helpful to add a ratio version of the function: 
> 
> def sample(population, size=None, *, ratio=None):
> assert None in (size, ratio), "can't specify both sample size and ratio"
> if ratio:
> return [el for el in population if random.random() < ratio]
> ...

Helpful under what circumstances?

Don't let the source speak for itself. Explain what it means. I 
understand what sample(population, size=100) does. What would 
sample(population, ratio=0.25) do?

(That's not a rhetorical question, I genuinely don't understand the 
semantics of this proposed ratio argument.)



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Abe Dillon

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: sample(range(1000),k=60).


However, when I try to use iterators other than range, like so:

random.sample(itertools.product(range(height), range(with)), 
0.5*height*width)

I get:

TypeError: Population must be a sequence or set. For dicts, use list(d).

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.
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 queue: 
import heapq
import random

def stream(): 
while True: yield random.random()

def sample(population, size):
q = [tuple()]*size
for el in zip(stream(), population):
if el > q[0]: heapq.heapreplace(q, el)
return [el[1] for el in q if el]

It would also be helpful to add a ratio version of the function: 

def sample(population, size=None, *, ratio=None):
assert None in (size, ratio), "can't specify both sample size and ratio"
if ratio:
return [el for el in population if random.random() < ratio]
...


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Exposing" `min` and `max`

2018-06-26 Thread Richard Damon

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 this sense) just means never changing directions, it can
be increasing and never decreasing or decreasing and never increasing so
we don't need the 'anti-' version.

-- 
Richard Damon

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Eloi Gaudry

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 extension 
developers (where their built-in types would benefit from being able to 
redefine some method dynamically)

-that python core developers and python extension developers can have 
different needs and objectives (which was the main reason why I was submitting 
this to the mailing-list again)

I feel sorry if that only resulted in looking like I was repeating myself.

Have a good day,
Eloi

From: Guido van Rossum 
Sent: Tuesday, June 26, 2018 7:20 PM
To: Eloi Gaudry 
Cc: Python-Ideas ; Serhiy Storchaka 

Subject: 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 response will also be 
the same.

--Guido

On Tue, Jun 26, 2018 at 8:00 AM Eloi Gaudry 
mailto:eloi.gau...@fft.be>> wrote:

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 Inc.)] on java1.5.0_13
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__setattr__(str, 'lower', str.upper)
>>> 'dammit Carlo!'.lower()
'DAMMIT CARLO!'
'''

but I do not see any reason why having an explicit flag for python extensions 
written in C to declare their types as static struct, and still be able to 
change their __setattr__, __getattr__, etc. slots would not make sense.

extensions and core types have not the same constraints and purposes, this 
should be reflected on the capabilities the first would have somewhere then.

From: Eloi Gaudry
Sent: Tuesday, June 26, 2018 4:27:18 PM
To: python-ideas@python.org
Subject: 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 to have their 
attributes changed.

but the extension needs is clearly not taken into account.

From: Python-ideas 
mailto:fft...@python.org>> 
on behalf of Eloi Gaudry mailto:eloi.gau...@fft.be>>
Sent: Thursday, June 21, 2018 5:26:37 PM
To: python-ideas@python.org; 
encu...@gmail.com
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

This request didn't have a lot of traction, but I still consider this is 
something that would need to be supported (2 lines of code to be changed; no 
regression so far with python 2 and python 3).

My main points are:

- HEAP_TYPE is not really used (as anyone being using it ?)

- HEAP_TYPE serves other purposes

- extension would benefit for allowing direct access to any of its type 
attributes

Petr, what do you think ?

Eloi

From: Python-ideas 
mailto:fft...@python.org>> 
on behalf of Eloi Gaudry mailto:eloi.gau...@fft.be>>
Sent: Tuesday, May 8, 2018 9:26:47 AM
To: encu...@gmail.com; 
python-ideas@python.org
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote:
> On 05/07/18 11:37, Eloi Gaudry wrote:
> > I mean, to my knowledge, there is no reason why a type should be
> > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html
> > ) to
> > be able to change its attributes at Python level.
>
> One reason is sub-interpreter support: you can have multiple
> interpreters per process, and those shouldn't influence each other.
> (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor
> t)
>
> With heap types, each sub-interpreter can have its own copy of the
> type
> object. But with builtins, changes done in one interpreter would be
> visible in all the others.

Yes, this could be a reason, but if you don't rely on such a feature
neither implicitly nor explicitly ?

I mean, our types are built-in and should be considered as immutable
across interpreters. And we (as most users I guess) are only running
one interpreter.

In case several intepreters are used, it would make sense to have a
non-heap type that would be seen as a singleton across all of them, no
?

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

2018-06-26 Thread Eloi Gaudry

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 to have their 
attributes changed.

but the extension needs is clearly not taken into account.

From: Python-ideas  on 
behalf of Eloi Gaudry 
Sent: Thursday, June 21, 2018 5:26:37 PM
To: python-ideas@python.org; encu...@gmail.com
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

This request didn't have a lot of traction, but I still consider this is 
something that would need to be supported (2 lines of code to be changed; no 
regression so far with python 2 and python 3).

My main points are:

- HEAP_TYPE is not really used (as anyone being using it ?)

- HEAP_TYPE serves other purposes

- extension would benefit for allowing direct access to any of its type 
attributes

Petr, what do you think ?

Eloi

From: Python-ideas  on 
behalf of Eloi Gaudry 
Sent: Tuesday, May 8, 2018 9:26:47 AM
To: encu...@gmail.com; python-ideas@python.org
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote:
> On 05/07/18 11:37, Eloi Gaudry wrote:
> > I mean, to my knowledge, there is no reason why a type should be
> > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html
> > ) to
> > be able to change its attributes at Python level.
>
> One reason is sub-interpreter support: you can have multiple
> interpreters per process, and those shouldn't influence each other.
> (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor
> t)
>
> With heap types, each sub-interpreter can have its own copy of the
> type
> object. But with builtins, changes done in one interpreter would be
> visible in all the others.

Yes, this could be a reason, but if you don't rely on such a feature
neither implicitly nor explicitly ?

I mean, our types are built-in and should be considered as immutable
across interpreters. And we (as most users I guess) are only running
one interpreter.

In case several intepreters are used, it would make sense to have a
non-heap type that would be seen as a singleton across all of them, no
?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Exposing" `min` and `max`

2018-06-26 Thread Franklin? Lee

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 could think
>> > of objects that may wish to implement __min__ and __max__ themselves,
>> > for efficiency.
>>
>> There are two questions.
>>
>> 1. What to do with additional min() and max() arguments: key and default.
>
>
> Neither should be passed to a dunder.
>
> 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.
>
> `default` is only used in case of an empty collection. The only question is,
> who has responsibility for detecting an empty collection, and how?
>
> Caller detects: The caller checks length before calling the dunder. If there
> is no dunder, it doesn't check. Are there real-world cases where length is
> not defined on an iterable collection?
>
> Dunder detects: Right now, `max` detects empty by watching for
> StopIteration, which can no longer be a false positive. StopIterations from
> a deeper scope are wrapped. If the dunder throws an error to signal
> emptiness, it should not be thrown otherwise. I think that's impossible to
> guarantee.

There's an argument that you DO want to pass to the dunder:
`last=True`. It's not currently part of `min` and `max`.

Currently, if there are multiple items that are maximum, `max` will
return the first one. In the future, a `last:bool` param could be
added, and a dunder for `max` will want to handle it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Brett Cannon

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 code to be changed; no regression so far with python 2 and
> python 3).
>
>
> My main points are:
>
> - HEAP_TYPE is not really used (as anyone being using it ?)
>
> - HEAP_TYPE serves other purposes
>
> - extension would benefit for allowing direct access to any of its
> type attributes
>


> Petr, what do you think ?
>
> Eloi
> --
> *From:* Python-ideas 
> on behalf of Eloi Gaudry 
> *Sent:* Tuesday, May 8, 2018 9:26:47 AM
> *To:* encu...@gmail.com; python-ideas@python.org
> *Subject:* Re: [Python-ideas] Allow mutable builtin types (optionally)
>
> On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote:
> > On 05/07/18 11:37, Eloi Gaudry wrote:
> > > I mean, to my knowledge, there is no reason why a type should be
> > > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html
> > > ) to
> > > be able to change its attributes at Python level.
> >
> > One reason is sub-interpreter support: you can have multiple
> > interpreters per process, and those shouldn't influence each other.
> > (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor
> > t)
> >
> > With heap types, each sub-interpreter can have its own copy of the
> > type
> > object. But with builtins, changes done in one interpreter would be
> > visible in all the others.
>
> Yes, this could be a reason, but if you don't rely on such a feature
> neither implicitly nor explicitly ?
>
> I mean, our types are built-in and should be considered as immutable
> across interpreters. And we (as most users I guess) are only running
> one interpreter.
>
> In case several intepreters are used, it would make sense to have a
> non-heap type that would be seen as a singleton across all of them, no
> ?
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Guido van Rossum

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 response will
also be the same.

--Guido

On Tue, Jun 26, 2018 at 8:00 AM Eloi Gaudry  wrote:

> 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 Inc.)] on java1.5.0_13
> Type "help", "copyright", "credits" or "license" for more information.
> >>> object.__setattr__(str, 'lower', str.upper)
> >>> 'dammit Carlo!'.lower()
> 'DAMMIT CARLO!'
> '''
>
> but I do not see any reason why having an explicit flag for
> python extensions written in C to declare their types as static struct, and
> still be able to change their __setattr__, __getattr__, etc. slots would
> not make sense.
>
> extensions and core types have not the same constraints and purposes, this
> should be reflected on the capabilities the first would have somewhere then.
>
>
>
>
> --
> *From:* Eloi Gaudry
> *Sent:* Tuesday, June 26, 2018 4:27:18 PM
> *To:* python-ideas@python.org
> *Subject:* 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 to have
> their attributes changed.
>
> but the extension needs is clearly not taken into account.
>
> --
> *From:* Python-ideas 
> on behalf of Eloi Gaudry 
> *Sent:* Thursday, June 21, 2018 5:26:37 PM
> *To:* python-ideas@python.org; encu...@gmail.com
> *Subject:* Re: [Python-ideas] Allow mutable builtin types (optionally)
>
>
> This request didn't have a lot of traction, but I still consider this is
> something that would need to be supported (2 lines of code to be changed;
> no regression so far with python 2 and python 3).
>
>
> My main points are:
>
> - HEAP_TYPE is not really used (as anyone being using it ?)
>
> - HEAP_TYPE serves other purposes
>
> - extension would benefit for allowing direct access to any of its
> type attributes
>
>
> Petr, what do you think ?
>
> Eloi
> --
> *From:* Python-ideas 
> on behalf of Eloi Gaudry 
> *Sent:* Tuesday, May 8, 2018 9:26:47 AM
> *To:* encu...@gmail.com; python-ideas@python.org
> *Subject:* Re: [Python-ideas] Allow mutable builtin types (optionally)
>
> On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote:
> > On 05/07/18 11:37, Eloi Gaudry wrote:
> > > I mean, to my knowledge, there is no reason why a type should be
> > > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html
> > > ) to
> > > be able to change its attributes at Python level.
> >
> > One reason is sub-interpreter support: you can have multiple
> > interpreters per process, and those shouldn't influence each other.
> > (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor
> > t)
> >
> > With heap types, each sub-interpreter can have its own copy of the
> > type
> > object. But with builtins, changes done in one interpreter would be
> > visible in all the others.
>
> Yes, this could be a reason, but if you don't rely on such a feature
> neither implicitly nor explicitly ?
>
> I mean, our types are built-in and should be considered as immutable
> across interpreters. And we (as most users I guess) are only running
> one interpreter.
>
> In case several intepreters are used, it would make sense to have a
> non-heap type that would be seen as a singleton across all of them, no
> ?
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Exposing" `min` and `max`

2018-06-26 Thread Franklin? Lee

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 __max__ themselves,
> > for efficiency.
>
> There are two questions.
>
> 1. What to do with additional min() and max() arguments: key and default.
>

Neither should be passed to a dunder.

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.

`default` is only used in case of an empty collection. The only question
is, who has responsibility for detecting an empty collection, and how?

Caller detects: The caller checks length before calling the dunder. If
there is no dunder, it doesn't check. Are there real-world cases where
length is not defined on an iterable collection?

Dunder detects: Right now, `max` detects empty by watching for
StopIteration, which can no longer be a false positive. StopIterations from
a deeper scope are wrapped. If the dunder throws an error to signal
emptiness, it should not be thrown otherwise. I think that's impossible to
guarantee.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

2018-06-26 Thread Eloi Gaudry

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 Inc.)] on java1.5.0_13
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__setattr__(str, 'lower', str.upper)
>>> 'dammit Carlo!'.lower()
'DAMMIT CARLO!'
'''

but I do not see any reason why having an explicit flag for python extensions 
written in C to declare their types as static struct, and still be able to 
change their __setattr__, __getattr__, etc. slots would not make sense.

extensions and core types have not the same constraints and purposes, this 
should be reflected on the capabilities the first would have somewhere then.

From: Eloi Gaudry
Sent: Tuesday, June 26, 2018 4:27:18 PM
To: python-ideas@python.org
Subject: 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 to have their 
attributes changed.

but the extension needs is clearly not taken into account.

From: Python-ideas  on 
behalf of Eloi Gaudry 
Sent: Thursday, June 21, 2018 5:26:37 PM
To: python-ideas@python.org; encu...@gmail.com
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

This request didn't have a lot of traction, but I still consider this is 
something that would need to be supported (2 lines of code to be changed; no 
regression so far with python 2 and python 3).

My main points are:

- HEAP_TYPE is not really used (as anyone being using it ?)

- HEAP_TYPE serves other purposes

- extension would benefit for allowing direct access to any of its type 
attributes

Petr, what do you think ?

Eloi

From: Python-ideas  on 
behalf of Eloi Gaudry 
Sent: Tuesday, May 8, 2018 9:26:47 AM
To: encu...@gmail.com; python-ideas@python.org
Subject: Re: [Python-ideas] Allow mutable builtin types (optionally)

On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote:
> On 05/07/18 11:37, Eloi Gaudry wrote:
> > I mean, to my knowledge, there is no reason why a type should be
> > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html
> > ) to
> > be able to change its attributes at Python level.
>
> One reason is sub-interpreter support: you can have multiple
> interpreters per process, and those shouldn't influence each other.
> (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor
> t)
>
> With heap types, each sub-interpreter can have its own copy of the
> type
> object. But with builtins, changes done in one interpreter would be
> visible in all the others.

Yes, this could be a reason, but if you don't rely on such a feature
neither implicitly nor explicitly ?

I mean, our types are built-in and should be considered as immutable
across interpreters. And we (as most users I guess) are only running
one interpreter.

In case several intepreters are used, it would make sense to have a
non-heap type that would be seen as a singleton across all of them, no
?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] datetime.timedelta literals

2018-06-26 Thread Robert Vanden Eynde

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, weeks = 
(CallableTimedelta(**{x:1}) for x in ('seconds', 'milliseconds', 
'microseconds', 'days', 'hours', 'minutes', 'weeks'))

print(minutes(50) / seconds) # 3000.0
print(50 * minutes / seconds) # 3000.0
print(minutes(50).total_seconds()) # 3000.0




2018-06-07 13:34 GMT+02:00 Pål Grønås Drange 
mailto:paal.dra...@gmail.com>>:

For closure, I've added a package, timeliterals

(env) [pgdr@hostname ~]$ pip install timeliterals
(env) [pgdr@hostname ~]$ python
>>> from timeliterals import *
>>> 3*hours
datetime.timedelta(0, 10800)
>>> 3*minutes
datetime.timedelta(0, 180)
>>> 3*seconds
datetime.timedelta(0, 3)

The source code is at https://github.com/pgdr/timeliterals

I'm not going to submit a patch to datetime at this time, but I will if people
would be interested.

- Pål

On 5 Jun 2018 13:56, "Jacco van Dorp" 
mailto:j.van.d...@deonet.nl>> wrote:
i'd also be pretty simple to implement

Just list:
minute = timedelta(minutes=1)
hour = timedelta(hours=1)
etc...

and you could import and use them like that. Or if you really want to
write 5*m, the just from datetime import minute as m
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

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

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

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

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

Re: [Python-ideas] "Exposing" `min` and `max`

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

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

Re: [Python-ideas] "Exposing" `min` and `max`

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

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

Re: [Python-ideas] "Exposing" `min` and `max`

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

Re: [Python-ideas] datetime.timedelta literals

15 matches

Site Navigation

Mail list logo

Footer information