Re: [Python-ideas] More alternate constructors for builtin type

[Josh Rosenberg]

bytes.ord is a bad name, given the behavior would be the opposite of ord
(ord converts length one str to int, not int to length one str).

PEP467 (currently deferred to 3.9 or later) does have proposals for this
case, either bytes.byte (old proposal:
https://legacy.python.org/dev/peps/pep-0467/#addition-of-explicit-single-byte-constructors
) or bytes.fromord/a top level built-in named bchr in the new version of
the PEP (
https://www.python.org/dev/peps/pep-0467/#addition-of-bchr-function-and-explicit-single-byte-constructors
). So if that's the way we want to go, we could just push forward on
PEP467. It's only a subset of Serhiy's broader proposal, though admittedly
one of the cases where the existing design is unusually weak and
improvements would better fill niches currently occupied by non-obvious
solutions.

On Tue, May 7, 2019 at 12:23 AM Steven D'Aprano  wrote:

> On Tue, May 07, 2019 at 09:54:03AM +1000, Cameron Simpson wrote:
> > On 06May2019 18:47, Antoine Pitrou  wrote:
> [...]
> > >The main constructors for built-in types are used so pervasively that
> > >there is no hope of actually removing such deprecated behavior.
> >
> > I don't find that compelling. I for one would welcome a small suite of
> > unambiguous factories that can't be misused. bytes() can easily be
> > misused by accident, introducing bugs and requiring debug work. I'd be
> > very happy for my own future code to be able to take advantage of hard
> > to misuse constructors.
>
> There is a difference between *adding* new constructor methods, and what
> Antoine is saying: that we cannot realistically remove existing uses of
> the current constructors.
>
> I think that Antoine is right: short of another major 2to3 backwards-
> incompatible version, the benefit of actually removing any of the
> built-in constructor behaviours is too small and the cost is too great.
> So I think removal of existing behaviour should be off the table.
>
> Or at least, taken on a case-by-case basis. Propose a specific API you
> want to remove, and we'll discuss that specific API.
>
>
> As for adding *new* constructors:
>
> > Of course we could all write tiny factories for these modes but (a) we'd
> > all have to write and debug them and (b) they'de all have different
> > spellings and signatures
>
> Probably because everyone will want them to do something different.
>
> We've already seen two different semantics for the same desired
> constructor call:
>
> bytes(10) -> b'10'# like str(), but returning bytes
> bytes(10) -> b'\x0A'  # like ord(), but returning a byte
>
> That suggests a possible pair of constructors:
>
> bytes.from_int(n)  -> equivalent to b'%d' % n
> bytes.ord(n)   -> equivalent to bytes((n,))
>
>
> The proposal in this thread seems to me to be a blanket call to add new
> constructors everywhere, and I don't think that's appropriate. I think
> that each proposed new constructor should live or die on its own merits.
> The two above for bytes seem like simple, obvious APIs that do something
> useful which is otherwise a small pain point. Both are syntactic sugar
> for something otherwise ugly or hard to discover.
>
> I think that, if somebody is willing to do the work (it can't be me,
> sorry) adding two new class methods to bytes for the above two cases
> would be a nett win, and they should be minor enough that it doesn't
> need a PEP.
>
> Thoughts?
>
>
>
> --
> Steven
> ___
> 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] Running average and stdev in the statistics module?

[Steven D'Aprano]

Hi Luca,

I'm the original author of the statistics module, and I'm very 
interested in your idea for calculating running statistics. However 
feature-freeze for 3.8 is not far away (about three weeks) so I think it 
would have to be deferred until 3.9.

But I encourage you to give some thought (either privately, or 
publicly here in this thread) about the features you want to see.



-- 
Steven
___
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] More alternate constructors for builtin type

[Steven D'Aprano]

On Tue, May 07, 2019 at 09:54:03AM +1000, Cameron Simpson wrote:
> On 06May2019 18:47, Antoine Pitrou  wrote:
[...]
> >The main constructors for built-in types are used so pervasively that
> >there is no hope of actually removing such deprecated behavior.
> 
> I don't find that compelling. I for one would welcome a small suite of 
> unambiguous factories that can't be misused. bytes() can easily be 
> misused by accident, introducing bugs and requiring debug work. I'd be 
> very happy for my own future code to be able to take advantage of hard 
> to misuse constructors.

There is a difference between *adding* new constructor methods, and what 
Antoine is saying: that we cannot realistically remove existing uses of 
the current constructors.

I think that Antoine is right: short of another major 2to3 backwards- 
incompatible version, the benefit of actually removing any of the 
built-in constructor behaviours is too small and the cost is too great. 
So I think removal of existing behaviour should be off the table.

Or at least, taken on a case-by-case basis. Propose a specific API you 
want to remove, and we'll discuss that specific API.


As for adding *new* constructors:

> Of course we could all write tiny factories for these modes but (a) we'd 
> all have to write and debug them and (b) they'de all have different 
> spellings and signatures 

Probably because everyone will want them to do something different.

We've already seen two different semantics for the same desired 
constructor call:

bytes(10) -> b'10'# like str(), but returning bytes
bytes(10) -> b'\x0A'  # like ord(), but returning a byte

That suggests a possible pair of constructors:

bytes.from_int(n)  -> equivalent to b'%d' % n
bytes.ord(n)   -> equivalent to bytes((n,))


The proposal in this thread seems to me to be a blanket call to add new 
constructors everywhere, and I don't think that's appropriate. I think 
that each proposed new constructor should live or die on its own merits. 
The two above for bytes seem like simple, obvious APIs that do something 
useful which is otherwise a small pain point. Both are syntactic sugar 
for something otherwise ugly or hard to discover.

I think that, if somebody is willing to do the work (it can't be me, 
sorry) adding two new class methods to bytes for the above two cases 
would be a nett win, and they should be minor enough that it doesn't 
need a PEP.

Thoughts?



-- 
Steven
___
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] More alternate constructors for builtin type

[Cameron Simpson]

On 06May2019 18:47, Antoine Pitrou  wrote:

On Mon, 6 May 2019 19:39:39 +0300
Serge Matveenko  wrote:

On Mon, May 6, 2019 at 7:29 PM Guido van Rossum  wrote:
> On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka  wrote:
>> I do not propose to change the current behavior. I propose to add new
>> named constructors. In most cases default constructors can be used, but
>> in cases when we use type check or different tricks to limit the type of
>> the argument, we could use named constructors.
>>
>> Current named constructors:
>>
>> * dict.fromkeys()
>> * int.from_bytes()
>> * float.fromhex()
>> * bytes.fromhex()
>> * bytearray.fromhex()
>
> Understood. My point is that we won't be able to remove the original 
behavior, so we'd end up with two ways to do it. :-(

With all respect, I disagree. There are ways to evolve Python such as
deprecation policies which proven to be effective. There are ways to
monitor current features adoption on PyPI to see whether it is safe to
remove deprecated things.


The main constructors for built-in types are used so pervasively that
there is no hope of actually removing such deprecated behavior.


I don't find that compelling. I for one would welcome a small suite of 
unambiguous factories that can't be misused. bytes() can easily be 
misused by accident, introducing bugs and requiring debug work. I'd be 
very happy for my own future code to be able to take advantage of hard 
to misuse constructors.


Of course we could all write tiny factories for these modes but (a) we'd 
all have to write and debug them and (b) they'de all have different 
spellings and signatures and (c) everyone else would not have easy 
access to them (yes, PyPI notwithstanding: finding a specific module in 
there can be haphazard) and (d) the bytes type is a natural place to 
have these constructors/factories.


All these arguments apply to the other types too.

Cheers,
Cameron Simpson 
___
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] A proper way to bring real interfaces to Python

[Steven D'Aprano]

On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:

> So, I would like to propose adding a third main object called
> `interface` in addition to `object` and `type` and to use it to define
> interface objects. 

Having read this thread, I think the proposal is complex enough that 
you will need to write a PEP explaining the nature of interfaces, the 
problem with the status quo, and your suggested solution.

I don't think a proof-of-concept class is sufficient.

https://www.python.org/dev/peps/


-- 
Steven
___
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] Open parenthesis in REPL completion

[Steven D'Aprano]

On Fri, Apr 26, 2019 at 11:14:32AM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >But having the opening bracket auto-added is a small satisfaction, and 
> >if you're using the REPL for actual calculations and not just help(), 
> >the benefit probably outweighs the annoyance
> 
> The completer could detect the help( as well and leave out
> the opening paren in that case.

It could, but is that special case special enough to break the rules?

"Why doesn't tab completion work correctly in help? I'm trying to call 
help(builder()) but tab completion doesn't add the opening parenthesis 
to builder..."


-- 
Steven
___
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] Open parenthesis in REPL completion

[Steven D'Aprano]

On Thu, Apr 25, 2019 at 02:42:09PM +0100, Stefano Borini wrote:

> PyCharm adds the parenthesis, but also adds the end parenthesis, so
> the whole use of parentheses is consistent: the user has not to worry
> about them.
> Bash refuses to guess when it's ambiguous, and stops until you fill
> the ambiguous part.

In Python, functions are first-class values, so parentheses or not is 
*always* ambiguous. If I start typing the name of a function, there is 
no way for the REPR to know whether I want to call the function or refer 
to it as an object.

Although it might *guess* that calling a function is more common than 
treating it as a value.


> Right now, the REPL implements a mixed situation where it both assumes
> your usage, and does not help you all the way through. Although we can
> all agree that functions most of the time are invoked, rather than
> used as is.
> IMHO, either the parenthesis should not be added, or two parentheses
> should be added and the cursor placed in the center (I am unsure about
> the details of the REPL implementation, but I guess it's possible) at
> least to have a consistent experience.

How ironic if a request on Python-Ideas to *stop* adding the opening 
parenthesis leads to the REPR adding the closing parenthesis as well.

The more I think about it, the more I suspect the least-worst solution 
will be to make tab-completion configurable, with three options:

- no parentheses
- both parentheses
- only the opening parenthesis (status quo)

and an API to set the behaviour at startup depending on an environment 
variable or a config file.

Anyone want to propose a patch?



-- 
Steven
___
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] More alternate constructors for builtin type

[Steven D'Aprano]

On Mon, May 06, 2019 at 07:39:39PM +0300, Serge Matveenko wrote:

> With all respect, I disagree. There are ways to evolve Python such as
> deprecation policies which proven to be effective. There are ways to
> monitor current features adoption on PyPI to see whether it is safe to
> remove deprecated things.

Monitoring adoption on PyPI tells you absolutely nothing about the 
millions of lines of Python code which is not on PyPI.

Not every Python programmer writes open source software available to the 
public. They are not second-class citizens -- we have a responsibility 
to them too, and that's why we don't break backwards-compatibility 
lightly.


> I'd understand if some feature is not accepted to Python if it is
> kinda bad. What I refuse to accept as a user is that behavior
> considered bad and ready to be improved is preserved through time just
> because it is there already.

Oh, you "refuse to accept" it do you? How nice.

Compared to languages like C that have ISO standards, Python's attitude 
towards removing old features might be seen as recklessly fast. You 
should read this to get another perspective:

https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html


> Please, get me right. I totally agree that this will bring up two ways
> of performing the same thing but we can deprecate one of them, keep
> track of the new way adoption and finally get Python to a better state
> if it is really desired.

Everything you say there is true in principle. That doesn't mean it will 
happen in practice.

For what it's worth, I'm less concerned than Guido is about having two 
ways to get the same result. There's two (or three, or ...) ways to do 
many things in Python and "Only One Way To Do It" has never been part of 
the Zen of Python, it was a put-down from Perl users misrepresenting 
Python's philosophy.

But duplication has costs: more to learn, more decisions to make, more 
code, more tests, more documentation. Duplicated APIs can become bloat, 
and bloat is not free. If a function or method doesn't bring *at least* 
enough benefit to outweigh the costs, then it is harmful.

Code churn is not free. Forcing people to change code that works because 
we felt like breaking it should not be done lightly. Keeping old, 
suboptimal APIs versus forcing code churn is a matter of balance, and 
choosing the right balance is not a black and white decision to make.

None of this is to say that we will never decide to deprecate or remove 
a feature. But it isn't clear that this proposal brings enough benefit 
to justify such deprecations.


-- 
Steven
___
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] Running average and stdev in the statistics module?

[Michael Selik]

I've often wanted a windowing function in itertools. One exists as a recipe
in the docs. If I remember correctly, one reason this was never implemented
is that the most efficient implementation changes depending on the size of
the window.

Use a deque(maxsize=n) for large windows and tuple slicing/concat for tiny
windows. I'm not sure how the tee/zip trick compares.

On Mon, May 6, 2019, 10:11 AM Serge Matveenko  wrote:

> On Sun, May 5, 2019 at 1:08 PM Luca Baldini 
> wrote:
> >
> > Hi here,
> > I wonder if the idea of adding to the statistics module a class to
> > calculate the running statistics (average and standard deviation) of a
> > generic input data stream has ever come up in the past.
> >
> > The basic idea is to do the necessary book-keeping as the data are fed
> > into the accumulator class and to be able to query the average variance
> > of the sequence at any point in time without having to loop over the
> > thing again. The obvious way to do that is well know, and described,
> > e.g., in Knuth TAOCP vol 2, 3rd edition, page 232. FWIW It is something
> > that through the years I have coded myself a myriad of times (e.g., for
> > real-time data processing)---and maybe worth considering for addition to
> > the standard library.
>
> Personally, I would definitely use this in a number of places in the
> real-life code I contribute to.
>
> The problem that I have with this idea is it's not clear how to store
> the data in an accumulator class. What about cases with different
> contexts in asyncio and/or multithreading code?
> I would say it could be useful to allow to pass a storage
> implementation from a user's code to address almost any possible
> scenario. In that case, such an accumulator class doesn't need to be a
> class at all and bother with any intermediate storage. It could be a
> number of module-level functions providing an effective algorythm
> implementation for user to be able to base on.
> ___
> 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] More alternate constructors for builtin type

[Kirill Balunov]

пн, 6 мая 2019 г. в 19:48, Antoine Pitrou :

> On Mon, 6 May 2019 19:39:39 +0300
> Serge Matveenko  wrote:
> > On Mon, May 6, 2019 at 7:29 PM Guido van Rossum 
> wrote:
> > >
> > > On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka 
> wrote:
> > >> I do not propose to change the current behavior. I propose to add new
> > >> named constructors. In most cases default constructors can be used,
> but
> > >> in cases when we use type check or different tricks to limit the type
> of
> > >> the argument, we could use named constructors.
> > >>
> > >> Current named constructors:
> > >>
> > >> * dict.fromkeys()
> > >> * int.from_bytes()
> > >> * float.fromhex()
> > >> * bytes.fromhex()
> > >> * bytearray.fromhex()
> > >
> > >
> > > Understood. My point is that we won't be able to remove the original
> behavior, so we'd end up with two ways to do it. :-(
> >
> > With all respect, I disagree. There are ways to evolve Python such as
> > deprecation policies which proven to be effective. There are ways to
> > monitor current features adoption on PyPI to see whether it is safe to
> > remove deprecated things.
>
> The main constructors for built-in types are used so pervasively that
> there is no hope of actually removing such deprecated behavior.
>
>
Especially `bytes` constructor: `bytes(int)`, it is so convenient and
obvious that in the entire Python standard library it is used only in tests
of its own existence:

'cpython-master/Lib/test/test_bytes.py' on line: 1023'

'cpython-master/Lib/test/test_bytes.py' on line: 1234'.


Currently, `bytes` is the most ambiguous resident in Python 3. It
seems that in the final version (which is very different from the
initial idea), it was created to surprise:

1. Those wishing to take it as a string in Python 2
2. Those who wish to perceive it as an array of integers from 0 to 255.
3. And those who want to see `bytes` as something else...


with kind regards,

-gdg
___
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] Running average and stdev in the statistics module?

[Serge Matveenko]

On Sun, May 5, 2019 at 1:08 PM Luca Baldini  wrote:
>
> Hi here,
> I wonder if the idea of adding to the statistics module a class to
> calculate the running statistics (average and standard deviation) of a
> generic input data stream has ever come up in the past.
>
> The basic idea is to do the necessary book-keeping as the data are fed
> into the accumulator class and to be able to query the average variance
> of the sequence at any point in time without having to loop over the
> thing again. The obvious way to do that is well know, and described,
> e.g., in Knuth TAOCP vol 2, 3rd edition, page 232. FWIW It is something
> that through the years I have coded myself a myriad of times (e.g., for
> real-time data processing)---and maybe worth considering for addition to
> the standard library.

Personally, I would definitely use this in a number of places in the
real-life code I contribute to.

The problem that I have with this idea is it's not clear how to store
the data in an accumulator class. What about cases with different
contexts in asyncio and/or multithreading code?
I would say it could be useful to allow to pass a storage
implementation from a user's code to address almost any possible
scenario. In that case, such an accumulator class doesn't need to be a
class at all and bother with any intermediate storage. It could be a
number of module-level functions providing an effective algorythm
implementation for user to be able to base on.
___
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] More alternate constructors for builtin type

[Serge Matveenko]

On Mon, May 6, 2019 at 7:48 PM Antoine Pitrou  wrote:
>
> On Mon, 6 May 2019 19:39:39 +0300
> Serge Matveenko  wrote:

> > With all respect, I disagree. There are ways to evolve Python such as
> > deprecation policies which proven to be effective. There are ways to
> > monitor current features adoption on PyPI to see whether it is safe to
> > remove deprecated things.
>
> The main constructors for built-in types are used so pervasively that
> there is no hope of actually removing such deprecated behavior.

I have no intention to start a long hypothetical discussion here, really.

There are a lot of things which were broken at some point even despite
2to3 crusade. Not to count: `except` syntax, restriction of `async`
keyword, u-strings forth and back.

Usually, It doesn't matter much why one cannot upgrade the interpreter
to the next version. Often, It just stops working and forces a user to
dig into dependencies mess.

I agree that there is no hope in making a change when there is no
intention to make this change. If this change is needed there are ways
to achieve that. The path could be almost infinite but it surely
cannot be walked if nobody willing to take 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] More alternate constructors for builtin type

[Serge Matveenko]

On Mon, May 6, 2019 at 7:29 PM Guido van Rossum  wrote:
>
> On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka  wrote:
>> I do not propose to change the current behavior. I propose to add new
>> named constructors. In most cases default constructors can be used, but
>> in cases when we use type check or different tricks to limit the type of
>> the argument, we could use named constructors.
>>
>> Current named constructors:
>>
>> * dict.fromkeys()
>> * int.from_bytes()
>> * float.fromhex()
>> * bytes.fromhex()
>> * bytearray.fromhex()
>
>
> Understood. My point is that we won't be able to remove the original 
> behavior, so we'd end up with two ways to do it. :-(

With all respect, I disagree. There are ways to evolve Python such as
deprecation policies which proven to be effective. There are ways to
monitor current features adoption on PyPI to see whether it is safe to
remove deprecated things.

I'd understand if some feature is not accepted to Python if it is
kinda bad. What I refuse to accept as a user is that behavior
considered bad and ready to be improved is preserved through time just
because it is there already.

Please, get me right. I totally agree that this will bring up two ways
of performing the same thing but we can deprecate one of them, keep
track of the new way adoption and finally get Python to a better state
if it is really desired.
___
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] More alternate constructors for builtin type

[Antoine Pitrou]

On Mon, 6 May 2019 19:39:39 +0300
Serge Matveenko  wrote:
> On Mon, May 6, 2019 at 7:29 PM Guido van Rossum  wrote:
> >
> > On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka  
> > wrote:  
> >> I do not propose to change the current behavior. I propose to add new
> >> named constructors. In most cases default constructors can be used, but
> >> in cases when we use type check or different tricks to limit the type of
> >> the argument, we could use named constructors.
> >>
> >> Current named constructors:
> >>
> >> * dict.fromkeys()
> >> * int.from_bytes()
> >> * float.fromhex()
> >> * bytes.fromhex()
> >> * bytearray.fromhex()  
> >
> >
> > Understood. My point is that we won't be able to remove the original 
> > behavior, so we'd end up with two ways to do it. :-(  
> 
> With all respect, I disagree. There are ways to evolve Python such as
> deprecation policies which proven to be effective. There are ways to
> monitor current features adoption on PyPI to see whether it is safe to
> remove deprecated things.

The main constructors for built-in types are used so pervasively that
there is no hope of actually removing such deprecated behavior.

Regards

Antoine.


___
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] More alternate constructors for builtin type

[Guido van Rossum]

On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka 
wrote:

> 06.05.19 17:49, Guido van Rossum пише:
> > 20-25 years ago this might have been a good idea. Unfortunately there's
> > so much code (including well-publicized example code) that I'm not sure
> > it's a good use of anyone's time to try and fix this.
>
> I do not propose to change the current behavior. I propose to add new
> named constructors. In most cases default constructors can be used, but
> in cases when we use type check or different tricks to limit the type of
> the argument, we could use named constructors.
>
> Current named constructors:
>
> * dict.fromkeys()
> * int.from_bytes()
> * float.fromhex()
> * bytes.fromhex()
> * bytearray.fromhex()
>

Understood. My point is that we won't be able to remove the original
behavior, so we'd end up with two ways to do it. :-(

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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] More alternate constructors for builtin type

[Serhiy Storchaka]

06.05.19 17:49, Guido van Rossum пише:
20-25 years ago this might have been a good idea. Unfortunately there's 
so much code (including well-publicized example code) that I'm not sure 
it's a good use of anyone's time to try and fix this.


I do not propose to change the current behavior. I propose to add new 
named constructors. In most cases default constructors can be used, but 
in cases when we use type check or different tricks to limit the type of 
the argument, we could use named constructors.


Current named constructors:

* dict.fromkeys()
* int.from_bytes()
* float.fromhex()
* bytes.fromhex()
* bytearray.fromhex()

___
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] A proper way to bring real interfaces to Python

[Serge Matveenko]

On Mon, May 6, 2019 at 5:33 PM Ivan Levkivskyi  wrote:
>
> On Mon, 6 May 2019 at 03:23, Serge Matveenko  wrote:
>>
>> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
>>  wrote:
>> >
>> > Serge Matveenko writes:
>> >
>> >  > So, I would like to propose adding a third main object called
>> >  > `interface` in addition to `object` and `type` and to use it to define
>> >  > interface objects. Such interfaces could then be used in the class
>> >  > definition in the following way.
>> >
>> > How does this compare to existing technology such as zope.interface?
>> > Why do you want it to behave differently where it does?
>>
>> Also, `strict-interfaces` provides typing annotations support and
>> could be easily be adopted in conjunction with PEP 544.
>
>
> I am not sure why one would need another special base class to enforce 
> checking implementations statically.
> Currently mypy can already enforce implementations of Protocols/ABCs at 
> instantiation time. I can imagine one can just add a flag
> (like --early-implementations) without other changes.

This another special base class is not for static checks. This is
about checks at module execution time and generally as Steven has
pointed out at class creation time. This allows to build interfaces
using dynamic factories for instance and then enforce the
implementation.
I see how mypy, type annotations and protocols are other useful links
in the same chain along with interfaces but I cannot see how mypy is
the replacement for the later.
___
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] More alternate constructors for builtin type

[Josh Rosenberg]

 The other bytes object constructor I often find myself in need of without
being able to remember how to do it is creating a a length 1 bytes object
from a known ordinal. The "obvious":

someordinal = ...
bytes(someordinal)

creates a zeroed bytes of that length, which is clearly wrong. I eventually
remember that wrapping it in a tuple (or list) before passing to the bytes
constructor works, but it's far from intuitive:

bytes((someordinal,))

Unfortunately, the most obvious name for the alternate constructor to fill
this niche is *also* bytes.fromint, which conflicts with Guido's use case.

On Mon, May 6, 2019 at 2:40 PM Guido van Rossum  wrote:

> 20-25 years ago this might have been a good idea. Unfortunately there's so
> much code (including well-publicized example code) that I'm not sure it's a
> good use of anyone's time to try and fix this.
>
> Exception: I am often in need of a constructor for a bytes object from an
> integer using the decimal representation, e.g. bytes.fromint(42) == b"42".
> (Especially when migrating code from Python 2, where I've found a lot of
> str(n) that cannot be translated to bytes(n) but must instead be written as
> b"%d" % n, which is ugly and unintuitive when coming from Python 2.)
>
> On Mon, May 6, 2019 at 2:50 AM Serhiy Storchaka 
> wrote:
>
>> Constructors for builtin types is too overloaded.
>>
>> For example, int constructor:
>>
>> * Converts a number (with truncation) to an integer.
>> * Parses human readable representation of integer from string or
>> bytes-like object. Optional base can be specified. Note that there is an
>> alternate constructor for converting bytes to int using other way:
>> int.frombytes().
>> * Without arguments returns 0.
>>
>> str constructor:
>>
>> * Converts an object to human-readable representation.
>> * Decodes a bytes-like object using the specified encoding.
>> * Without arguments returns an empty string.
>>
>> bytes constructor:
>>
>> * Converts a bytes-like object to a bytes object.
>> * Creates a bytes object from an iterable if integers.
>> * Encodes a string using the specified encoding. The same as str.encode().
>> * Creates a bytes object of the specified length consisting of zeros.
>> Equals to b'\0' * n.
>>
>> dict constructor:
>>
>> * Creates a dict from a mapping.
>> * Creates a dict from an iterable of key-value pairs.
>> * Without arguments returns an empty dict.
>>
>> The problem of supporting many different types of input is that we can
>> get wrong result instead of error, or that we can get error later, far
>> from the place where we handle input.
>>
>> For example, if our function should accept arbitrary bytes-like object,
>> and we call bytes() on the argument because we need the length and
>> indexing, and we pass an integer instead, we will get an unexpected
>> result. If our function expects a number, and we call int() on the
>> argument, we may prefer to get an error if pass a string.
>>
>> I suggest to add limited versions of constructors as named constructors:
>>
>> * int.parse() -- parses string or bytes to integer. I do not know
>> whether separate int.parsestr() and int.parsebytes() are needed. I think
>> round(), math.trunc(), math.floor() and math.ceil() are enough for lossy
>> converting numbers to integers. operator.index() should be used for
>> lossless conversion.
>> * bytes.frombuffer() -- accepts only bytes-like objects.
>> * bytes.fromvalues() -- accepts only an iterable if integers.
>> * dict.frommapping() -- accepts only mapping, but not key-value pairs.
>> Uses __iter__() instead of keys() for iterating keys, and can take an
>> optional iterable of keys. Equals to {k: m[k] for k in m} or {k: m[k]
>> for k in keys}.
>> * dict.fromitems() -- accepts only key-value pairs. Equals to {k: v for
>> k, v in iterable}.
>>
>> ___
>> 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)
> *Pronouns: he/him/his **(why is my pronoun here?)*
> 
> ___
> 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] More alternate constructors for builtin type

[Guido van Rossum]

20-25 years ago this might have been a good idea. Unfortunately there's so
much code (including well-publicized example code) that I'm not sure it's a
good use of anyone's time to try and fix this.

Exception: I am often in need of a constructor for a bytes object from an
integer using the decimal representation, e.g. bytes.fromint(42) == b"42".
(Especially when migrating code from Python 2, where I've found a lot of
str(n) that cannot be translated to bytes(n) but must instead be written as
b"%d" % n, which is ugly and unintuitive when coming from Python 2.)

On Mon, May 6, 2019 at 2:50 AM Serhiy Storchaka  wrote:

> Constructors for builtin types is too overloaded.
>
> For example, int constructor:
>
> * Converts a number (with truncation) to an integer.
> * Parses human readable representation of integer from string or
> bytes-like object. Optional base can be specified. Note that there is an
> alternate constructor for converting bytes to int using other way:
> int.frombytes().
> * Without arguments returns 0.
>
> str constructor:
>
> * Converts an object to human-readable representation.
> * Decodes a bytes-like object using the specified encoding.
> * Without arguments returns an empty string.
>
> bytes constructor:
>
> * Converts a bytes-like object to a bytes object.
> * Creates a bytes object from an iterable if integers.
> * Encodes a string using the specified encoding. The same as str.encode().
> * Creates a bytes object of the specified length consisting of zeros.
> Equals to b'\0' * n.
>
> dict constructor:
>
> * Creates a dict from a mapping.
> * Creates a dict from an iterable of key-value pairs.
> * Without arguments returns an empty dict.
>
> The problem of supporting many different types of input is that we can
> get wrong result instead of error, or that we can get error later, far
> from the place where we handle input.
>
> For example, if our function should accept arbitrary bytes-like object,
> and we call bytes() on the argument because we need the length and
> indexing, and we pass an integer instead, we will get an unexpected
> result. If our function expects a number, and we call int() on the
> argument, we may prefer to get an error if pass a string.
>
> I suggest to add limited versions of constructors as named constructors:
>
> * int.parse() -- parses string or bytes to integer. I do not know
> whether separate int.parsestr() and int.parsebytes() are needed. I think
> round(), math.trunc(), math.floor() and math.ceil() are enough for lossy
> converting numbers to integers. operator.index() should be used for
> lossless conversion.
> * bytes.frombuffer() -- accepts only bytes-like objects.
> * bytes.fromvalues() -- accepts only an iterable if integers.
> * dict.frommapping() -- accepts only mapping, but not key-value pairs.
> Uses __iter__() instead of keys() for iterating keys, and can take an
> optional iterable of keys. Equals to {k: m[k] for k in m} or {k: m[k]
> for k in keys}.
> * dict.fromitems() -- accepts only key-value pairs. Equals to {k: v for
> k, v in iterable}.
>
> ___
> 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)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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] A proper way to bring real interfaces to Python

[Ivan Levkivskyi]

On Mon, 6 May 2019 at 03:23, Serge Matveenko  wrote:

> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
>  wrote:
> >
> > Serge Matveenko writes:
> >
> >  > So, I would like to propose adding a third main object called
> >  > `interface` in addition to `object` and `type` and to use it to define
> >  > interface objects. Such interfaces could then be used in the class
> >  > definition in the following way.
> >
> > How does this compare to existing technology such as zope.interface?
> > Why do you want it to behave differently where it does?
>
> Also, `strict-interfaces` provides typing annotations support and
> could be easily be adopted in conjunction with PEP 544.
>

I am not sure why one would need another special base class to enforce
checking implementations statically.
Currently mypy can already enforce implementations of Protocols/ABCs at
instantiation time. I can imagine one can just add a flag
(like --early-implementations) without other changes.

--
Ivan
___
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] More alternate constructors for builtin type

[Serhiy Storchaka]

Constructors for builtin types is too overloaded.

For example, int constructor:

* Converts a number (with truncation) to an integer.
* Parses human readable representation of integer from string or 
bytes-like object. Optional base can be specified. Note that there is an 
alternate constructor for converting bytes to int using other way: 
int.frombytes().

* Without arguments returns 0.

str constructor:

* Converts an object to human-readable representation.
* Decodes a bytes-like object using the specified encoding.
* Without arguments returns an empty string.

bytes constructor:

* Converts a bytes-like object to a bytes object.
* Creates a bytes object from an iterable if integers.
* Encodes a string using the specified encoding. The same as str.encode().
* Creates a bytes object of the specified length consisting of zeros. 
Equals to b'\0' * n.


dict constructor:

* Creates a dict from a mapping.
* Creates a dict from an iterable of key-value pairs.
* Without arguments returns an empty dict.

The problem of supporting many different types of input is that we can 
get wrong result instead of error, or that we can get error later, far 
from the place where we handle input.


For example, if our function should accept arbitrary bytes-like object, 
and we call bytes() on the argument because we need the length and 
indexing, and we pass an integer instead, we will get an unexpected 
result. If our function expects a number, and we call int() on the 
argument, we may prefer to get an error if pass a string.


I suggest to add limited versions of constructors as named constructors:

* int.parse() -- parses string or bytes to integer. I do not know 
whether separate int.parsestr() and int.parsebytes() are needed. I think 
round(), math.trunc(), math.floor() and math.ceil() are enough for lossy 
converting numbers to integers. operator.index() should be used for 
lossless conversion.

* bytes.frombuffer() -- accepts only bytes-like objects.
* bytes.fromvalues() -- accepts only an iterable if integers.
* dict.frommapping() -- accepts only mapping, but not key-value pairs. 
Uses __iter__() instead of keys() for iterating keys, and can take an 
optional iterable of keys. Equals to {k: m[k] for k in m} or {k: m[k] 
for k in keys}.
* dict.fromitems() -- accepts only key-value pairs. Equals to {k: v for 
k, v in iterable}.


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