[Python-ideas] Re: Comparison operator support (>= and <=) for type
On Fri, Jun 14, 2019 at 12:39 PM Steven D'Aprano wrote: > and no simple way to talk about *strict* subclass and superclass > relationships without a verbose compound test: > > assert issubclass(parent, child) and child != parent Well, why not go further then and make the following thing to be a strict check? `Parent >> Child` Which is `True` when and only when `Child` is a direct subclass of `Parent`. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TN7EPGDXGS6B4H7XXMYO36HRQYYWTBVC/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A plea for people to please remember to assume good faith
On Thu, May 16, 2019 at 10:41 AM Steven D'Aprano wrote: > - try to assume the author of emails is writing in good faith I have a piece of advice I often give to teams. When you catch yourself in a conversation on a thought like "how can I convince an opponent that I'm right" try first to think "maybe my opponent is right". Surprisingly, this could drastically change your attitude in a conversation and really helps to get to the positive result much more quickly. Just try to help your opponent to convince you instead of trying to convince your opponent:) P.S.: Thanks for the whole message. I respect your ability to treat yourself critically and I really believe this could help other people. ___ 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] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 4:34 AM Steven D'Aprano wrote: > You "see ... no obvious difference" between two functions that live in > completely different modules? > > > > The bottom line is that it is completely normal and not uncommon for > functions to be distinguished by the namespace they are found in. It is > both unreasonable and unnecessary to force objects in different > namespaces to have unique names. There is no need to explain basic things to me. Thank you very much indeed! My point was that in case of `os.symlink` vs `shutil.symlink` it is not obvious how they are different even taking into account their namespaces. In the case `os.remove` vs `list.remove` the difference is obvious as namespaces clearly represent different subjects. On the other hand, it is not that easy to guess the developer intent comparing `os` and `shutil` subjects. Why there are two different implementations? Which one should I use? While I don't need "force" functionality at the moment is it ok to use the one from `os` package or I would need that in the future? Is it worth just stick with the one from `shutil` and forget that `os.symlink` exists at all? ___ 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] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 6:19 AM Steven D'Aprano wrote: > The problem is a lack of a symlink function that safely overwrites an > existing file or symlink. We're just bike-shedding over its spelling > and where it lives: > > - modify os.symlink and give it a "force" parameter > - add a new function into shutils How about introducing `force=False` argument to `pathlib.Path.symlink_to` method? It looks like a good place for this as `pathlib` is actually the place where higher-level things to operate on paths live already and this method already has a different name and a slightly different signature. ___ 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] shutil.symlink to allow non-race replacement of existing link targets
On Mon, May 13, 2019 at 9:24 PM Anders Hovmöller wrote: > > On 13 May 2019, at 19:38, Steven D'Aprano wrote: > >> On Mon, May 13, 2019 at 12:31:08PM +0200, Anders Hovmöller wrote: > >> An optional "overwrite_if_exists=False" flag seems much nicer. > > > > Aside from the argument name being too verbose, that violates the rule > > of thumb "avoid constant bool flags" design principle. > > Verbose is better than cryptic. Having the exact same name as something that > does something else is pretty cryptic. As a regular library user, I see and expect no obvious difference between `os.symlink` and `shutil.symlink`. Probably they should have different names if the behavior is not the same. As a constant Linux user, I'd expect a `symlink` function to do something similar to `ln -s` which also could be used as `ln -sf`. So, something like `symlink(force:bool=False)` looks like an expected and "guessable". Thanks! ___ 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] Path conversion for f-strings
On Mon, May 13, 2019 at 4:44 AM Batuhan Taskaya wrote:
>
> Like repr and string the file system path is used alot and something like
> path!p might be handy.
>
> >>> class MyClass:
> ... def __fspath__(self):
> ... return "/home/batuhan"
> ...
> >>> assert f"{mc!p}" == f"{os.fspath(mc)}"
>
> Also it saves us to unnecessarily import os for only fspath().
Hi! Honestly, I feel a lack of use case context here.
Just to mention, `pathlib.Path` like objects have there `__str__`
implement to return a string representation of the path, i.e.
`str(pathlib.Path("/home/batuhan"))` returns `"/home/batuhan"`
___
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
On Wed, May 8, 2019 at 12:37 PM Chris Angelico wrote:
> When you come to write it up, I hope you can go into some detail about
> what you mean by "a third main object". Currently, the hierarchy is
> reentrant at the apex ("object" is an instance of "type", and "type"
> is a subclass of "object"); where would "interface" fit in? Would it
> be a type? Would it be an object? Will both type and interface be
> subclasses of a BaseType, same as we have with exceptions?
It's a good point. Thanks for that!
___
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
On Tue, May 7, 2019 at 2:45 AM Steven D'Aprano wrote: > > 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'd be happy to do that. Would you like to sponsor such a PEP? ___ 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?
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
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
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] A proper way to bring real interfaces to Python
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] A proper way to bring real interfaces to Python
On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote: > It isn't that I *oppose* moving the checks to class-creation time > instead of instantiation time, but I'd like to hear more about why it is > a problem. This doesn't look like moving checks from one place to another for me. It is basically how I would design interfaces in Python at the current state of the language ability to express this concept. I think it is worth mentioning the following here from the POC implementation README. ``` Design Goals * Be as strict as possible * Fail on import time * Do not mess with object and/or type inheritance * Possibility to integrate in CPython Core * Ability to use "out of the box" regardless support in an interpreter ``` ___ 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
> Another one is that ABCs aren't interfaces at all as they all to have > actual implementations being encapsulated in them. This causes > misunderstandings of the code and strange behaviors like in > `collection.abc` module for instance where there is a lot of > implementation and some methods are just mentioned by name. The code > could be much more clear if there were only interfaces and partial > implementation mixins. I meant `importlib.abc` not `collections.abc` 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
On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote: > > 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. Such interfaces could then be used in the class > > definition in the following way. > > How will that solve the problem? Your `interface` object will still > inherit from both object and type since everything inherits from object > and all types inherit from type. In my realization, `interface` stays aside from the inheritance logic. It has its own tree of inheritance and doesn't participate in MRO of its implementations. This is the key feature and the goal. > > Another problem is that ABC performs checks at the moment an object is > > being instantiated which isn't exactly the way one expects an > > interface to work. > > Isn't it? That's how I expect it to work in Python, and I haven't had > any problems with it so far. Well, you haven't had any problems doesn't mean there are no:) > That's not to say there aren't problems, but you should explain what > they are rather than assume that others have experienced the same issues > you have. Why is the late check a problem? Are you worried about > performance? One of the problems is that ABCs doesn't require a class to implement anything. IF you have only class-methods and never instantiate the class it will be never checked. Another one is that ABCs aren't interfaces at all as they all to have actual implementations being encapsulated in them. This causes misunderstandings of the code and strange behaviors like in `collection.abc` module for instance where there is a lot of implementation and some methods are just mentioned by name. The code could be much more clear if there were only interfaces and partial implementation mixins. Overall, there is no interface implementation in Python at the moment. There is abc module indeed which is just a bunch of legacy hacks from the times when there was no possibility to do it in a better way. Now we have tools in the language to do it better and I think that it's time to rethink this now. > It isn't that I *oppose* moving the checks to class-creation time > instead of instantiation time, but I'd like to hear more about why it is > a problem. The main problem that this is just checks on an instance without any hard connection to method signatures as they defined and without any check on type annotations or ever treating a class definition as a proper type. ___ 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
On Sun, May 5, 2019 at 6:40 AM Ryan Gonzalez wrote: > > Worth maybe noting that this could play interestingly with PEP 484? You're right. It already plays along with type hints in different ways. At the moment it requires an exact match of implementation method signatures with the interface including type annotations. There are some examples in test modules https://github.com/lig/python-interfaces/blob/master/tests/interfaces_test.py ___ 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] A proper way to bring real interfaces to Python
Hi, all! I believe, almost everybody is familiar with the `abc` package. The problem is that the ABC class is not a separate thing from `object`. So, using ABCs often results in complicated inheritance designs and even in the infamous metaclass conflict. Another problem is that ABC performs checks at the moment an object is being instantiated which isn't exactly the way one expects an interface to work. The obvious way would be to enforce the implementation at the moment `type` for that class is created, i.e. on module execution time. I'm aware there was `PEP 245 -- Python Interface Syntax` which was rejected. However, I agree with the idea that the syntax proposed in this PEP wasn't particularly "pythonish". 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. ``` class MyInterfaceA(interface): def foo(): pass class MyInterfaceB(interface): def bar(): pass class Implementation(implements=[MyInterfaceA, MyInterfaceB]): def foo(): pass def bar(): pass ``` As a proof of concept, I've implemented a library which implements the idea and allows to use this approach right out of the box — https://pypi.org/project/strict-interfaces/. I would like to get any feedback for the idea and the library. Thanks to all! ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
