[Python-ideas] Re: Generalized deferred computation in Python

[Neil Girdhar]

Could this idea be used to specify the default factory of a dataclass 
field?  For example,

@dataclass
class X:
  x: list[int] = deferred []

instead of

@dataclass
class X:
  x: list[int] = field(default_factory=list)

If so, it might be worth adding to your proposal as another common 
motivating example?

Best,

Neil

On Wednesday, June 22, 2022 at 2:23:13 PM UTC-4 David Mertz, Ph.D. wrote:

> On Wed, Jun 22, 2022 at 10:47 AM Martin Di Paola  
> wrote:
>
>> Hi David, I read the PEP and I think it would be useful to expand the
>> Motivation and Examples sections.
>> While indeed Dask uses lazy evaluation to build a complex computation
>> without executing it, I don't think that it is the whole story.
>> Dask takes this deferred complex computation and *plans* how to execute it
>> and then it *executes* it in non-obvious/direct ways.
>>
>
> Dask is very clever about execution planning.  Ray is possibly even more 
> clever in that regard.
>
> However, I think that that should be an explicit non-goal of the PEP.  
> DeferredObjects should create a DAG, yes.  But I think Python itself should 
> not think about being *clever* in evaluating that DAG, nor in itself think 
> about parallelism.  If my PEP were adopted, that would be something other 
> libraries like Dask or Django could build on top of with more elaborate 
> evaluation plans.
>
> But just the DAG itself gets you more than just "wait until needed to do 
> the final computation." It allows for intermediate computation of nodes of 
> the DAG lower down than the final result.  For example, imagine 
> dependencies like this (where all the computation steps are expensive):
>
> A -> B
>  B -> Z
>  B -> Y
>  B -> X
> A -> C
>  C -> X
>   X -> F
>   X -> G
>  C -> W
>  C -> V
> A -> D
>  D -> V
>  D -> U
>  D -> T
>  
> Hopefully you either see my ASCII art in fixed font, or it's at least 
> intelligible.  If I want to force evaluation of A, I need to do 
> everything.  But if it turns out all I need within my program is C, then I 
> have to do computations C, X, F, G, W, V.  Which is maybe still expensive, 
> but at least I don't worry about B, Z, Y, U, T, or A.
>
> Yes, I should add something like this to the PEP.
>
>
>___
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/US5MCILKVRPUQBUERK352JKTH7RNJMTJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Would it be desirable to save the state of functools.cache?

[Neil Girdhar]

Would it be desirable to save the state of functools.cache between program 
executions?  For example, by providing cache_state property on the cache 
that is pickle-able.___
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/C6ZD3N5NP2VVR73SVDOV6NTTZLIO3AJX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Please consider making dataclasses define an empty __post_init__

[Neil Girdhar]

This was discussed here: https://bugs.python.org/issue46757

This came up because I had a dataclass subclass to flax.linen.Module that 
had its own post-init.  When I figured out that I needed to call super, I 
did so.   Later, when I refactored my code to remove the superclass, the 
super-call was broken.

It have been much simpler to always call super in __post_init__ from the 
start.  The proposal on the bug report was to get in the habit of doing:

if hasattr(super(), "__post_init__"): super().__post_init__() or: try: 
post_init = super().__post_init__ except AttributeError: pass else: 
post_init()

I think it will be difficult to convince projects to do this.

Best,

Neil
___
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/B77X2LJVQ4LEWEYL72AJSYQWKTYCII6A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set

[Neil Girdhar]

I humbly disagree that any of what you wrote is "obvious".

On Fri, Feb 11, 2022 at 4:41 AM Steven D'Aprano  wrote:

> On Thu, Feb 10, 2022 at 02:27:42PM -0800, Neil Girdhar wrote:
>
> > AttributeError: can't set attribute 'f'
> >
> > This can be a pain to debug when the property is buried in a base class.
>
> > Would it make sense to mention the reason why the attribute can't be
> set,
> > namely that it's on a property without a setter?
>
> I have no objection to changing the error message, I'm sure it's a small
> enough change that you should just open a ticket on b.p.o. for it. But I
> don't expect that it will be particularly useful either.
>
> If you can't set an attribute on an object, aren't there three obvious
> causes to check?
>
> - the object has no __dict__, and so has no attributes at all;
>   e.g. trying to set an attribute on a float;
>
> - the object has slots, but 'f' is not one of them;
>
> - or 'f' is a property with no setter (or a setter that raises
>   AttributeError).
>
> Have I missed any common cases?
>
> The error messages are different in each case, but even if they were the
> same, there are three obvious causes to check, and property is one of
> them.
>
> I suppose that there are exotic failures that could happen in
> __getattribute__ or weird descriptors, or metaclass magic, etc, and
> *those* might be hard to debug, but it doesn't seem likely to me that a
> read-only property will be mysterious.
>
> Especially if you have the object available in the interactive
> interpreter, so you can inspect it with the various tools available:
>
> * dir(obj)
> * help(obj)
> * type(obj).f  # Will display 
>
> etc. Its hard to keep the existence of a property secret in Python.
>
> So once you know that f is a property, it might be hard to work out
> which of the fifty-seven superclasses and mixins it came from *wink* but
> that's neither here nor there :-)
>
> Maybe reporting "can't set property 'f'" is good enough.
>
>
> --
> Steve
> ___
> 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/Z2AWWETWB72CKARR4DAHB3A2LFRLQR7X/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/IMzPQhK64lw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python-ideas/20220211093720.GO16660%40ando.pearwood.info
> .
>
___
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/UW3D64ROFVSOEW6G6B3JTMB67ERRWW5D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Please consider mentioning property without setter when an attribute can't be set

[Neil Girdhar]

Hello,  consider:

class C:
@property
def f(self) -> int:
return 2

class D(C):
pass

D().f = 2

Gives:

Traceback (most recent call last):
  File "/home/neil/src/cmm/a.py", line 10, in 
D().f = 2
AttributeError: can't set attribute 'f'

This can be a pain to debug when the property is buried in a base class.  
Would it make sense to mention the reason why the attribute can't be set, 
namely that it's on a property without a setter?

Best,

Neil
___
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/NG3LNNF4LLDUOZS5UQS53HESWRIHHGXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Consider moving abstract method checking logic from ABCMeta into object

[Neil Girdhar]

On Tue, Feb 8, 2022 at 5:50 AM Paul Moore  wrote:

> On Tue, 8 Feb 2022 at 00:09, Neil Girdhar  wrote:
> >
> > Currently, some type checkers rightly complain that a method is
> decorated with abc.abstractmethod when the class's type does not inherit
> from ABCMeta.  Adding a metaclass is a fairly heavy dependency since you're
> forced to poison all of your other metaclasses with the same base
> metaclass.  It also brings in possibly unwanted type registration that ABC
> comes with.
> >
> > Now that abstractmethod's usage is extremely well-understood, would it
> make sense to move the checking logic out of ABCMeta?
> >
> > It could either be put into object so that no base class is necessary
> (at the cost of slightly slower class creation), or else in a non-meta base
> class (say, HasAbstractMethods) now that __init_subclass__ is in all extant
> versions of Python.  Inheriting from such a non-meta base class would avoid
> the poisoning problem described above.
> >
> > As far as I can tell, neither solution breaks code.
>
> If it's valid usage, why not just get the type checkers fixed?


I don't think that the type checkers need to be fixed.

Or if,
> as you say, the type checkers are complaining correctly, why do you
> want to do it?
>
The main motivation is that adding a metaclass is a fairly heavy dependency
since you're forced to poison all of your other metaclasses with the same
base metaclass.  It also brings in possibly unwanted type registration that
ABC comes with.

Also, I can't prevent the type checker warnings and it takes weeks to
submit pull requests and convince projects I use to add the base class and
explain the error.  It would save everyone time if these errors didn't
happen in the first place.

So, pulling this functionality into object would just eliminate the whole
problem, and as far as I can tell doesn't cause any?  It also lowers the
bar for usage of abc.abstractmethod.

>
> Paul
>
___
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/LP5ISUQFS6TSOAXQPC52BDB3I3UTYIBM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Consider moving abstract method checking logic from ABCMeta into object

[Neil Girdhar]

Currently, some type checkers rightly complain that a method is decorated 
with abc.abstractmethod when the class's type does not inherit from 
ABCMeta.  Adding a metaclass is a fairly heavy dependency since you're 
forced to poison all of your other metaclasses with the same base 
metaclass.  It also brings in possibly unwanted type registration that ABC 
comes with.

Now that abstractmethod's usage is extremely well-understood, would it make 
sense to move the checking logic out of ABCMeta?

It could either be put into object so that no base class is necessary (at 
the cost of slightly slower class creation), or else in a non-meta base 
class (say, HasAbstractMethods) now that __init_subclass__ is in all extant 
versions of Python.  Inheriting from such a non-meta base class would avoid 
the poisoning problem described above.

As far as I can tell, neither solution breaks code.

Best,

Neil
___
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/XXWLARRYM2D4R6RHMP5CTQ7WN2WXU6TK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Neil Girdhar]

Even if f{1} creates a frozenset, I don't think f{} should create a 
frozenset.  I think it makes more sense to keep f{1: 2} open for frozendict 
if it ever makes it in.  Also, {} should be consisten with f{} (both should 
create dicts).  If you want an empty frozenset, you would have to do it the 
same way you do it for sets: either frozenset() or f{*()}.

Best

Neil

On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:

>
> One thing to consider is if we're going to have a syntax capable of 
> creating an empty frozenset, we need one that creates an empty set.
>
> if f{...} exists, then s{...} should also exist?
>
> Regards
> João Bernardo
>
>
> On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas <
> python...@python.org> wrote:
>
>> I'm +1 on the idea.
>> I'm happy with the
>> f{ ... }
>> syntax (although I did suggest something else).
>> We already have letter-prefixes, let's stick to them rather than adding 
>> something new (which conceivably might one day find another use).
>> Best wishes
>> Rob Cliffe
>>
>> On 18/01/2022 15:53, Ricky Teachey wrote:
>>
>> On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno  
>> wrote:
>>
>>> >  but I don't think we should underestimate the cost of even this small 
>>> complexity increase in the language. 
>>>
>>> Actually, I think _maybe_ in this case the "complexity increase" cost is 
>>> _negative_. People might waste 
>>> more time looking for a way of spelling a frozenset literal than just 
>>> filling in "frozenset()". 
>>> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is 
>>> negligible, would 
>>> "feel" better there was a way to spell that without the needless 
>>> conversions.
>>>
>>> That said, an appropriate prefix for the {} just as we do for strigns 
>>> would be nice, and
>>> I disagree that it would be a significant source for "bugs". The "@{" is 
>>> a nice
>>> way out if people think "f{}" would be too close to "f()". And "<1,2,3>" 
>>> just for frozensets
>>> are indeed overkill. We already do "literal prefixing" with `"` after 
>>> all. and formally extending this
>>> prefix usage as needed for other literals seems like a nice path. 
>>> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j 
>>> anyone?)- maybe
>>> "{1,2,3}f" ? 
>>>
>>
>> I have been following along with not much to comment but this response 
>> sparked something in me.
>>
>> After reading all the viewpoints I think I would be +1 on the basic idea, 
>> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes 
>> I'm more of +0.5
>>
>> I like the way the suffix FLOWS with the act of writing the program. When 
>> I write a set, I am primarily focused on *what I am going to put in it*, 
>> and whether or not it should be mutable is kind of a later thought/debate 
>> in my head after I have established what it contains.
>>
>> As a dumb example, if my task at hand is "I need to create a bag of 
>> sports balls", I am mostly thinking about what goes into that bag at first, 
>> so I will write that first:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"), 
>> Ball("golf")} 
>>
>> Now I get to the end of that line, and I then sort of naturally think "ok 
>> does it make sense to freeze this" after i know what is in it.  With the 
>> postfix syntax, I then either type the f:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"), 
>> Ball("golf")}f
>>
>> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>>
>> A. it takes slightly more "work' at this point to "convert" the set to a 
>> frozenset, OR
>> B. i have to think about ahead of time-- before i have actually written 
>> what is in the set- whether it will be frozen, or not.
>>
>> In contrast, when you are deciding whether to write a list vs a tuple, 
>> you are deciding between two things that are fundamentally far more 
>> different IDEAS than a "bag of things, frozen or unfrozen". A list is very 
>> often more of an open ended stack than it is "an unfrozen tuple". A tuple 
>> is very often much more of an object that can be used as a dictionary key, 
>> or a member of a set, than it is a container of things (of course, it is a 
>> container of things, too). These differences make is a lot easier to 
>> choose, ahead of time, which one makes sense before you have even written 
>> the line of code.
>>
>> Maybe I'm making too much of this, but I really like the idea of deciding 
>> at the END of the set literal whether to tack on that "f".
>>
>> ---
>> Ricky.
>>
>> "I've never met a Kentucky man who wasn't either thinking about going 
>> home or actually going home." - Happy Chandler
>>
>>
>>
>>
>> ___
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to 
>> python-id...@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at 
>> 

[Python-ideas] Re: staticmethod vs classmethod [was: Add a decorators called @staticproperty]

[Neil Girdhar]

Totally agree with this.  I think both of points should be clarified in the 
documentation: https://docs.python.org/3/library/functions.html#staticmethod

Namely that:
* Nearly all uses of static methods should instead be class methods, and
* The main exception is setting an ordinary function as a class attribute 
without making it a method.

Best,

Neil
On Sunday, December 19, 2021 at 3:07:38 PM UTC-5 Serhiy Storchaka wrote:

> 19.12.21 19:41, Ethan Furman пише:
> > On 12/19/21 5:40 AM, Serhiy Storchaka wrote:
> > 
> >> classmethod supersedes staticmethod. It was not clearly known when they
> >> were introduced, but now we see that there is very few use cases for
> >> staticmethod which cannot be replaced by classmethod (actually only one
> >> specific case).
> > 
> > What is the one case?
>
> Setting a Python function as a class attribute without making it a method.
>
> def func(*args, **kwargs): ...
> class A:
> f = staticmethod(func)
> a = A()
> a.f(1) # calls func(1), not func(a, 1)
>
> It is used in tests if there are C and Python implementations.
> staticmethod(func) could be replaced with
>
> lambda self, /, *args, **kwargs: func(*args, **kwargs)
>
> or
>
> property(lambda self: func)
>
> in these cases.
>
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/J7GEEWCKIXWXOEQ4KD3ZFPA5W73ZAWVK/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/3PL4NXPEN6NWWZWECDEGDIDGKO4BNB74/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Applications user/system directories functions

[Neil Girdhar]

+1 for appdirs.  It's a shame that more projects don't yet use it.

On Wednesday, December 15, 2021 at 9:03:07 AM UTC-5 Matt del Valle wrote:

> There is appdirs which does precisely what you're looking for:
>
> https://pypi.org/project/appdirs/
>
> That said, it does seem to be a core bit of functionality that would be 
> nice to have in the os and pathlib modules without needing an external 
> dependency. I'm not going to weigh in on the pros/cons of adding it to the 
> stdlib, I'll leave that to others who I'm sure will have strong opinions on 
> the matter :)
>
> On Wed, Dec 15, 2021 at 1:47 PM JGoutin via Python-ideas <
> python...@python.org> wrote:
>
>> Hello,
>>
>> The idea is to add 3 functions to get "config", "data" and "cache" 
>> directories that are commonly used to store application files in user home 
>> / system.
>>
>> This look very straightforward to get theses directories path, but in 
>> practices it depends on many factors like OS, environnement variables, user 
>> or system dir.
>>
>> For instance, with the "config" directory:
>> * Linux, user: os.path.join(os.getenv("XDG_CONFIG_HOME", 
>> os.path.expanduser("~/.config")), app_name)
>> * Linux, system: os.path.join("/etc", app_name)
>> * Windows, user: os.path.join(os.path.expandvars("%APPDATA%"), app_name)
>> * Windows, system: 
>> os.path.join(os.path.expandvars("%CSIDL_COMMON_APPDATA%"), app_name)
>>
>> For linux, the full spec is here: 
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
>> I see many applications that just use "~/.app_name" to not have to handle 
>> theses cases.
>>
>>
>> The functions prototypes may look like and may be added to "shutil" (or 
>> "os.path" ?):
>>
>> def getcachedir(app_name: str=None, system: bool=False):
>>
>> With
>> * app_name: The application name
>> * system: If the required directory is the systemd directory or user 
>> direcotry.
>>
>>
>> This may also be implemented as an external library, but I am not sure I 
>> would like add add a dependency to my projects "just for this".
>>
>>
>> I can implement this if people are interested with this feature.
>> ___
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to python-id...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python...@python.org/message/MHEWO4U6SBDU7OU3JH4A62EWCANDM7I2/
>>  
>> 
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>___
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/IV3W2LRZ2KRYERYOYOGYWLI4TO7NXUHI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python standard library TOML module

[Neil Girdhar]

FYI: The flake8 project refuses to add toml configuration file support in 
part because there is no standard library toml 
module: https://github.com/PyCQA/flake8/issues/234#issuecomment-812800722

The thread was eventually locked by the project owner, and a project sprang 
up to try to address the issue: https://github.com/csachs/pyproject-flake8

Best,

Neil
On Saturday, December 11, 2021 at 11:57:24 AM UTC-5 Pradyun Gedam wrote:

> The line of reasoning for the packaging tooling choosing TOML is 
> elaborated upon in PEP 518 (
> https://www.python.org/dev/peps/pep-0518/#other-file-formats) and that 
> choice was informed by a survey of the existing formats: 
> https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f.
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/SDAJ4DCK7GJIMEONNYJ3NNXKJYGQWJDF/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/SFWQLF2RVIMDAS3WXYFDNPZ7HMIGAHWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

[Neil Girdhar]

On Monday, December 6, 2021 at 6:28:10 PM UTC-5 Steven D'Aprano wrote:

> On Mon, Dec 06, 2021 at 11:57:11AM -0800, Neil Girdhar wrote: 
>
> > Has anyone done a survey of, say, the cpython library codebase to see 
> what 
> > proportion of arguments lists would significantly benefit from this PEP 
> > given as a proportion of the total codebase? In all the Python I've ever 
> > written or seen, I can only thing of one example of a custom sentinel 
> ever 
> > being needed. 
>
> It is not just the *custom sentinels* that could be replaced with 
> late-bound defaults, but the good ol' `if param is None` sentinel as 
> well.


Yes, but that's not a big win in my opinion.  The None sentinels are not 
going away.  They're baked into the type annotations, and decades of 
idiomatic usage.  If None sentinels are slightly annoying, please let's 
consider pushing the none-aware operators.

Also, I like passing None sentinels because it means that I don't have to 
edit custom argument dicts, as I mentioned in my other comment.

Besides default constructed containers and custom sentinels, I don't see 
this feature as a big win.

>
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@python.org 
> https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/OM723LFGG4KGJMRG7NHRVHCABO2QWTJN/
>  
> <https://mail.python.org/archives/list/python-ideas@python.org/message/OM723LFGG4KGJMRG7NHRVHCABO2QWTJN/>
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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/A6PV6HD775JF2C3LXPOOQLJ2UCHZV7Y5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

[Neil Girdhar]

Has anyone done a survey of, say, the cpython library codebase to see what 
proportion of arguments lists would significantly benefit from this PEP 
given as a proportion of the total codebase?  In all the Python I've ever 
written or seen, I can only thing of one example of a custom sentinel ever 
being needed.

I think people are significantly underestimating the cognitive load this 
feature would add.

On Saturday, December 4, 2021 at 11:01:44 PM UTC-5 David Mertz, Ph.D. wrote:

> On Sat, Dec 4, 2021, 10:14 PM Rob Cliffe via Python-ideas 
>
>> The designers of 12 languages have chosen to provide late binding; those 
>> of 3 or 4 have provided early binding.
>> I think this is at least tenuous evidence in favour of my belief that 
>> late binding is more useful than early binding.
>>
>
> As the person probably most vociferous in opposing this PEP, 
>
I absolutely agree that late-binding is more useful. If I were creating a 
> new programming language today, I would certainly make arguments be 
> evaluated on call, not on definition.
>
> There are perfectly good ways to "fake" either one if you only have the 
> other. Probably more work is needed to simulate early binding, but there 
> are ways to achieve the same effect.
>
> However, that language would not be Python. That ship sailed in 1991. 
> What's being discussed here isn't changing the behavior of binding in `def 
> f(foo=bar)`. 
>
> Instead, it's a discussion of adding ADDITIONAL syntax for late-binding 
> behavior. I think the proposed syntax is the worst of all the options 
> discussed. But the real issue is that the cases where it is relevant are 
> vanishingly rate, and the extra cognitive, teaching, and maintenance burden 
> is significant.
>
> In 90%+ of the functions I've written, default arguments are non-sentinel 
> immutable values. If those were late bound, nothing whatsoever would 
> change. Yes, maybe slightly different bytecodes would exist, but at the 
> Python level, everything works work the same.
>
> So this issue only issue is only remotely relevant to <10% of functions 
> with default arguments. However, of those <10%, 98% work perfectly fine 
> with None as a sentinel.
>
> Probably fewer than half of functions I've written use named parameters at 
> all.
>
> In other words, for somewhere fewer than one in a thousand functions, this 
> new syntax might serve any purpose at all. That purpose is predominantly 
> "avoid using a custom sentinel." A custom sentinel is a SMALL lift. I agree 
> that a custom sentinel, while rare, is a slight wart in a program.
>
> I also believe that in this 1/1000 case, there could be a slightly 
> prettier automatic docstrings. But not prettier than writing an explicit 
> docstring in any case.
>
> The cost here is that EVERY SINGLE student learning Python needs to add 
> this new construct to their mental load. EVERY book and tutorial needs to 
> be updated. EVERY experienced developer has to spend extra effort 
> understanding and writing code.
>
> The COST of implementing this PEP is *quite literally* tens of millions of 
> person days. The benefit is a rare savings of two lines of function body 
> code or a docstring line.
>
>
>___
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/C6HMJPQ6NFZVSV3ZWY3JY54PSX4QAYPD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

[Neil Girdhar]

On Wednesday, December 1, 2021 at 1:18:33 AM UTC-5 Chris Angelico wrote:

> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ 
> with some additional information about the reference implementation, 
> and some clarifications elsewhere. 
>
> *PEP 671: Syntax for late-bound function argument defaults* 
>
> Questions, for you all: 
>
> 1) If this feature existed in Python 3.11 exactly as described, would 
> you use it?

No, I would avoid for the sake of readers.  Anyway, it can't be used in any 
public projects until thy drop support for 3.10, which is many years off.

Also, I think this question is quite the biased sample on python-ideas. 
Please consider asking this to less advanced python users, e.g., 
reddit.com/r/python or learnpython. 

>
> 2) Independently: Is the syntactic distinction between "=" and "=>" a 
> cognitive burden? 
>
> (It's absolutely valid to say "yes" and "yes", and feel free to say 
> which of those pulls is the stronger one.)

 Yes.

>
>
> 3) If "yes" to question 1, would you use it for any/all of (a) mutable 
> defaults, (b) referencing things that might have changed, (c) 
> referencing other arguments, (d) something else? 
>
> 4) If "no" to question 1, is there some other spelling or other small 
> change that WOULD mean you would use it? (Some examples in the PEP.)

No. 
 

> 5) Do you know how to compile CPython from source, and would you be 
> willing to try this out? Please? :) 
>
> I'd love to hear, also, from anyone's friends/family who know a bit of 
> Python but haven't been involved in this discussion. If late-bound 
> defaults "just make sense" to people, that would be highly 
> informative. 
>
> Any and all comments welcomed. I mean, this is python-ideas after 
> all... bikeshedding is what we do best! 

 


This PEP has a lot of interesting ideas.  I still think that none-aware 
operators (PEP 505) are an easier, more readable general solution to 
binding calculated default values to arguments succinctly.  I think the 
problems with this idea include:
* The caller cannot explicitly ask for default behaviour except by omitting 
the parameter.  This can be very annoying to set up when the parameter 
values are provided from other places, e.g.,
if need_x:
  # do lots of stuff
  x = whatever
else:
  # do more
  x = None
f(x=x, ...)  # easy, but with this PEP, you would have to find a way to 
remove x from the parameter list.  Typically, removing a parameter from a 
dynamically-created parameter list is hard.

* The function code becomes unreadable if the parameter-setting code is 
long.  Having a long piece of code inside the function after "if parameter 
is None" is just fine.  Having none-aware operators would make such code 
more succinct.

* People nearly always avoid writing code in the parameter defaults 
themselves, and this new practice adds a lot of cognitive load.  E.g., 
people rarely write:
def f(x: int = 1+g()) -> None: ...
Parameter lists are already busy enough with parameter names, annotations, 
and defaults.  We don't need to encourage this practice.

In short, I think this is a creative idea, a great exploration.  While 
optional parameters are common, and some of them have defaults that are 
calculated inside the function, my feeling is that people will continue to 
set their values inside the function.

Best,

Neil

___
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/HJIDYKZV3EVURWFLETSPIZ2YFGN2RNZE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: extending ast.parse with some lib2to3.pytree features

[Neil Girdhar]

I wish this had gotten more attention! :)
___
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/6M2NDXGWLC633IPUDDTFAHLAG2PCAKZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

[Neil Girdhar]

> I propose (not for the first time) that similarly concatenating an 
unknown number of iterables or dicts should be possible via comprehensions:

I'm really happy to see this feature proposal come up again!  Every time, 
it seems this feature is even more intuitive to even more people, and I'm 
excited to see so many +1s compared to the -1s.  I hope it will be 
accepted, if not this time, then one day :)

It was considered and rejected in PEP 448. What was changed since? What new 
> facts or arguments have emerged?


Just for the record, both Joshua and I worked on implementing PEP 448.  We 
both wanted this feature because we felt it was consistent.  However, we 
wanted to maximize the probability that PEP 448 was accepted, so we chose 
to defer this feature.

Best,

Neil
___
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/4XTAB77PVTQ5DDY27IHPOXUPMED6B5TI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Neil Girdhar]

I like this comment.

The proposal to change list and str is way too ambitious.  But some minor 
cleanup might not be so pernicious?

On Saturday, November 13, 2021 at 5:31:49 PM UTC-5 Mike Miller wrote:

>
> I like this idea and disappointed it always gets a negative reaction. One 
> of my 
> biggest peeves is this: 
>
> import datetime # or 
> from datetime import datetime 
>
> Which is often confusing... is that the datetime module or the class 
> someone 
> chose at random in this module? A minor thorn that… just doesn't go away. 
>
>
> On 2021-11-11 07:38, Eric V. Smith wrote: 
> > The costs of migration are also too high. I personally work on a 20 year 
> old 
> > proprietary python code base that would never be updated for a change 
> like this. 
> > 
> > like: "str = 'foo'". But even if a perfect tool existed, it would take 
> > man-months and many tens of thousands of dollars to test such a large 
> code base. 
> > My clients are understandably unwilling to do that for no functional 
> gain. 
>
>
> My current work is on a ~15 year old code base. Had to do a number of 
> upgrades 
> over the years. 2.x to 3.x was the big one. Luckily there was not a lot of 
> text encoding work so porting was straightforward, and the project was 
> improved 
> for the effort. Despite the failures and grumbling there are success 
> stories as 
> well. 
>
> A lot of folks are understandably hesitant at repeating the 2 vs 3 divide. 
> But 
> I think some learned the wrong lesson from that experience. 
>
> The lesson wasn't that we shouldn't improve anything, but that we 
> shouldn't 
> change anything *fundamental.* Fundamental improvements generally can't be 
> automated, they sometimes have to be rebuilt from the ground up. I agree 
> that's 
> a no-go. 
>
> But this thread is about a rename with aliases for compatibility. 
>
> Recently we brought the same project from the ~3.5 era to 3.8 idioms using 
> the 
> tool pyupgrade. Have you tried it? Made short work of moving forward. 
> Project 
> is now more readable, using better language features. 
>
> It took a few hours from an existing maintenance budget—not tens of 
> thousands of 
> dollars. Not only that, (combined with other refactoring) the code is more 
> fun 
> to work on now. Yes, you read that right, enjoyment has increased due to 
> improved readability, appearance, and quality. 
>
> No, we couldn't afford to rewrite it from the ground up. But, running a 
> tool to 
> fix the case of a few confusing names is a small win for a small cost. I 
> would 
> like to continue the process. 
>
> +1 for stdlib, not including typing scope creep, 
> -Mike 
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/7DQAXLLLNWKRJAWBU2QPUBYH4LRSP746/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/7VEKSRWWODDUSRZQRP5RGKYTSBDZRYHX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Neil Girdhar]

As someone who originally worked on implementing PEP 448, I wanted to chime 
in that while I agreed with the decision to be conservative when adding new 
features, I originally hoped that [*x for x in xs] would eventually make 
its way into Python.  To me, it seemed intuitive and I hoped people would 
eventually come around to seeing things that way, and to Steven's similar 
suggestion for dicts {**x for x in xs}.

However, I had never seen Serhiy and Guido's point about the similarity to 
[a, b for a, b in abs].  I agree that the comparison makes sense, and that 
that notation is really confusing.  Maybe this should be added to the PEP 
(https://www.python.org/dev/peps/pep-0448/) as a reminder?

Given the counterpoint, I don't have a strong opinion either way. Maybe 
it's better to remain conservative and see where the language is at in 
another few years?

On another tangent, I'd like to see array[*x, y] working one day.  If I 
remember correctly, that was an oversight.  It regularly comes up when 
indexing numpy arrays, and needs an ugly workaround.

Best,

Neil

>___
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/K7MYCJPHWMKW67XQAS244CJ4I22VHVSY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Neil Girdhar]

Oh, and I see you're a sympy developer!  I hope I'm not coming across
as critical in any way.  I love that sympy exists and thought it was a
really cool project when I first learned about what it can do.

Perhaps we should move our discussion to a "Github discussion" under
the sympy Github?

We might be able to build a toy example that takes functions, inspects
the signature, and converts it into a traditional sympy expression.
Then we could examine a variety of examples in the docs to see whether
the function-based symbols are easier or harder to use in general.

Best,

Neil

On Tue, Jun 1, 2021 at 6:47 AM Neil Girdhar  wrote:
>
> On Tue, Jun 1, 2021 at 6:28 AM Oscar Benjamin
>  wrote:
> >
> > On Tue, 1 Jun 2021 at 10:53, Neil Girdhar  wrote:
> > >
> > > On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
> > >  wrote:
> > > >
> > > > On Tue, 1 Jun 2021 at 05:16, Neil Girdhar  wrote:
> > > > >
> > > > > Hi Oscar,
> > > > >
> > > > > The problem that the original poster was trying to address with
> > > > > additional syntax is the automatic naming of symbols.  He wants to
> > > > > omit this line:
> > > > >
> > > > > x = symbols("x")
> > > > >
> > > > > You're right that if you have many one-character symbol names, you can
> > > > > use a shortcut, but this benefit is lost if you want descriptive names
> > > > > like:
> > > > >
> > > > > momentum = symbols('momentum')
> > > > >
> > > > > He is proposing new syntax to eliminate the repeated name.  The
> > > > > function approach specifies each name exactly once.  This is one of
> > > > > the benefits of JAX over TensorFLow.
> > > > >
> > > > > Second, the function approach allows the function to be a single
> > > > > object that can be used in calcuations.   You might ask for:
> > > > >
> > > > > grad(equation, 2)(2, 3, 4 5)  # derivative with respect to parameter 2
> > > > > of equation evaluated at (2, 3, 4, 5)
> > > > >
> > > > > With the symbolic approach, you need to keep the equation object as
> > > > > well as the symbols that compose it to interact with it.
> > > >
> > > > This makes more sense in a limited context for symbolic manipulation
> > > > where symbols only represent function parameters so that all symbols
> > > > are bound. How would you handle the situation where the same symbols
> > > > are free in two different expressions that you want to manipulate in
> > > > tandem though?
> > > >
> > > > In this example we have two different equations containing the same
> > > > symbols and we want to solve them as a system of equations:
> > > >
> > > > p, m, h = symbols('p, m, h')
> > > > E = p**2 / 2*m
> > > > lamda = h / p
> > > >
> > > > E1 = 5
> > > > lamda1 = 2
> > > > [(p1, m1)] = solve([Eq(E, E1), Eq(lamda, lamda1)], [p, m])
> > > >
> > > > I don't see a good way of doing this without keeping track of the
> > > > symbols as separate objects. I don't think this kind of thing comes up
> > > > in Jax because it is only designed for the more limited symbolic task
> > > > of evaluating and differentiating Python functions.
> > >
> > > This is a really cool design question.
> > >
> > > One of the things I like about JAX is that they stayed extremely close
> > > to NumPy's interface.  In NumPy, comparison operators applied to
> > > matrices return Boolean matrices.
> > >
> > > I would ideally express what you wrote as
> > >
> > > def E(p, m): ...
> > >
> > > def lamda(h, p): ...
> > >
> > > def f(p, m):
> > > return jnp.all(E(p, m) == E1) and jnp.all(lamda(h, p) == lamda1)
> > >
> > > p1, m1 = solve(f)
> >
> > So how does solve know to solve for p and m rather than h?
>
> Because those are the parameters of f.
> >
> > Note that I deliberately included a third symbol and made the
> > parameter lists of E and lamda inconsistent.
> >
> > Should Jax recognise that the 2nd parameter of lamda has the same name
> > as the 1st parameter of E? Or should symbols at the same parameter
> > index be considered the same regardless of their name?
>
> It doesn't need to because the same var

[Python-ideas] Re: symbolic math in Python

[Neil Girdhar]

On Tue, Jun 1, 2021 at 6:28 AM Oscar Benjamin
 wrote:
>
> On Tue, 1 Jun 2021 at 10:53, Neil Girdhar  wrote:
> >
> > On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
> >  wrote:
> > >
> > > On Tue, 1 Jun 2021 at 05:16, Neil Girdhar  wrote:
> > > >
> > > > Hi Oscar,
> > > >
> > > > The problem that the original poster was trying to address with
> > > > additional syntax is the automatic naming of symbols.  He wants to
> > > > omit this line:
> > > >
> > > > x = symbols("x")
> > > >
> > > > You're right that if you have many one-character symbol names, you can
> > > > use a shortcut, but this benefit is lost if you want descriptive names
> > > > like:
> > > >
> > > > momentum = symbols('momentum')
> > > >
> > > > He is proposing new syntax to eliminate the repeated name.  The
> > > > function approach specifies each name exactly once.  This is one of
> > > > the benefits of JAX over TensorFLow.
> > > >
> > > > Second, the function approach allows the function to be a single
> > > > object that can be used in calcuations.   You might ask for:
> > > >
> > > > grad(equation, 2)(2, 3, 4 5)  # derivative with respect to parameter 2
> > > > of equation evaluated at (2, 3, 4, 5)
> > > >
> > > > With the symbolic approach, you need to keep the equation object as
> > > > well as the symbols that compose it to interact with it.
> > >
> > > This makes more sense in a limited context for symbolic manipulation
> > > where symbols only represent function parameters so that all symbols
> > > are bound. How would you handle the situation where the same symbols
> > > are free in two different expressions that you want to manipulate in
> > > tandem though?
> > >
> > > In this example we have two different equations containing the same
> > > symbols and we want to solve them as a system of equations:
> > >
> > > p, m, h = symbols('p, m, h')
> > > E = p**2 / 2*m
> > > lamda = h / p
> > >
> > > E1 = 5
> > > lamda1 = 2
> > > [(p1, m1)] = solve([Eq(E, E1), Eq(lamda, lamda1)], [p, m])
> > >
> > > I don't see a good way of doing this without keeping track of the
> > > symbols as separate objects. I don't think this kind of thing comes up
> > > in Jax because it is only designed for the more limited symbolic task
> > > of evaluating and differentiating Python functions.
> >
> > This is a really cool design question.
> >
> > One of the things I like about JAX is that they stayed extremely close
> > to NumPy's interface.  In NumPy, comparison operators applied to
> > matrices return Boolean matrices.
> >
> > I would ideally express what you wrote as
> >
> > def E(p, m): ...
> >
> > def lamda(h, p): ...
> >
> > def f(p, m):
> > return jnp.all(E(p, m) == E1) and jnp.all(lamda(h, p) == lamda1)
> >
> > p1, m1 = solve(f)
>
> So how does solve know to solve for p and m rather than h?

Because those are the parameters of f.
>
> Note that I deliberately included a third symbol and made the
> parameter lists of E and lamda inconsistent.
>
> Should Jax recognise that the 2nd parameter of lamda has the same name
> as the 1st parameter of E? Or should symbols at the same parameter
> index be considered the same regardless of their name?

It doesn't need to because the same variable p (which will ultimately
point to a tracer object) is passed to the functions E and lamda.
It's not using the names.
>
> In Jax everything is a function so I would expect it to ignore the
> symbol names so that if
> args = solve([f1, f2])
> then f1(*args) == f2(*args) == 0.
>
> This is usually how the API works for numerical rather than symbolic
> root-finding algorithms. But then how do I solve a system of equations
> that has a symbolic parameter like `h`?

I assumed that h was a constant and was being closed over by f.  If h
is a symbol, I think to stay consistent with functions creating
symbols, we could do:


def f(p, m, h):
return E(p, m) == E1 and lamda(h, p) == lamda1

def g(h):
return solve(partial(f, h=h))

g is now a symbolic equation that returns p, m in terms of h.

By the way, it occured to me that it might be reasonable to build a
system like this fairly quickly using sympy as a backend.

Although, there are some other benefits of Jax's symbolic
expression-builder that might be a lot harder to capture: Last time I
used sympy though (years ago), I had a really hard time making
matrices of symbols, and there were some incongruities between numpy
and sympy functions.

Best,

Neil
>
> --
> Oscar
___
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/AN37BNIJQNVFEW27CQ5T5RJJHKGLCD3H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Neil Girdhar]

On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
 wrote:
>
> On Tue, 1 Jun 2021 at 05:16, Neil Girdhar  wrote:
> >
> > Hi Oscar,
> >
> > The problem that the original poster was trying to address with
> > additional syntax is the automatic naming of symbols.  He wants to
> > omit this line:
> >
> > x = symbols("x")
> >
> > You're right that if you have many one-character symbol names, you can
> > use a shortcut, but this benefit is lost if you want descriptive names
> > like:
> >
> > momentum = symbols('momentum')
> >
> > He is proposing new syntax to eliminate the repeated name.  The
> > function approach specifies each name exactly once.  This is one of
> > the benefits of JAX over TensorFLow.
> >
> > Second, the function approach allows the function to be a single
> > object that can be used in calcuations.   You might ask for:
> >
> > grad(equation, 2)(2, 3, 4 5)  # derivative with respect to parameter 2
> > of equation evaluated at (2, 3, 4, 5)
> >
> > With the symbolic approach, you need to keep the equation object as
> > well as the symbols that compose it to interact with it.
>
> This makes more sense in a limited context for symbolic manipulation
> where symbols only represent function parameters so that all symbols
> are bound. How would you handle the situation where the same symbols
> are free in two different expressions that you want to manipulate in
> tandem though?
>
> In this example we have two different equations containing the same
> symbols and we want to solve them as a system of equations:
>
> p, m, h = symbols('p, m, h')
> E = p**2 / 2*m
> lamda = h / p
>
> E1 = 5
> lamda1 = 2
> [(p1, m1)] = solve([Eq(E, E1), Eq(lamda, lamda1)], [p, m])
>
> I don't see a good way of doing this without keeping track of the
> symbols as separate objects. I don't think this kind of thing comes up
> in Jax because it is only designed for the more limited symbolic task
> of evaluating and differentiating Python functions.

This is a really cool design question.

One of the things I like about JAX is that they stayed extremely close
to NumPy's interface.  In NumPy, comparison operators applied to
matrices return Boolean matrices.

I would ideally express what you wrote as

def E(p, m): ...

def lamda(h, p): ...

def f(p, m):
return jnp.all(E(p, m) == E1) and jnp.all(lamda(h, p) == lamda1)

p1, m1 = solve(f)

>
> Also for simple expressions like this I think that a decorated
> function seems quite cumbersome:
>
> @symbolic
> def E(p, m):
> return p**2 / (2*m)
>
> @symbolic
> def lamda(h, p):
> return h / p

I guess we don't need the decorator unless we want to memoize some
results.  JAX uses a decorator to memoize the jitted code, for
example.  I thought it might be nice for example to memoize the parse
tree so that the function doesn't have to be called every time it's
used.
>
> > Finally, the function can just be called with concrete values:
> >
> > equation(2, 3, 4, 5)  # gives 25
> >
> > which is convenient.
>
> That is convenient but I think again this only really makes sense if
> all of your expressions are really just functions and all of your
> symbols are bound symbols representing function parameters. It is
> possible in sympy to convert an expression into a function but you
> need to specify the ordering of the symbols as function parameters:
>
> expression = p**2 / (2*m)
> function = lambdify([p, m], expression)
> function(1, 2)  # 0.25
>
> The need to specify the ordering comes from the fact that the
> expression itself is not conceptually a function and does not have an
> ordered parameter list.

Right.  I think it's simpler to just specify symbolic functions as
Python functions, but I can see why that does make the very simplest
cases slightly more wordy.

>
> --
> Oscar
___
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/Z6C5HVMJMDG7EMGHVRFPWPPL5KNZ2Y5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Neil Girdhar]

Have you considered using the JAX library's trick of decorating functions 
to provide automatic symbols?

For example, your problem could be done in current Python with an 
appropriately-coded library:

@symbolic
def f(x, a, b, c):
 return a * x ** 2 + b * x + c

sentinel = Sentinel()

solve(f(sentinel, 1, 0, -1 / 2), solve_for=sentinel)

The idea is that f(sentinel) would produce the expression graph by 
propagating tracer objects throughout the tree.  Then, solve would identify 
the appropriate tracer to be solved.

JAX uses this trick to accomplish three tasks: JIT compilation of 
mathematical expressions, automatic calculation of gradients and related 
functions, and automatic generation of vectorized versions of functions.

To be fair, JAX's design is brilliant.  I don't fault the SymPy people for 
not coming up with it, but the problem that you're trying to solved could 
be done with a better-designed SymPy.  You don't need new syntax.

Neil
On Wednesday, May 19, 2021 at 2:39:18 AM UTC-4 Martin Teichmann wrote:

> Hi list,
>
> as you might have noticed, I am trying to improve the syntax and semantics 
> for symbolic math in Python. Until now, I have to say, my ideas were not 
> that well received, but I learned from the discussion and maybe this time I 
> come up with something people like.
>
> To frame the problem, let us try to solve the equation x ** 2 == 1/2 using 
> sympy:
>
> >>> from sympy import Eq, solve, symbols, S
> >>> x = symbols("x")
> >>> solve(Eq(x**2, S(1)/2))
> [-sqrt(2)/2, sqrt(2)/2]
>
> that worked well, but actually we would like to write the last line simply 
> as
>
> >>> solve(x**2 == 1/2)
>
> as you might notice, this is fully legal Python syntax. Unfortunately the 
> semantics is such that sympy has no way to determine what is actually going 
> on, this is why they invented all those helper functions shown above.
>
> My idea is now to start at the line above, "x = symbols('x')". I propose a 
> new syntax, "symbolic x", which tells the parser that x is a symbolic 
> variable, and expressions should not be executed, but handed over as such 
> to the calling functions. To stay with the example, the code would look 
> like this (this is fake, I did not prototype this yet):
>
> >>> from sympy import solve
> >>> symbolic x
> >>> solve(x**2 == 1/2)
> [-sqrt(2)/2, sqrt(2)/2]
>
> Now to the details. The scope that "symbolic" acts on should be the same 
> as the scope of "global". Note that "symbolic x" is currently illegal 
> syntax, so we would not even need to make "symbolic" a keyword.
>
> Expressions that contain a symbolic variable are not executed, but instead 
> the expression should be given to the function as a tuple, so in the 
> example above, solve would be given
> ('==', ('**', ('x', 2)), ('/', 1, 2)). If that looks like LISP to you, 
> then you are not completely wrong. The boundaries of expressions are 
> function calls, assignments, getitems and getattrs, as they can be 
> overloaded much easier by other means. To give an example with gory details 
> (again, this is fake):
>
> >>> symbolic x
> >>> d = {"a" : 5}
> >>> c = 7 # not symbolic!
> >>> print(c * x + d["a"])
> ('+', ('*', 7, 'x'), 5)
>
> Maybe we would want to have a new class "expressiontuple" which simply 
> acts as a pretty-printer, then the last lines would become
>
> >>> print(x + d["a"])
> 7 * x + 5
>
> What sympy does with this tuple would be fully at its discretion.
>
> I think that other libraries could also benefit from this proposal. As an 
> example, in a numerics library (numpy? scipy?) one could improve numerical 
> integration as in
>
> >>> symbolic x
> >>> integrate(sin(x), x, 0, pi)
>
> then the integrator could even compile the expression to machine code for 
> faster integration.
>
> numpy could also compile expressions to machine code, making it even 
> faster than it is now, as in
>
> >>> symbolic x
> >>> f = compile(5 * x + 7 * y, (x, y))
> >>> f(matrix_a, matrix_b) 
>
> Let's see how well this proposal fares.
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/ZMUV4OUDUX3NSROM2KRUIQKSIBUCZOCD/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/QU627GUQAVPPWY6ELV45KPYGDXO4H6YY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Neil Girdhar]

I agree with the comment about removing full justification.

Also, I think the Masonite docs' navigation is far superior to the Python 
docs.  I like the full contents on the left, along with the version button, 
and the local jump on the right.  The python docs require you to navigate 
somehwere else for the full contents.  And, I don't undrstand why anyone 
would want "previous topic/next topic"—it's not like you're curling up with 
the Python docs before bed :)

Finally, putting the docs in the center of the screen is better on today's 
giant monitors.



On Tuesday, May 4, 2021 at 11:21:48 PM UTC-4 Jonathan Goble wrote:

> On Tue, May 4, 2021 at 11:05 PM Mike Miller  
> wrote:
>
>> One  thing  that  drives me  nuts  about  the current  Python  docs  
>> theme  is
>> the FULL  JUSTIFICATION that  adds random  spaces into  each  line to 
>> make the
>> edges   line  
>>  up!
>>
>> Whatever y'all do, please remove that. :D  I sometimes deactivate it in 
>> the 
>> browser dev tools but there it is again next refresh.
>>
>
> Please. Full justification is nice with narrow columns like newspapers, 
> but on the web with wider paragraphs, it's annoying. I'd love to see it 
> yanked from the Python docs.
>
___
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/ISTQ4PLQ3TNLXXL5BRWWJLI5PIDAGD33/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add an export keyword to better manage __all__

[Neil Girdhar]

This is a great discussion.  However, there's one issue that seems to
be getting lost.  Consider this library structure:

test/lemon
test/lemon/__init__.py
test/module.py

where test/module.py is:

__all__ = ['lemon']
def lemon():
pass

and test/__init__.py is:

from .module import *
from .lemon import *

and test/lemon/__init__.py is empty.

What do you think test.lemon is?  It's not the function because it's
hidden by the eponymous package.  Also, test.module is exported
whether you wanted to export it or not.

This is the problem with any mechanism like __all__ or export.  I
think the main motivation behind the Jax team tucking everything in
_src is that it hides the package names and module names from the
public interface.

I think I'm going to start only using __all__ for collecting private
symbols into packages under a _src package.  For the external
interface, I'm going to explicitly import from dummy modules.  I'd
love to know if something better exists, but I don't think the export
keyword works because of the above problem.

Best,

Neil

On Mon, Apr 12, 2021 at 7:39 AM Joseph Martinot-Lagarde
 wrote:
>
> M.-A. Lemburg wrote:
> > The public API of a library is the one which is documented as
> > such. That's really all there is to it. Documentation is written
> > explicitly by the author of a package and languages provides
> > a lot more nuances than using some programmatic mechanism.
> I use __all__ with sphinx to automatically build my documentation, so __all__ 
> effectively becomes part of the documentation. I don't expect people to use 
> import *. Maybe for big projects there is a need to write all the 
> documentation by hand, but for small libraries using __all__ and 
> automatically build the documentation (along other pages like FAQ, HOWTO and 
> so on) is very powerful and makes a good documentation while assurint it's up 
> to date with the code.
> There are definitely use cases for __all__ outside of import *.
> ___
> 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/ASZOJHLO2HDSQDDA2KQPTELUZOVNIL3C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "python-ideas" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/python-ideas/c2JTmIJnX5c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> python-ideas+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/python-ideas/161822751700.5428.12873752338560477293%40mail.python.org.
___
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/TNGY6TTTQBX5QS62C24E7ZG6GEH3P7A6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add an export keyword to better manage __all__

[Neil Girdhar]

I like the idea of improving the way interfaces are exported in Python.  I 
still don't know what the standard is today.

Some of my favourite projects like Jax have started tucking their source in 
a _src directory: https://github.com/google/jax/tree/master/jax/_src, and 
then importing the exported interface in their main 
project: https://github.com/google/jax/blob/master/jax/scipy/signal.py.  As 
far as I know, this "private source" method is nicest way to control the 
interface.

What I've been doing is importing * from my __init__.py 
(https://github.com/NeilGirdhar/tjax/blob/master/tjax/__init__.py) and then 
making sure every module has an __all__.  This "init-all" method is 
problematic if you want to export a symbol with the same name as a folder.  
It also means that all of your modules and folders are exported names. If I 
started again, I'd probably go with the way the Jax team did it.

I agree that the proposed export keyword is nicer than __all__, and 
accomplishes what I've been doing more elegantly.  However, it suffers from 
the same extraneous symbol problem.  I would still choose the private 
source method over export.

I'm curious if anyone has ideas about how exporting an interface should be 
done today, or could be done tomorrow.
On Monday, March 15, 2021 at 9:48:11 AM UTC-4 Rob Cliffe via Python-ideas 
wrote:

>
>
> On 15/03/2021 05:54, Ethan Furman wrote:
> > On 3/14/21 12:42 PM, Stestagg wrote:
> >
> >> The value of being able to (in specific cases) reach into third-party 
> >> code, and customize it to work for your specific situation should not 
> >> be disregarded.
> >
> > I completely agree with this.  One of the hallmarks of Python is the 
> > ability to query, introspect, and modify Python code.  It helps with 
> > debugging, with experimenting, with fixing.  Indeed, one of the few 
> > frustrating bits about Python is the inability to work with the C 
> > portions as easily as the Python portions (note: I am /not/ suggesting 
> > we do away with the C portions).
> An emphatic +1.
> Rob Cliffe
> >
> >
> > What would be the benefits of locking down modules in this way?
> >
> > -- 
> > ~Ethan~
> > ___
> > Python-ideas mailing list -- python...@python.org
> > To unsubscribe send an email to python-id...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at 
> > 
> https://mail.python.org/archives/list/python...@python.org/message/KIFAVTRMIPCVAX2RZ7NDSTDM46AHSDWK/
>  
> 
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/TFGG5LBGEIH34WJNIKZGBCT67A6KFGKM/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YDTNI7V2V6L3SEJCHOYZWSXC3QVB4WBS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] reversed enumerate

[Neil Girdhar]

On Thu, Jan 21, 2021 at 7:19 PM Chris Angelico  wrote:
>
> On Fri, Jan 22, 2021 at 11:10 AM Random832  wrote:
> >
> > On Thu, Jan 21, 2021, at 18:48, Chris Angelico wrote:
> > > Note that slicing is NOT easy. The proposed semantics for a reversed
> > > enumeration would make slicing extremely odd.
> >
> > What proposed semantics? You were the one who posted a pure-python 
> > implementation that didn't bother to implement slicing.
>
> Ah, my bad. This thread started out on python-dev before migrating to
> -ideas, and I believe the proposed semantics may have been on one of
> the early -dev posts.
>
> The proposal was, effectively, to be the same as enumerating, making a
> concrete list, and then reversing (only, without actually building the
> list, of course). So enumerate("abc") yields [(0,'a'),(1,'b'),
> (2,'c')], and iterating backwards should yield those same tuples in
> reverse order.
>
> But if you take the reversed enumeration, iterate over it a bit, and
> then slice it, the semantics will be extremely bizarre.
>
> > It's easy enough to add slicing to your Enumerated class concept, though.
> >
> > class Enumerated:
> > def __init__(self, basis, indices=None):
> > self.basis = basis
> > self.indices = indices if indices is not None else range(len(basis))
> > def __getitem__(self, idx):
> > if isinstance(idx, slice):
> > return Enumerated(self.basis, indices=self.indices[idx])
> > else:
> > return (self.indices[idx], self.basis[self.indices[idx]])
> > def __len__(self):
> > return len(self.indices)
>
> Yeah, I don't think that'll work if you slice more than once,
> especially with some iteration in between.
>
> The precise semantics for mixing iteration and slicing are complex
> enough and variable enough that you may as well just go for a concrete
> list at that point.

Can you give an example of what you mean?--because I'm pretty sure
that we're not talking about the same thing at all.

If enumerate(some_sequence) returns a sequence view, iterating over
that sequence view does not advance it—just like how DictViews are not
altered by iteration.  Same thing if reversed(some_sequence) returns a
sequence view.

So, reversed(enumerate("abc"))[2] would just be (0, 'a').

You're right that there are some minor incongruities.  The only one I
can think of off-hand is bool(enumerate(some_sequence)) would be false
when the sequence is empty.

As for candidates for sequence views, I'd like to see reversed and
enumerate to start since I can remember having to cast to list many
times and it would be convenient not to have to.  From itertools, it
would be useful for thecombinatorics operators (combinations,
permutations, product, etc.) to be sequence views.  In fact, there are
convenience functions for looking them up by index in more-itertools
as this comes up a lot (at least it did for me back when I did
contests).

>
> ChrisA
> ___
> 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/VTSZZK3RKSKCEG7CFHYT4TZXLMP37P3I/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "python-ideas" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/python-ideas/3wGART2ECXQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> python-ideas+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/python-ideas/CAPTjJmpboVPni3FimaTh%3DNo_GBUfTmozE4kQhXBPQCrsgmkSJg%40mail.gmail.com.
___
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/YWD7JGFSUGLMFCRJKFRQYVZYTIMW25PV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] reversed enumerate

[Neil Girdhar]

On Thu, Jan 21, 2021 at 3:13 PM Christopher Barker  wrote:
>
> On Thu, Jan 21, 2021 at 10:43 AM Neil Girdhar  wrote:
>>
>> > > I've seen this proposed here before.  The general idea is that some 
>> > > iterator transformations (like enumerate) should return sequences when 
>> > > they're applied to sequences.
>
>
> I'm not so sure -- I don't think I want a sequence returned. In fact, in this 
> case, just the opposite. If you wanted a sequence, you could simply do:
>
> reversed(list(enumerate(the_iterable)))
>
> Rather, you want (or I want, anyway) is for various iterators to be able to 
> do things that require a Sequence, when given a Sequence. Or, maybe not even 
> a full Sequence, but rather, some particular aspect of a sequence -- like the 
> length, or indexability.
>
> enumerate() with a reversed flag is one. Another, I'd like is islice to 
> support negative indexing for indexing from the end. There are probably many 
> others.
>
> I'd love to see these supported. For this example:
>
> enumerate(an_iterable, reversed=True)

Don't you think this is over-complicated?

It's possible for reversed(enumerate(...)) to just work if enumerate
of a sequence were to return a sequence view.  Then you would also get
all the other sequence operations for free like enumerate(...)[23:27],
len(enumerate(...)), etc.

>
> would "just work" if an_iterable had a __len__ and a __getitem__.
>
> It would raise a TypeError if passed a non-lengthed, or non-indexable 
> iterable.
>
> -CHB
>
> > > In short, this has nothing to do with reversed.
>
> I agree.
>
> >> If you made enumerate return a sequence when its input is a sequence, you 
> >> would also be able to do enumerate(some_list)[34],
>
> As Chris A mentioned, it's quite easy to wrap list() or tuple() around it if 
> you want that.

Yes, you can alternatively wrap with list and pay the computational
cost.  However, as was suggested by Andrew in this thread, but has
come up many times before, the native iteration tools could return
views.  This saves the user having to build her own custom classes
(along with tests, etc.).  I happen to think this is simpler and more
beautiful.

Best,

Neil

>
> - Chris B
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
___
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/S4BNJSIRGJT3IKK7GQCHWUWK2VLDYE4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] reversed enumerate

[Neil Girdhar]

On Thu, Jan 21, 2021 at 1:26 PM Chris Angelico  wrote:
>
> On Fri, Jan 22, 2021 at 5:21 AM Neil Girdhar  wrote:
> >
> > I've seen this proposed here before.  The general idea is that some 
> > iterator transformations (like enumerate) should return sequences when 
> > they're applied to sequences.  I think it's good idea, but it adds 
> > complexity and work, which I guess needs to be justified on a case-by-case 
> > basis.
> >
> > In short, this has nothing to do with reversed.  If you made enumerate 
> > return a sequence when its input is a sequence, you would also be able to 
> > do enumerate(some_list)[34], which could also be useful.  I think it makes 
> > Python slightly more perfect and more beautiful.
> >
>
> list(enumerate(some_list)) will give you a sequence, if that's what you want.

Right.  And reversed(list(enumerate(some_list)) also works.  The point
is that if you return sequence views (as Andrew mentioned), you don't
need to cast to list explicitly, and you don't pay the computational
cost of that either.

>
> ChrisA
> ___
> 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/WW3JHS234TJSXKUICY4PG2SPDTD3SBUP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "python-ideas" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/python-ideas/3wGART2ECXQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> python-ideas+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/python-ideas/CAPTjJmpPchBQEWVP1Mt8UW3aaquTKx2kLVrxhc%3DV7LOpD%3Db7XQ%40mail.gmail.com.
___
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/RPKLUPE4XINPWKORTJU6TGUENPQ3UVXD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] reversed enumerate

[Neil Girdhar]

I've seen this proposed here before.  The general idea is that some 
iterator transformations (like enumerate) should return sequences when 
they're applied to sequences.  I think it's good idea, but it adds 
complexity and work, which I guess needs to be justified on a case-by-case 
basis.

In short, this has nothing to do with reversed.  If you made enumerate 
return a sequence when its input is a sequence, you would also be able to 
do enumerate(some_list)[34], which could also be useful.  I think it makes 
Python slightly more perfect and more beautiful.

Best,

Neil
On Thursday, January 21, 2021 at 6:23:20 AM UTC-5 Nuri Jung wrote:

> So, what is the conclusion? I also think reversed(enumerate(some_seq)) 
> will be very useful in many cases.
> It should:
> 1) work the same as reversed(tuple(enumerate(...))) for "reversible" 
> objects as argument of enumerate,
> 2) raise TypeError if the object is not reversible.
>
> Or, another option would be adding a "step" keyword argument to enumerate.
> Then, reversing enumerate would be much easier, like this:
> enumerate(reversed(some_seq), step=-1)
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/BW2XKRZ4TSXCFULCS2EU33LLNMIXAL5T/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YNJEP32X4VGD2GAMJCDJH6UHLBQHW5AP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Consider having numbers.Real provide __complex__?

[Neil Girdhar]

Thanks for the correction Mark, I didn't realize that!

Shantanu is right about what my ask was meant to be.  I guess I'm nowhere 
near the first to propose things like this and there's a lot of discussion 
in various threads about it that I wasn't aware of.

Best,

Neil

On Monday, January 18, 2021 at 3:56:59 PM UTC-5 Shantanu Jain wrote:

> Yes, I believe the ask is for `int.__complex__`, `float.__complex__` and 
> `complex.__complex__` (
> https://github.com/python/mypy/issues/3186#issuecomment-762121456)
>
> On Mon, 18 Jan 2021 at 09:47, Mark Dickinson  
> wrote:
>
>> Inheriting from `numbers.Real` _does_ give you `__complex__`, though: 
>> https://github.com/python/cpython/blob/314b8787e0c50985ba708034b84ff5b37a1d47de/Lib/numbers.py#L245-L248
>>
>> Is it instead `float.__complex__` you're asking for?
>> ___
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to python-id...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python...@python.org/message/L7KA5VUCJB77MUOXQPMMCSA3CDCM767O/
>>  
>> 
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>___
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/ZDFSC3V3J5KRWCJ6HCPFLA2JHJM336HP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Consider having numbers.Real provide __complex__?

[Neil Girdhar]

I've been following along various issues in mypy regarding challenges with 
getting the ABCs in numbers 
(https://docs.python.org/3/library/numbers.html) working.  Currently, 
there's a lot of clever logic in the functions int, float, and complex.
Currently, inheriting from Real doesn't give you __complex__.  This is 
because the complex function doesn't need it—it falls back to __float__.  I 
think it would be nice if it did for the purpose of type annotations.

Best,

Neil
___
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/CWELU3VHQKGW55MVA5RUHGMPUKKQ5P45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Multiple dispatch for comparison operators?

[Neil Girdhar]

The way I understand it, multiple dispatch is programming language feature 
wehreby a function or method overload is chosen based on run time types.  
Python already has single dispatch (functools.singledispatch).  It also has 
the concept of overloads for type annotations (typing.overload).

My main motivation for suggesting multiple dispatch for Python is to 
simplify writing comparison operators and to facilitate mypy's ability to 
understand them.

Python has a long history of writing comparison operators like this:

class X:
def __lt__(self, other: Any) -> bool:
if isinstance(other, X):
return self.a < other.a
return NotImplemented

Thanks to modern type annotations, multiple dispatch could allow something 
like this:

def __lt__(lhs: X, rhs: X) -> bool:
return lhs.a < rhs.a

Essentially, in most cases of implementing comparison operators, the user 
implements the dispatching with a little help from the interpreter thanks 
to "return NotImplemented".

One benefit of double dispatch would be addressing typing annotation 
problems like this: https://github.com/numpy/numpy/issues/17368.  A type 
checker cannot know the return type of the comparison operators.  Even in 
general, a type checker can't know whether two types are comparable.

Multiple dispatch is one of Julia's main selling points compared with 
Python.  They make some convincing arguments here: 
https://www.youtube.com/watch?v=kc9HwsxE1OY.

What I'm wondering is whether there's any possibility in Python's distant 
future for implementing comparison operators using double dispatch?  
Besides being simpler, type checkers like mypy would have an easier time 
inferring types.  The major drawback is backwards compatibility.  Is there 
a way to craft things so that old style comparison operators could co-exist 
with new style ones?

Best,

Neil

___
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/UKBZLKEBMLNZ7X5BHS2WU4IZYG65XZNP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Neil Girdhar]

You might be interested in https://pypi.org/project/extended-int/

On Sunday, September 6, 2020 at 12:41:04 AM UTC-4 Cade Brown wrote:

> Fair enough, I guess people have managed without it and there are plenty 
> of "good-enough" solutions for this that can be used in the place.
>
> I can see it's probably not worth any code breakage for a more 'pure' 
> design that ultimately is more of an aesthetic problem than one which is 
> preventing real programs from being written
>
> On Sat, Sep 5, 2020, 11:02 PM Guido van Rossum  wrote:
>
>> On Sat, Sep 5, 2020 at 5:21 PM Cade Brown  wrote:
>>
>>> [...] we could spent all day going over particular cases which the repr 
>>> -> eval identity doesn't hold. However I still think that, as a principle, 
>>> it's a solid one. I think changing the repr of 'inf' to 'float('inf')' is a 
>>> decent solution (but keeping str conversion the same).
>>>
>>> So, I guess in order to reduce backwards incompatibility, the repr could 
>>> be modified to return a string which actually generates an infinite value
>>>
>>
>> I would assume that there's a lot of code, much of it not written in 
>> Python, that has been written to specifically look for this "inf" string. 
>> So I don't think we should change it. And making the repr() of floats 
>> different from their str() just in this one special case sounds like a bad 
>> idea too.
>>
>> I don't think we could fix this one without making 'inf' a builtin 
>> constant, and I don't like that option at all. I also don't think this is 
>> quite as big a deal as it seems to have become in your head. So please put 
>> it to rest. There are many other worthy causes.
>>  
>> -- 
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)* 
>> 
>>
>___
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/7STUE2W3ZRSHAFKM6ZM7M6A2PS6JUUKL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Consider allow functools.singledispatch to work with typing.Union?

[Neil Girdhar]

Julia's burgeoning popularity has renewed my interest in dynamic dispatch.  
It seems to me that many methods that have been written as a giant switch 
on types can more clearly be written using dynamic dispatch.  It was 
prettty exciting to see that Python already has single dispatch built in, 
and that it supports type annotations!

Would it be possible and desirable to extend it slightly to support Union 
types?

---

In [1]: from functools import singledispatch

In [3]: from typing import Any, Union

In [4]: @singledispatch
   ...: def a(x: Any):
   ...: print("a")
   ...: 

In [5]: class X: pass

In [6]: class Y: pass

In [7]: @a.register
   ...: def _(x: Union[X, Y]):
   ...: print("b")
   ...: 
---
TypeError Traceback (most recent call last)
 in 
  1 @a.register
> 2 def _(x: Union[X, Y]):
  3 print("b")
  4 

~/.pyenv/versions/3.8.5/lib/python3.8/functools.py in register(cls, func)
858 argname, cls = next(iter(get_type_hints(func).items()))
859 if not isinstance(cls, type):
--> 860 raise TypeError(
861 f"Invalid annotation for {argname!r}. "
862 f"{cls!r} is not a class."

TypeError: Invalid annotation for 'x'. typing.Union[__main__.X, __main__.Y] 
is not a class.

___
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/HF5HDXQ2SXZHO3TWODIRQATTE4TCAWPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Default behavior for random.sample when no k

[Neil Girdhar]

Can you not just use 
https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.random_permutation
 ?

On Saturday, August 1, 2020 at 2:26:23 PM UTC-4 Ram Rachum wrote:

> I would also prefer a `random.shuffled` function. The reason I didn't 
> propose it is because there's usually more resistance for adding new 
> functions. But in my view that'll be the best solution.
>
> On Sat, Aug 1, 2020 at 9:17 PM Alex Hall  wrote:
>
>> I agree that calling random.shuffle imperatively is annoying. But I don't 
>> think your proposed solution is readable. You're not taking a sample. A 
>> sample generally implies a strict subset, usually quite a small one.
>>
>> I've often thought there should just be a `random.shuffled()` function 
>> which returns a shuffled copy, similar to `.sort()` and `sorted()` or 
>> `.reverse()` and `reversed()`.
>>
>> On Sat, Aug 1, 2020 at 7:59 PM Ram Rachum  wrote:
>>
>>> When writing some code now, I needed to produce a shuffled version of 
>>> `range(10, 10 ** 5)`.
>>>
>>> This is one way to do it: 
>>>
>>> shuffled_numbers = list(range(10, 10 ** 5))
>>> random.shuffle(shuffled_numbers)
>>>
>>>
>>> I don't like it because (1) it's too imperative and (2) I'm calling the 
>>> list "shuffled" even before it's shuffled.
>>>
>>> Another solution is this: 
>>>
>>> shuffled_numbers = random.sample(range(10, 10 ** 5), k=len(range(10, 10 
>>> ** 5)))
>>>
>>> This is better because it solves the 2 points above. However, it is 
>>> quite cumbersome.
>>>
>>> I notice that the `random.sample` function doesn't have a default 
>>> behavior set when you don't specify `k`. This is fortunate, because we 
>>> could make that behavior just automatically take the length of the first 
>>> argument. So we could do this: 
>>>
>>> shuffled_numbers = random.sample(range(10, 10 ** 5))
>>>
>>> What do you think? 
>>>
>>>
>>> Thanks,
>>> Ram.
>>> ___
>>> Python-ideas mailing list -- python...@python.org
>>> To unsubscribe send an email to python-id...@python.org
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> Message archived at 
>>> https://mail.python.org/archives/list/python...@python.org/message/OHLXVKIBMNSQO6BCFK6LEHSYNXDB6OQJ/
>>>  
>>> 
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>___
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/RG346EKJMPYZAI6PHCCZRKOIJUIML3HB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Neil Girdhar]

What the future of this?

I looked at type annotations in networkx recently (
https://github.com/networkx/networkx/pull/4014), and I wanted to keep 
things simple, so I proposed and implemented

Graph[NodeType]

However, I knew that they may ultimately want

Graph[NodeType, EdgeTypedDict, NodeTypedDict]

but no one is going to want to replace their calls with

Graph[str, dict[str, Any], dict[str, Any]]

That's what too noisy.

This proposal would allow you to have default parameters.  But what's the 
future looking like now?  Do we expect to have a type constructor?

class Graph:
def T(node_type, edge_type_dict=..., node_type_dict=...) -> a type 
annotation

And then

g: Graph.T(whatever) = Graph()

Does that work?

On Friday, July 10, 2020 at 4:20:58 AM UTC-4, Stefano Borini wrote:
>
> I am one of the authors of the PEP. My problem was to deal with 
> natural notation in quantum chemistry mostly. It had no technical 
> purpose, but I still think it would open some interesting options. 
> The PEP was rejected mostly because of lack of interest. 
>
> On Mon, 4 May 2020 at 00:07, Andras Tantos  > wrote: 
> > 
> > Hello! 
> > 
> > I'm not sure I'm addressing the right audience here, so please direct me 
> to the appropriate channel if that's the case... 
> > 
> > My name is Andras Tantos and I'm working on a Python library desscribing 
> HW designs. I came across this problem of __getitem__ and co. not 
> supporting kwargs. Apparently this extension was proposed and rejected as 
> PEP 472. 
> > 
> > Apart from my use-case, which is arguably a corner-case and not worth 
> modifying the language for, I believe there are two important use-cases 
> that are worth considering with the latest improvements in the language: 
> > 
> > 1. With the recent type-hint support, the feature could be made way more 
> descriptive if this PEP got implemented. 
> > 
> > For example, instead of doing the following: 
> > 
> > def func(in: Dict[str, int]) 
> > 
> > one could write: 
> > 
> > def func(in: Dict[key=str, value=int]) 
> > 
> > 2. It would also make 'generic classes' much cleaner to implement, 
> similar to the way type-hints look. Consider the following code: 
> > 
> > class _Generic(object): 
> > Specializations = [] 
> > @classmethod 
> > def __getitem__(cls, *args): 
> > name = f"Generic_{len(cls.Specializations)}" 
> > Specialized = type(name, (cls,), {"specials": tuple(args)}) 
> > cls.Specializations.append(Specialized) 
> > return Specialized 
> > def __init__(self, value = None): 
> > self.value = value 
> > def __str__(self): 
> > if hasattr(self, "specials"): 
> > return(f"[{type(self)} - " + ",".join(str(special) for special in 
> self.specials) + f"] - {self.value}") 
> > else: 
> > return(f"[{type(self)} - GENERIC" + f"] - {self.value}") 
> > Generic = _Generic() 
> > #g = Generic() - fails because of no specialization is given 
> > s1 = Generic[12]() 
> > s2 = Generic[42]("Hi!") 
> > print(s1) 
> > print(s2) 
> > 
> > Running this simple example results in: 
> > 
> > python3 -i python_test.py 
> > [ - 12] - None 
> > [ - 42] - Hi! 
> > 
> > You can see how the specialized parameters got passed as well as the 
> ones to '__init__'. Obviously, in real code the idea would be to filter 
> generic parameters and set up 'Specialized' with the right set of methods 
> and arguments. 
> > 
> > Now, without kwargs support for __getitem__, it's impossible to pass 
> named arguments to the specialization list, which greatly limits the 
> usability of this notation. 
> > 
> > I don't know how convincing these arguments and use-cases are for you, 
> but could you advise me about how to start the 'ball rolling' to drum-up 
> support for re-activating this PEP? 
> > 
> > Thanks again, 
> > Andras Tantos 
> > 
> > 
> > ___ 
> > Python-ideas mailing list -- python...@python.org  
> > To unsubscribe send an email to python-id...@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/6OGAFDWCXT5QVV23OZWKBY4TXGZBVYZS/
>  
> > Code of Conduct: http://python.org/psf/codeofconduct/ 
>
>
>
> -- 
> Kind regards, 
>
> Stefano Borini 
> ___ 
> Python-ideas mailing list -- python...@python.org  
> To unsubscribe send an email to python-id...@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/UHVZLOU57HS2HGH6E4JCDW6ETAIORKG7/
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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 

[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?

[Neil Girdhar]

Are all objects in Python equality-comparable?  I know that you can delete 
__hash__ to make an object unhashable (e.g., dicts).  If so, this is a 
great addition.

On Saturday, July 4, 2020 at 5:26:45 PM UTC-4, Joao S. O. Bueno wrote:
>
>
>
> On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka  > wrote:
>
>> 30.06.20 18:58, Joao S. O. Bueno пише:
>> > I ended up writting an __eq__ - and in the process I found it is not 
>> > _that_ straightforward  due
>> > to  having to check subclasses types when comparing.
>> > (given Base sequence A, child class B(A), class C(A) and class B1(B) - 
>> > Instances of B and B1 can be
>> > equal, but instances of B and C should always be different) - or in 
>> > Python, inside __eq__ :
>> >  if not issubclass(type(other), type(self)) and not 
>> > issubclass(type(self), type(other)):
>> >  return False
>>
>> It would be more correct to return NotImplemented.
>>
>> Also, it is enough to test isinstance(other, type(self)) because 
>> other.__eq__(self) be called first if the type of other is a subclass of 
>> the type of self.
>>
>
> Ah - yes. Half the logic is already on the __eq__ semantics - thanks.
> Well, I am updating that on my code right now. 
>
> Anyway I am not seeing anyone opposing this going into col...abc.Sequence 
> - 
> Maybe it is ok for a BPO?  
>
> (yes, there is this consideration I had, and also Guido,
> that it would create new behavior in classes that already exist, but I saw
>  no way that could break code not specially crafted to  break with this 
> change.)
>
>
> ___
>> Python-ideas mailing list -- python...@python.org 
>> To unsubscribe send an email to python-id...@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/K2P4ZWF6FIRPCRKUH7IHZHMC7E3HVJER/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>___
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/FXJWTXQWTW7C32JBEBOIYLYOXVDLTQ2P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Should use of _ as an R-value be deprecated?

[Neil Girdhar]

Oh, I guess there's gettext…

On Monday, June 29, 2020 at 5:04:05 AM UTC-4, Neil Girdhar wrote:
>
> PEP 622 proposes a special use for _: to match anything, discarding the 
> whatever value matches.  (If I understand.)  This aligns with the way _ is 
> conventionally used in other statements.  This special use in case 
> statements feels weird given that _ is otherwise just an ordinary 
> variable.  It may even have a value going into the case/match statement, 
> which would be ignored.
>
> Has there been any discussion on deprecating use of _ as an R-value?  In 
> other words, making _ a "black hole" variable "preposition" into which 
> values go but never come out?  Besides the benefit of unifying the 
> conventional use of _ with its proposed use  in case/match statements, 
> another benefit for CPython would be that _ would no longer hang onto 
> references and would therefore not prevent garbage collection of whatever 
> was put into it.
>
> Best,
>
> Neil
>
___
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/M7VMC77RTTXAHLVUUL2IZRBV64WOD65M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Should use of _ as an R-value be deprecated?

[Neil Girdhar]

PEP 622 proposes a special use for _: to match anything, discarding the 
whatever value matches.  (If I understand.)  This aligns with the way _ is 
conventionally used in other statements.  This special use in case 
statements feels weird given that _ is otherwise just an ordinary 
variable.  It may even have a value going into the case/match statement, 
which would be ignored.

Has there been any discussion on deprecating use of _ as an R-value?  In 
other words, making _ a "black hole" variable "preposition" into which 
values go but never come out?  Besides the benefit of unifying the 
conventional use of _ with its proposed use  in case/match statements, 
another benefit for CPython would be that _ would no longer hang onto 
references and would therefore not prevent garbage collection of whatever 
was put into it.

Best,

Neil
___
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/B5W3ZNF4RCJYQP3QNKLMWUXBU2SY4UWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Neil Girdhar]

Can you use SortedDict.peekitem(index): 
http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html ?

As other people are saying, the computational complexity of CPython's dict 
is linear for this operation.  SortedDict does it in logarithmic time.

On Friday, June 26, 2020 at 1:32:58 PM UTC-4, Hans Ginzel wrote:
>
> Date: Fri, 26 Jun 2020 18:47:44 +0200 
> From: Hans Ginzel > 
> To: Hans Ginzel > 
> Subject: Access (ordered) dict by index; insert slice 
>
> Hello, 
>
> thank you for making dict ordered. 
> Is it planned to access key,value pair(s) by index? See 
> https://stackoverflow.com/a/44687752/2556118 for example. Both for 
> reading and (re)writing? 
> Is it planned to insert pair(s) on exact index? Or generally to slice? See 
> splice() in Perl, https://perldoc.perl.org/functions/splice.html. 
>
> Use case: Represent database table metadata (columns). It is useful as to 
> access columns both by name and by index as to insert column on specific 
> position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, 
> “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or 
> table storage size optimisation by aligning). 
>
> Thank you in advance, 
> Hans 
> PS1: Named tuples cannot be used, are immutable. 
> PS2: See 
> https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/OFTBN3Y5PYGBJ6IMEQB75ZDZAUMQS5A4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Please consider adding numbers.Boolean

[Neil Girdhar]

I'm just curious if there was a reason why Boolean was omitted from the 
numeric tower in the numbers library?  It seems that builtins.bool and 
numpy.bool_ would both be elements of Boolean, and Boolean itself would be 
Integral?

Best,

Neil
___
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/X4JVLL3J2U36MPGWFB3Z4HWZEWONAH43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bringing the print statement back

[Neil Girdhar]

Nevertheless, it's nice to see how powerful the new parser is!

Any chance this would allow us to have a multi-line with statement?

with self.context_manager_one(some, parameters, that, are, passed) \
as return_value_one, \
self.context_manager_two(self.p, slice(None), None) \
as return_value_two:

but with parentheses instead of backslash continuations?

On Wednesday, June 10, 2020 at 12:55:01 PM UTC-4, Guido van Rossum wrote:
>
> On Tue, Jun 9, 2020 at 6:33 PM Greg Ewing  > wrote:
>
>> Why is this being proposed?
>>
>> I think we would need a very strong reason to consider this,
>> and so far I haven't seen any justification other than "because
>> we can".
>>
>
> There was definitely something of that... I was looking at the new PEG 
> parser and realized that *if people wanted it* this would be easy to do. So 
> I spent a pleasant hour or two coding it up to my satisfaction.
>
> But I was also trying to satisfy some demand. When Python 3 was young, 
> print becoming a function  was one of the most frequent complaints, and 
> it's still occasionally seen on Twitter. I found at least two StackOverflow 
> issues about it, but the combined upvote count was less than 100.
>
> An early post in this thread reminded me that IPython has a feature called 
> "autocall" that allows exactly this syntax. I don't know how popular it is. 
> However, apparently there the form `f x+1` ends up calling `f("x+1")` (i.e. 
> stringifying the argument), so introducing similar syntax in Python with 
> different semantics would hardly be helpful. (If someone wants to start a 
> debate on argument quoting, please start a new thread, so we can lay this 
> one to rest.)
>
> All in all, it's clear that there's no future for this idea, and I will 
> happily withdraw it.
>
> -- 
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)* 
> 
>
___
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/GE2A256YFTMSSYOQLURCTKZZGL4ZQMG7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Neil Girdhar]

Have you seen PEP 505?  https://www.python.org/dev/peps/pep-0505/

I'm still praying they add "??=" every time I need it.

Maybe if someone proposed just that operator, it would go a long way 
towards simplifying code without resulting in endless debates?

Best,

Neil


On Sunday, May 17, 2020 at 3:23:59 PM UTC-4, James Lu wrote:
>
> Many a python programmer have tired to see code written like: 
>
> def bar(a1, a2, options=None): 
> if options is None: 
>options = {} 
> ... # rest of function 
>
> syntax if argument is not passed, evaluate {} and store to options 
> def foo(options:={}): pass 
> syntax if argument is not passed or is None, evaluate {} and store to 
> options* 
> def foo(options?={}): pass 
>
> The Zen of Python states "there shouldn't be two ways to do the same 
> thing." 
>
> Thus, only one of ":=" or "?=" should be adopted. They should be evalued 
> on: 
>  - Which encourages writing better code? 
>  - Which catches mistakes easier? 
>
> Do we want to encourage callers to pass None to indicate default 
> arguments? 
>
> spam = { data: True } if arg else None 
> bar(a1, a2, param=spam) 
>
> versus 
>
> bar(a1, a2, { data: True }) if arg else bar(a1, a2) 
>
> versus 
>
> _ = foo.curry(a1, a2) 
> _({data: True}) if arg else _(a1, a2) 
>
> Since Python is a strongly typed language, it seems more consistent to me 
> that 
> this code should throw an error: 
> def getoptions(): 
> ... # code to get options 
> # whoops! missing return statement 
> #return os.environ 
> foo(a1, a2, param=getoptions()) 
>
> := should be adopted because it catches mistakes more quickly. 
>
> On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." 
> idiom. 
>
> (I propose adopting only ":=". I show "?=" as a strawman.) 
> ___ 
> Python-ideas mailing list -- python...@python.org  
> To unsubscribe send an email to python-id...@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/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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/REIWV2QL42JVLJYLRBPCAINRJYMDWF6H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

[Neil Girdhar]

I'm just curious, but is it usual for errors to be one-based rather than 
zero-based?  If I do zip(*iterables, strict=True), then "argument  1 is too 
long" refers to iterables[0]? 

On Friday, May 1, 2020 at 2:20:12 PM UTC-4, Brandt Bucher wrote:
>
> I have pushed a first draft of PEP 618: 
>
> https://www.python.org/dev/peps/pep-0618 
>
> Please let me know what you think – I'd love to hear any *new* feedback 
> that hasn't yet been addressed in the PEP! 
>
> Brandt
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/ZBB5L2I45PNLTRW7CCV4FDJO5DB7M5UT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/3ZXTCHVRXDVWZ5VB6YBMZ2Z3FF7PL7RQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Should dataclass init call super?

[Neil Girdhar]

I'm just curious:  what is the downside of calling super with kwargs?
Usually when I define a class, the first I write is

def __init__(self, **kwargs):
super().__init__(**kwargs)

just in case I want to use the class in cooperative inheritance.  I always
thought it couldn't hurt?

I might be alone in this interpretation, but I imagine that there are three
fundamental kinds of inheritance patterns for methods, which I defined in
my ipromise package (https://pypi.org/project/ipromise/): implementing an
abstract method, overriding, and augmenting.  If I had to choose, I would
say that __init__ should be an "augmenting" pattern.

Therefore, it seems weird for __init__ not to call super.  Even if you want
Y t to override some behavior in X, what happens if Z inherits from Y and
W?  Now, Y.__init__'s decision not to call super would mean that W.__init__
would not be called.  That seems like a bug.  Instead, I would rather put
the behavior that Y wants to override in a separate method, say X.f, which
is called in X.__init__.  Now, if Y.f overrides X.f, everything is okay.
Even if Z inherits from Y and W, the override still works, and W.__init__
still gets called, angels sing, etc.

Long story short, am I wrong to interpret __init__ as a "must augment"
method and always call super().__init__(**kwargs)?

On Wed, Apr 15, 2020 at 1:32 PM Andrew Barnert  wrote:

> On Apr 15, 2020, at 04:26, Ricky Teachey  wrote:
>
> 
>
>> For simple situations you can call super in the __post_init__ method and
>>> things will work fine:
>>>
>>
>> But not for the OP's case: he wanted to pass extra parameters in -- and
>> the dataclass' __init__ won't accept extra arguments.
>>
>>
>> Can’t you just create InitVar attributes for the extra args you want to
>> pass through in that case?
>>
>
> InitVar fields for all the desired parent class init parameters can often
> solve the problem.
>
> But it can be painful to have to manually provide every parameter
> explicitly when normally (when not using a dataclass) you'd just add *args
> and **kwargs to the init signature and call super().__init__(*args,
> **kwargs).
>
>
> To handle that case, couldn’t we just add InitVarStar and InitVarStarStar
> fields? If present, any extra positional and/or keyword args get captured
> for the __postinit__ to pass along just like normal InitVars.
>
> I think that could definitely be useful, but not as useful as you seem to
> think it would be.
>
> It becomes more painful the more parameters the parent has- parameters
> which the dataclass may not even care about. It not only makes the class
> definition long, it adds so these additional parameters to the init
> signature, which is icky for introspection and discoverability. Lots of
> "What the heck is this parameter doing here?" head scratching for future me
> (because I forget everything).
>
>
> I think that’s backward. The signature is there for the user of the
> dataclass, not the implementer. And the user had better care about that x
> argument, because it’s a mandatory parameter of the X class, so if they
> don’t pass one, they’re going to get an exception from inside some class
> they never heard of. So having x show up in the signature would be helpful
> for introspection and discovery, not harmful. It makes your users ask “What
> the heck is the x parameter doing here?” but that’s a question that they’d
> better have an answer to or they can’t construct a Y instance. (And notice
> that the X doesn’t take or pass along *args, so if the Y claims to take
> *args as well as **kwargs, that’s even more misleading, because passing any
> extra positional args to the constructor will also raise.) And that’s as
> true for tools as for human readers—an IDE auto-completing the parameters
> of Y(…) should be prompting you for an x; a static analyzer should be
> catching that you forgot to pass as x; etc.
>
> There are cases where you need *args and/or **kwargs in a constructor. But
> I don’t think they make sense for a dataclsss. For example, you’re not
> going to write a functools.partial replacement or a generic RPC proxy
> object as a dataclass.
>
> But there are cases where you _want_ them, just out of… call it
> enlightened laziness. And those cases do seem to apply to dataclass at
> least as much as normal classes. And that’s why I think it could be worth
> having these new fields. The OP’s toy example looks like part if a design
> where the X is one of a bag of mixins from some library that you compose up
> however you want in your app.
>

You got it.


> It would be more discoverable and readable if the final composed Y class
> knew which parameters its mixins demanded—but it may not be worth the
> effort to put that together (either manually, or programmatically at class
> def time). If your Y class is being exposed as part of a library (or RPC or
> bridge or whatever), or it forms part of the connection between two key
> components in an air traffic control system, then you probably do want to
> 

[Python-ideas] Should dataclass init call super?

[Neil Girdhar]

Dear Pythoners,

class X:
def __init__(self, x, **kwargs):
super().__init__(**kwargs)
print(x, kwargs)



@dataclass
class Y(X):
y: int


Y(1)  # What should happen?
Y(1, 2)  # What should happen?


I feel like it would be nice to be able to use dataclasses more often 
without worrying that you cannot use dataclasses in cooperative 
inheritance.  Perhaps, dataclasses could call super with unused args and 
kwargs?

Best,

Neil
___
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/6YMRI4BJDTZZTWM6XQ6EQDZ47RWX4C7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add the imath module

[Neil Girdhar]

I mean:

def binom(n, *ks):
# Check that there is at least one ki, and that their sum is less than 
n, and that they are all nonnegative.
# Returns n! / (prod(ki! for ki in ks) * (n-sum(ks))!)

This would still work for binom(n, k), but would also work for the 
mulinomial case.

On Sunday, March 22, 2020 at 2:01:18 PM UTC-4, Neil Girdhar wrote:
>
> I really like this idea.  It fixes the weirdness whereby cmath is for 
> complex numbers, and math is for real numbers and integers.  I like 
> separating them into three categories.
>
> One suggestion: Consider generalizing binom to the multinomial coefficent.
>
> def binom(n, *ks):
> # Returns n! / prod(ki! for ki in ks)
>
> Best,
>
> Neil 
>
> On Thursday, July 12, 2018 at 7:57:08 AM UTC-4, Serhiy Storchaka wrote:
>>
>> What are your thoughts about adding a new imath module for integer 
>> mathematics? It could contain the following functions: 
>>
>> * factorial(n) 
>>
>> Is just moved from the math module, but non-integer types are rejected. 
>> Currently math.factorial() accepts also integer floats like 3.0. It 
>> looks to me, the rationale was that at the time when math.factorial() 
>> was added, all function in the math module worked with floats. But now 
>> we can revise this decision. 
>>
>> * gcd(n, m) 
>>
>> Is just moved from the math module. 
>>
>> * as_integer_ration(x) 
>>
>> Equivalents to: 
>>
>> def as_integer_ration(x): 
>>  if hasattr(x, 'as_integer_ration'): 
>>  return x.as_integer_ration() 
>>  else: 
>>  return (x.numerator, x.denominator) 
>>
>> * binom(n, k) 
>>
>> Returns factorial(n) // (factorial(k) * factorial(n-k)), but uses more 
>> efficient algorithm. 
>>
>> * sqrt(n) 
>>
>> Returns the largest integer r such that r**2 <= n and (r+1)**2 > n. 
>>
>> * isprime(n) 
>>
>> Tests if n is a prime number. 
>>
>> * primes() 
>>
>> Returns an iterator of prime numbers: 2, 3, 5, 7, 11, 13,... 
>>
>> Are there more ideas? 
>>
>> ___ 
>> Python-ideas mailing list 
>> python...@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
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/AB6FYCQ6B3BKMJRV5C7BOPIVGON3MWTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add the imath module

[Neil Girdhar]

I really like this idea.  It fixes the weirdness whereby cmath is for 
complex numbers, and math is for real numbers and integers.  I like 
separating them into three categories.

One suggestion: Consider generalizing binom to the multinomial coefficent.

def binom(n, *ks):
# Returns n! / prod(ki! for ki in ks)

Best,

Neil 

On Thursday, July 12, 2018 at 7:57:08 AM UTC-4, Serhiy Storchaka wrote:
>
> What are your thoughts about adding a new imath module for integer 
> mathematics? It could contain the following functions: 
>
> * factorial(n) 
>
> Is just moved from the math module, but non-integer types are rejected. 
> Currently math.factorial() accepts also integer floats like 3.0. It 
> looks to me, the rationale was that at the time when math.factorial() 
> was added, all function in the math module worked with floats. But now 
> we can revise this decision. 
>
> * gcd(n, m) 
>
> Is just moved from the math module. 
>
> * as_integer_ration(x) 
>
> Equivalents to: 
>
> def as_integer_ration(x): 
>  if hasattr(x, 'as_integer_ration'): 
>  return x.as_integer_ration() 
>  else: 
>  return (x.numerator, x.denominator) 
>
> * binom(n, k) 
>
> Returns factorial(n) // (factorial(k) * factorial(n-k)), but uses more 
> efficient algorithm. 
>
> * sqrt(n) 
>
> Returns the largest integer r such that r**2 <= n and (r+1)**2 > n. 
>
> * isprime(n) 
>
> Tests if n is a prime number. 
>
> * primes() 
>
> Returns an iterator of prime numbers: 2, 3, 5, 7, 11, 13,... 
>
> Are there more ideas? 
>
> ___ 
> Python-ideas mailing list 
> python...@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
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/NTSXZQAIC2OLSA2K4HP5N7HSFUNW7ZYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow star unpacking within an slice expression

[Neil Girdhar]

Reviving this old thread since this is hitting me again today.  Is there 
any momentum on extending tuple unpacking to within slices?


On Thursday, December 21, 2017 at 4:33:07 PM UTC-5, Neil Girdhar wrote:
>
> I didn't think of this when we were discussing 448.  I ran into this 
> today, so I agree with you that it would be nice to have this.
>
> Best,
>
> Neil
>
> On Monday, December 4, 2017 at 1:02:09 AM UTC-5, Eric Wieser wrote:
>>
>> Hi,
>>
>> I've been thinking about the * unpacking operator while writing some 
>> numpy code. PEP 448 allows the following:
>>
>>values = 1, *some_tuple, 2
>>object[(1, *some_tuple, 2)]
>>
>> It seems reasonable to me that it should be extended to allow
>>
>>item = object[1, *some_tuple, 2]
>>item = object[1, *some_tuple, :]
>>
>> Was this overlooked in the original proposal, or deliberately rejected?
>>
>> Eric
>>
>___
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/3737BQS7QFRLGE5CHQQNL3DVLLIMYH6R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: More descriptive error message than "too many values to unpack"

[Neil Girdhar]

I also would prefer richer exceptions especially if it can be done without 
introducing any other problems.

In the same vein, I once suggested a richer inheritance failure message 
(this, basically: https://github.com/NeilGirdhar/inheritance_graph), for 
which if I remember correctly Guido was mildly supportive.  I didn't have 
time to make a proposal patch.

On Monday, March 2, 2020 at 4:32:35 PM UTC-5, Sebastian Kreft wrote:
>
> There was a proposal (by me) some time ago to add some structured 
> information to some of the Exceptions. See 
> https://www.python.org/dev/peps/pep-0473/, but it finally got rejected 
> due to being too broad. I'd be happy to revive (parts of) the proposal if 
> anyone is interested.
>
> I managed though to create a PR adding a name attribute to NameError, see 
> https://github.com/python/cpython/pull/6271 and 
> https://bugs.python.org/issue37797.
>
> On Mon, Mar 2, 2020 at 6:01 PM Alex Hall > 
> wrote:
>
>>
>>
>> On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker > > wrote:
>>
>>> That being said, more information is better than less, so maybe an 
>>> unpacking error should show the *value* of what was being unpacked:
>>>
>>> >>> a, b = 1, 2, 3
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> ValueError: too many values to unpack (expected 2)
>>>
>>> Which, in fact, is what iPython already does:
>>>
>>> In [5]: a,b = 1,2,3 
>>>
>>>
>>> ---
>>> ValueErrorTraceback (most recent call 
>>> last)
>>>  in 
>>> > 1 a,b = 1,2,3
>>>
>>> ValueError: too many values to unpack (expected 2)
>>>
>>
>> The only extra thing IPython is doing here is showing the source line, 
>> which it can do because it saves the input in linecache. The standard shell 
>> never saves its input so it never shows in tracebacks. I do think that's an 
>> issue, but if you ran these examples in files you'd get the same amount of 
>> information either way.
>>
>> (cause it's showing the line of code, not the run time values)
>>>
>>
>> There are many tools which enhance tracebacks with local variables. Even 
>> the standard traceback module can do it. But of course improving the 
>> default experience with just the right amount of information would be 
>> ideal. 
>>  
>>
>>> So if possible, it would be great if error messages did generally show 
>>> the value(s) of the objects involved, if possible.
>>>
>>> Then that would be:
>>>
>>> ValueError: too many values to unpack (expected 2, got : 'this')
>>>
>>> Given that it's a ValueError, it seem the *value* should be known, and 
>>> generally relevant.
>>>
>>> And this is already done for some ValueErrors:
>>>
>>> In [3]: i = int('45f')   
>>>
>>>
>>> ---
>>> ValueErrorTraceback (most recent call 
>>> last)
>>>  in 
>>> > 1 i = int('45f')
>>>
>>> ValueError: invalid literal for int() with base 10: '45f'
>>>
>>> Maybe it should be for ALL Value Errors? 
>>>
>>
>> In general Python error messages don't include the relevant values or 
>> much information about them, although I often wish they would. For example 
>> when I get a KeyError I wish I could see which keys are present, unless 
>> there's too many for it to be practical. I'm speculating, but I think there 
>> are two main reasons for this:
>>
>> 1. To avoid executing arbitrary __repr__ methods.
>> 2. To avoid the performance cost of creating a message for an exception 
>> that may be caught and thrown away.
>>
>> Neither of these really apply to int('45f').
>>
>> Are there any other major reasons for the general lack of information? It 
>> feels like an intentional decision beyond implementation difficulty. I 
>> imagine we can work around both reasons:
>>
>> 1. There's a lot of information that can be extracted and displayed 
>> without running any user defined code.
>> 2. Objects can be saved (such as the dict that raised KeyError) while 
>> deferring the message rendering until it's requested.
>> ___
>> Python-ideas mailing list -- python...@python.org 
>> To unsubscribe send an email to python-id...@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/SLIFGO4FSMAM4AMZZX3B4Y3YQCNZACPE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> -- 
> Sebastian Kreft
>
___
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 

[Python-ideas] Re: Traits

[Neil Girdhar]

You may be interested in the excellent traitlets library: 
https://traitlets.readthedocs.io/en/stable/

On Friday, February 7, 2020 at 11:11:59 AM UTC-5, Soni L. wrote:
>
> I'd like to see traits some day, with a syntax similar to this one: 
>
> trait Trait: 
>def x(self): 
>  raise NotImplementedError 
>def y(self): 
>  raise NotImplementedError 
>
> trait Anoher: 
>def x(self): 
>  raise NotImplementedError 
>def y(self): 
>  raise NotImplementedError 
>
> def foo(Trait(x)): 
>x.x() 
>
> class Bar: 
>def y(self): 
>  print("hello") 
>impl Trait: 
>  def x(self): 
>self.y()  # resolves to Bar.y 
>impl Another: 
>  def x(self): 
>raise ValueError 
>
> foo(Bar())  # prints 'hello' 
> Trait(Bar()).x()  # also prints 'hello' 
> Bar().x()  # AttributeError: ambiguous reference to trait method x 
>
> if the trait isn't used in the function definition you get the raw 
> object, where name conflicts between traits (but not between traits and 
> inherent methods) result in an error about name conflicts. otherwise you 
> get a friendly wrapper. 
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/MMTEZRNSPHB55IYCKJ2E2CXDRN7KYURC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/F2MKZJ4QTGB7RC6JE4H3I3MTVAFMDU6T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggestion for language addition

[Neil Girdhar]

On Tuesday, December 3, 2019 at 7:54:03 PM UTC-5, Jan Bakuwel wrote:
>
> Hi Guido, 
>
> On 4/12/19 1:06 pm, Guido van Rossum wrote: 
> > I was playing the devil's advocate in jest. There is no way this will 
> > be added to Python, for a large variety of sociological and software 
> > engineering reasons. While some of the responses may to you seem like 
> > they come from inexperienced people who have not carefully read your 
> > argument, consider that to us, your proposal appears to come from yet 
> > another person who is relatively new to Python asking for their 
> > favorite feature from language X without understanding how that 
> > feature would interact with the rest of Python. 
>
> I was not implying at all that any response was from inexperienced 
> people. However no-one, at least not in a way clear to me, responded to 
> the value of the suggestion to get early warnings (ie. at parse time) 
> when an "end while" is written where an "end if" should have been written. 
>

I can see how you would find it useful, and I can also see why you're 
getting a lot of opposition.

One compromise suggestion is to take Andrew's advice and add your own  # 
end for's.  Then take Serhiy's advice and add the check to a linter.  After 
you've been coding like this for a while, start your movement to popularize 
"# end for" :)
 

>
> While I like Python a lot, I do miss the support of advanced compilers 
> that tell me at compile time where I made a typo or logic error so I 
> find myself spending relatively more time debugging at runtime. Not a 
> worry as Python easily makes up for the lost time for 1000+ reasons. I'm 
> just thinking aloud how it could, in my eyes, be even better while also 
> considering the sociological and software engineering impact on the 
> Python community to the best of my abilities. 
>
> I appreciate that I have much less experience with Python than many of 
> the folks on the list here. So please help me understand how the 
> suggested feature would, in any way, unfavorably interact with the rest 
> of Python as you say. 
>
> cheers, 
>
> Jan 
>
> ___ 
> Python-ideas mailing list -- python...@python.org  
> To unsubscribe send an email to python-id...@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/WH4TOP57AZSMRQG26YRWHDMDBEXV5WQV/
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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/4LMK2RQMFIG6FJPWNWZPW3KM53CC5RWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: __repr__ helper(s) in reprlib

[Neil Girdhar]

I really like this feature suggestion and I would definitely use it if it 
were available.

It might be easiest to have the repr helper do as much as it can, but give 
the user the flexibility to override things with varying levels of 
precision.  For example:

def kwargs(obj,
   keys: Optional[Collection[str]] = None,
   keys_values: Optional[Mapping[str, Any]] = None,
   *,
   qualified=True):
if keys is None and keys_values is None:
pass  # Fallback?
keys_strings = (
[]
if keys is None
else [(k, repr(getattr(obj, k))) for k in keys])
keys_strings += (
[]
if keys_values is None
else [(k, repr(v)) for k, v in keys_values.items()])
class_name = (obj.__class__.__qualname__
  if qualified
  else obj.__class__.__name__)
parameters = ", ".join(
f"{k}={v}" for k, v in keys_strings)
return f"{class_name}({parameters})"




On Tuesday, January 21, 2020 at 10:33:43 PM UTC-5, Andrew Barnert via 
Python-ideas wrote:
>
> On Jan 21, 2020, at 14:30, Chris Angelico > 
> wrote: 
> > 
> > On Wed, Jan 22, 2020 at 9:17 AM Andrew Barnert  > wrote: 
> >> 
> >>> On Jan 21, 2020, at 12:29, Chris Angelico  > wrote: 
> >>> 
> >>> For non-dataclass classes, it would be extremely helpful to have an 
> >>> easy helper function available: 
> >>> 
> >>> class Spam: 
> >>>  def __repr__(self): 
> >>>  return reprlib.kwargs(self, ["quality", "recipe", "ham"]) 
> >>> 
> >>> The implementation for this function would be very similar to what 
> >>> dataclasses already do: 
> >>> 
> >>> # in reprlib.py 
> >>> def kwargs(obj, attrs): 
> >>>  attrs = [f"{a}={getattr(obj, a)!r}" for a in attrs] 
> >>>  return f"{obj.__class__.__qualname__}({", ".join(attrs)})" 
> >>> 
> >>> A similar function for positional args would be equally easy. 
> >> 
> >> I like this, but I think it’s still more complex than it needs to be 
> for 80% of the cases (see below) 
> > 
> > IMO that's not a problem. The implementation of reprlib.kwargs() is 
> > allowed to be complex, since it's buried away as, well, implementation 
> > details. As long as it's easy to call, that's all that matters. 
>
> Sorry, I didn’t mean the implementation, I meant the interface. You 
> shouldn’t have to specify the names in simple cases, and there are no 
> correct names to specify in more complicated cases, and the range in which 
> names are useful but also necessary seems pretty narrow. 
>
> Even this example can’t work with your kwargs function: 
>
> class Spam 
> def __init__(self, x): 
> self._x = x 
> def __repr__(self): 
> return kwargs(self, '_x'.split()) # or 'x'.split() 
>
> You want the repr to be `Spam(x=3)`, but there’s no way to get that. If 
> you use _x you get `Spam(_x=3)`, which is wrong; if you use x you get an 
> AttributeError, which nobody wants from repr. 
>
> >> while for the other 20%, I think it might make it too easy to get 
> things wrong. 
> > 
> > Hmm. I kept it completely explicit - it will generate a repr that 
> > shows the exact attributes listed (and personally, I'd often write it 
> > as "quality recipe ham".split()), 
>
> Right, but that’s exactly what makes it easy to get wrong. If I add a new 
> param and attribute with a default value and don’t remember to also add it 
> to the repr, I’m now silently generating reprs that look right but aren’t. 
> If I have an attribute that’s computed and include it in repr by accident, 
> likewise. 
>
> >>> Bikeshedding opportunity: Should it be legal to omit the attrs 
> >>> parameter, and have it use __slots__ or fall back to dir(obj) ? 
> >> 
> >> This makes things even more dangerous. It’s very common for classes to 
> have attributes that aren’t part of the constructor call, or constructor 
> params that aren’t attributes, and this would give you the wrong answer. 
> >> 
> >> It would be nice if there were a safe way to get the 
> constructor-call-style repr. And I think there might be for 80% of the 
> types—and the rest can specify it manually and take the risk of getting it 
> wrong, probably. 
> >> 
> >> One option is the pickle/copy protocol. If the type uses one of the 
> newargs methods, you can use that to get the constructor arguments; if it 
> uses one of the other pickling methods (or can’t be pickled), this just 
> doesn’t work. 
> >> 
> >> You could also look at the inspect.signature of __init__ and/or 
> __new__. If every param has an attribute with the same name, use that; 
> otherwise, this doesn’t work. 
> >> 
> >> And if none of the automatic ways worked and you tried to use them 
> anyway, you get an error. 
> > 
> > This is definitely getting into the realm of magic. 
>
> I don’t think getnewargs is any more magical than dir is—and it’s correct, 
> and ties into a protocol already used for two other things in Python. 
>
> > The question is, 
> > is it worth the convenience? I'd be +0.25 

[Python-ideas] Re: Target-and-expression lists and if-try

[Neil Girdhar]

This is very cool, well thought-out, and solves an important problem.  I 
would have definitely benefited from Python having better pattern matching.

As an idealist though, if you're going to add pattern matching, why not 
just do it completely?  I agree that your proposal would be useful in some 
cases, but then what happens when someone wants to go just a step farther?  
For example,

def parse(text):
if try "(", *a, ")" = text[i, i+n]:   # how do you set n?  do you try 
them all?
parse(a)  # etc.

and even more complicated:

def parse(text):
   if try "\begin{", *a, "}", *b, "\end{", *a, "}" = ... # how do you 
ensure that the two a's match?  how do you ensure that a can only consist 
of letter characters?

I feel like it would be more idealistic to find a powerful, expressive way 
to specify parsers.  (As far as I know, no Python parser library can 
specify expression yet because they don't execute code on their "rules").  
If we had such a parsing library or extension, then we could compare 
whether it's overkill or reasonable to use that library in situations that 
you're proposing to address with "if try".

Best,

Neil


On Friday, January 3, 2020 at 12:15:42 PM UTC-5, Andrew Barnert via 
Python-ideas wrote:
>
> > On Jan 2, 2020, at 18:34, Dan Sommers <2qdxy4rz...@potatochowder.com 
> > wrote: 
> > 
> > On 1/2/20 3:07 PM, Random832 wrote: 
> >> On Thu, Jan 2, 2020, at 13:22, Dan Sommers wrote: 
> > 
> >>> What about "if except" (any time I can eliminate a "not," that's a 
> >>> good thing): 
> >> ... is this meant to be for the doesn't-throw case or does-throw? ... 
> >>> if except x: 
> >>> y 
> > 
> > That would be the does-throw case.  Read it as "if there's an exception 
> > evaluating x, then do the following." 
>
> But then you have the opposite of what you need. You want “if it matches 
> this, do that with these bindings”, not “if it doesn’t match this, do that 
> (with these failed bindings)”. 
>
> Also, you can’t chain these up and keep trying patterns until one 
> succeeds, or default if all of them fail; instead you can only chain them 
> up and keep trying patterns until one fails, or default if they all 
> succeed. 
>
> So, this syntax might be useful for other things, but not for pattern 
> matching. 
>
> >> ... how are we eliminating the not? 
> > 
> > I changed "not try" to "except," thus eliminating the "not." 
>
> But there’s no “not try”, just a “try”. We want to run code if the try 
> condition succeeds, which is positive, not negative. 
>
> Or, if you prefer, it’s a double negative, and you’ve removed one of the 
> negatives: 
>
>if try (x, 0, z) := vec: 
>xz_stuff(x, z) 
>
> … would be roughly equivalent to: 
>
>try: 
>x, 0, z = vec 
>except ValueError. 
>pass 
>else: 
>xz_stuff(x, z) 
>
> What you’ve given is a way to put code in the one place where we didn’t 
> want any (but had to put a “pass” just for syntactic reasons) without 
> putting code in the place we did. 
>
>
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/5HOJJFQIQ25JZLPPGBOZTEMDDTAMGBSJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/DC2OKRB6GKQHIIY65XEMHWGK4GKGEJ6L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fix statistics.median()?

[Neil Girdhar]

I'm just glancing at this thread, but it sounds like you want to add the 
quickselect algorithm to the standard library.   As you point out in 
another message, quickselect is faster than quicksort: it is linear time 
(provided the pivot is chosen by median of medians) whereas quicksort is 
expected linearithmic time.

Using quickselect, you could select any order statistic: the median, the 
25th percentile, etc.  If it were added, I guess it probably belongs in 
statistics.

Best,

Neil  

On Thursday, December 26, 2019 at 3:14:33 PM UTC-5, David Mertz wrote:
>
> Maybe we can just change the function signature:
>
> statistics.median(it, do_wrong_ass_thing_with_nans=False)
>
> :-)
>
> But yes, the problem is really with sorted(). However, the implementation 
> of statistics.median() doesn't HAVE TO use sorted(), that's just one 
> convenient way to do it.
>
> There IS NO right answer for `sorted([nan, 1, 2, 3])`.  However, there is 
> a very plausibly right answer for `statistics.median([nan, 1, 2, 3])` ... 
> or rather, both 'nan' and '2' are plausible (one approach is what Numpy 
> does, the other is what Pandas does).
>
> -- 
> Keeping medicines from the bloodstreams of the sick; food 
> from the bellies of the hungry; books from the hands of the 
> uneducated; technology from the underdeveloped; and putting 
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
___
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/FE2A6LAFA4ETV3JEZ5VFHGGPEV5LSA6G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

[Neil Girdhar]

On Tuesday, November 19, 2019 at 3:06:26 PM UTC-5, Paul Moore wrote:
>
> On Tue, 19 Nov 2019 at 19:03, Random832  > wrote: 
> > 
> > On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote: 
> > > Because you don't have to create the context manager directly in the 
> > > with statement 
> > 
> > ...what? that's *my* argument. that's *precisely* why I consider open to 
> be 'misbehaving'. Because you *should* be able to create a context manager 
> outside the with statement without causing these problems. Because calling 
> open outside the with statement [absent other arrangements like an explicit 
> try/finally] causes problems that wouldn't be there for a proper context 
> manager that has __exit__ as the inverse of __enter__ rather than as the 
> inverse of some other operation that happens before __enter__. 
>
> We're just going round in circles here. You *can* call open outside 
> the with statement. It's *perfectly* fine to do so. But if you do, it 
> is *your* responsibility to manage the closing of the file object 
>

So you're proposing that everyone who doesn't use open in a context manager 
should always write
f = open(...)
# Absolutely nothing between the above line and the line below.
try:
   ...
finally:
   f.close()

How is that any nicer than using a context manager?  Because if you don't 
always write the above code, I think your code is way too fragile.  If any 
line of code where the comment is raises, you have a resource leak. 

(which is done using close(), not __exit__()). That's been valid and 
> acceptable for more years than I can recall (at least back to Python 
> 1.4). 


It is valid, and I guess this is a matter of preference, but personally I 
don't think it's "acceptable" code.  I think most code reviews would 
request changes to code that opens files without using a context manager.
 

> As a convenience, you can pass the file object to a with 
> statement, to say "i want the file to be closed when control leaves 
> this suite, regardless of how that happens - please handle the admin 
> for me. That convenience ability is provided by file objects making 
> __enter__ do nothing (because there's nothing you need to do on 
> entering the with block to prepare for the tidying up) and making 
> __exit__ act like close (because all you need to do on leaving the 
> scope is close the file). 
>
> According to the PEP, and established usage since Python 2.5, an 
> object that does this is called a context manager. It's a perfectly 
> acceptable one. Even if it doesn't implement other behaviours that you 
> would like it to have, doesn't mean it's not a context manager. I'm 
> fine with you coining a new term ("enhanced context manager", I don't 
> know, I've already said naming is hard) for context managers with the 
> additional properties you are interested in, but existing context 
> managers are *not* somehow "misbehaving" or "broken", or "problematic" 
> - it's your assumption that context managers have behaviour that isn't 
> required of them by the definition of that term that's wrong. 
>

I guess I'm in the camp of people that considers acquiring resources in the 
constructor as "misbehaving".  Reason below…

>
> > Because you *should* be able to create a context manager outside the 
> with statement without causing these problems. 
>
> Says who? The PEP doesn't say any such thing. If you are saying it, I 
> disagree with you. If you are saying "it's obvious and everyone must 
> surely agree", then sorry, I still disagree with you. Simply asserting 
> the same thing repeatedly is not a particularly effective argument. 
>
> Demonstrate some benefits. I'll give you "we'd be able to create 
>

There's nothing preventing anyone from creating a context manager whenever 
they please.  For example, an object could create a list of context 
managers and then acquire those later when the resources are needed.  Are 
you proposing a system whereby objects that inherit from ContextManager can 
only come into existence in a with block?

Right now, context managers can be created anwhere.  Your best defense 
against leaking resources is acquiring them in the __enter__ method.  
Therefore, my personal opinion is that any object that acquires resources 
outside of an __enter__ method should probably be rewritten as a context 
manager. 
 

> functions like nested() without worrying about users misusing them" 
> for free. It's not worth a lot (IMO) but hey, you got it for free, 
> what did you expect? ;-) 
> Examine the costs, and explain why they are worth accepting  Backward 
> compatibility is a big one here, and you're going to need some serious 
> benefits to offset it, or at least some really good ways to mitigate 
> it - there's masses of code that passes file objects to with 
> statements, as well as plenty of code that uses them independently. 
>
> I really don't see any new arguments being made here, to be honest. 
>
> Paul 
> ___ 
> 

[Python-ideas] Consider blocking heterogeneous chained comparison

[Neil Girdhar]

Some people find this legal syntax confusing:

A in B < C

(It means A in B and B < C.)

I feel like most code reviews would not allow this kind of code to be 
checked in, at least without a comment explaining what the code does.  What 
are the motivating reasons for allowing this syntax?  Is there any 
idiomatic code that uses it?

If not, I suggest dividing the comparison operators into two groups:

in, not in, is, is not

and

<, >, <=, >=, ==, !=

and then disallowing chaining of operators from both groups.

For example, still allowed:

A <= B <= C

A in B in C

disallowed:

A < B in C

The advantage of such a change is that there is fewer "gotcha" code.  I 
admit that this code is rarely written, but it can come up.  For example, 
you might write your own comparison operator and then want to see if it's 
working:

A < B is None

returns false if B is not None even if A < B returns None.

Also, in my opinion, the existence is a deterrent to Python and takes away 
from Python's beauty as a language.

The downside of such a change is that the language is more complicated.

As far as implementation goes, this can be done after parsing when the AST 
is checked and errors are raised (from what I remember).

Best,

Neil
___
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/S7NBNTIPUON2N6WGNBCJXBRVAJNFPNPS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Neil Girdhar]

I really like this idea.  Once you've already decided to raise an
exception, does it really cost much to try to raise a more helpful one?
And helpful exception messages make programming a lot less painful, and a
lot more of a joy.

On Tue, Oct 22, 2019 at 2:43 PM Mike Miller 
wrote:

>
> On 2019-10-18 10:23, Ricky Teachey wrote:
> > but i'm -0 because i am very concerned it will not be obvious to new
> learners,
> > without constantly looking it up, whether adding two mappings together
> would either:
>
> The big trade off I'm gathering from this mega-thread is that the |, |=
> operators are more accurate, but less obvious to newcomers, who will first
> try
> +, += instead.
>
> I've tried them in this order myself several times over the years.
>
> Had an idea, why not choose the more accurate syntax: |, |= after all?
> Then, to
> help newcomers and forgetful pros a custom error message is implemented
> for +,
> +=.  In pseudo C/Python, something like this:
>
>  class dict:
>
>  def __add__(self, other):
>
>  if isinstance(other, dict):
>  raise TypeError(
>  'unsupported operand type(s) for +: … '
>  'Dictionary merging leads to last-value-wins data '
>  'loss. If acceptable, use the union "|" operator.'
>  )
>  else:
>  raise TypeError(std_err_msg)
>
>
> I think it is worth it to lead the newcomer to a moment's reflection on
> why
> dictionary combining/merging is potentially lossy.  Everyone is informed
> with
> the proper mental model, then on their way and left alone afterward.
>
> Thoughts?
> -Mike
> ___
> 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/43T52R223GYPHIDP3CHTIS3JTQYUNCVL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/puGRBmzVl9c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python-ideas/3ac803c4-f703-67bf-c4c9-a37bbe0c61d8%40mgmiller.net
> .
>
___
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/3UGDM5QPUYVABW35MM7DGACWBYFBK2CT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Neil Girdhar]

I would use it, and I prefer | for the reasons given by Stephen, MRAB, and 
the other proponents.

On Monday, October 21, 2019 at 1:08:32 AM UTC-4, Andrew Barnert via 
Python-ideas wrote:
>
> On Oct 20, 2019, at 21:10, Stephen J. Turnbull <
> turnbull...@u.tsukuba.ac.jp > wrote: 
> > 
> > I'm not against having an operator for updating dicts, but "+" is not 
> > it.  "|" is fine, though. 
>
> It seems like people who don’t really like this feature and don’t plan to 
> use it mostly really want it to be spelled | if it has to be added. But 
> people who are dying for it mostly want + (except for the ones who want all 
> the set operators). I’m not sure what that means… 
>
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/TV73IEFOV77Z64RN2QXOKYIOBCUHD45I/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/NXQ4YKXCT6SHZ6QDRWCAE4RJB5MULPSQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Subscriptable ABC

[Neil Girdhar]

On Fri., Oct. 11, 2019, 2:38 a.m. Neil Girdhar, 
wrote:

>
>
> On Fri, Oct 11, 2019 at 2:28 AM Andrew Barnert  wrote:
>
>> > On Oct 10, 2019, at 22:13, Neil Girdhar  wrote:
>> >
>> > That's funny, I always thought of that as legacy.  The iterator
>> protocol has been a special case in so many proposals I've seen on this
>> list.  I think it's really ugly.  Instead of
>> collections.abc.OldStyleSequence, what do you think of adding something
>> like InfiniteSequence to collections.abc instead?  It's basically Sequence
>> without __len__, __reversed__, or __count__.   I don't see it getting much
>> use though.
>>
>> Are you proposing that this type isn’t allowed to have those methods (as
>> opposed to just not being required to)?
>
>
> Not required.  Just like if we added a row to the table.  So, the point of
> this mixin would be to implement __contains__ __iter__ and __index__ given
> __getitem__.
>
>
>> If so that would be a unique ABC, and a pretty weird one. If not, isn’t
>> this exactly equivalent to the original proposal, but just with a different
>> name? And I think it’s a pretty misleading name. Especially if the subclass
>> hook is structural (method-check), because then it would pick up Sequence
>> and Mapping types even though they aren’t infinite sequences. For that
>> matter, not even every useful old-style sequence is infinite; that’s just
>> the most obvious example everyone comes up with first.
>>
>
> Yeah, those are all good points.  After sending, I realized, that it would
> be nicer as a base class of Sequence.  I guess I'm for the proposal then.
> I skipped reading the big debate about structural checks because I think if
> you really care about this, you should probably either inherit from the ABC
> or register yourself with it.
>
> Anyway, I guess we pretty much agree then.  I just wanted to push against
> legitimizing the sequence protocol in favor of explicitly inheriting from a
> mixin (whatever you want to call it, GenericSequence?  AbstractSequence?
> PossiblyInfiniteSequence?)   Inheritance like this is a nice declaration of
> intent.  Even if you just implemented __getitem__, I think you would have
> to have a comment to make the code clear anyway.
>
>
>> Anyway, I don’t want to put words in Steven’s mouth; maybe this would fit
>> what he wanted. But I suspect it wouldn’t.
>>
>
___
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/HNJGWHF3R5AABCNEGE7RRMOQOJ6IV2S7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Subscriptable ABC

[Neil Girdhar]

On Monday, September 30, 2019 at 12:24:30 AM UTC-4, Andrew Barnert via 
Python-ideas wrote:
>
> On Sep 29, 2019, at 16:41, Steven D'Aprano  > wrote: 
> > 
> >> On Sun, Sep 29, 2019 at 11:27:32AM +0100, Oscar Benjamin wrote: 
> >> 
> >> That's the point that I would make as well. What can you do with an 
> >> object that is only known to be Subscriptable? 
> > 
> > I can subscript it. What did you expect the answer to be? 
>
> I think the idea here is that your type follows the “old sequence 
> protocol”, where you can index it with 0, 1, … until you get an IndexError, 
> without having to check __len__ first. 
>
> Since there are various bits of Python (including the iter function) that 
> support this protocol, it’s odd that there’s no ABC for it. And it’s not 
> just that it’s odd, it’s different from almost every other 
> collection-related protocol in Python. 
>
> I think the only reasonable argument against this is that “old-style” 
> means “legacy”, as in you shouldn’t be creating new classes like this. But 
> I don’t think that argument is true. There are perfectly good use 
> cases—like your infinite sequences—that are perfectly good old-style 
> sequences and are not valid Sequences, and how else are you supposed to 
> implement them? (Iteration is great, but sometimes random access matters.) 
>

That's funny, I always thought of that as legacy.  The iterator protocol 
has been a special case in so many proposals I've seen on this list.  I 
think it's really ugly.  Instead of collections.abc.OldStyleSequence, what 
do you think of adding something like InfiniteSequence to collections.abc 
instead?  It's basically Sequence without __len__, __reversed__, or 
__count__.   I don't see it getting much use though.

>
> If I’m right about what you’re asking for, I think it’s a useful addition. 
>
> Of course the same protocol would accept all kinds of bizarre other things 
> that support __getitem__ for different reasons, like the “I want to spell 
> calling differently” thing, plus (somewhat less uselessly) 
> typing._GenericAlias subclasses like typing.List. But I don’t think that’s 
> a problem. Sure, it’s not ideal that your test would accept typing.List, 
> but who’s going to pass the List pseudo-type to a function that clearly 
> expects some kind of collection? If they get a different exception than 
> they expected (a TypeError a few lines down, most likely), who cares? That 
> seems like a consenting adults issue. 
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/LPQXOMBHEKSPZZVRDB36U5WFTABBLMCK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/ETY5PLWHCPIIC7BFUGLZ6CEN4CRL7MQF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Skip modules by default in star-import

[Neil Girdhar]

I think I agree with Serhiy, but I don't think Anders' suggestion is 
workable since it's very common in __init__.py to do exactly this (import * 
from local modules in order to re-export them), and you definitely don't 
want to explitly foo=foo for everything.  That's the whole reason you 
"import *".  For example, 
https://github.com/numpy/numpy/blob/master/numpy/linalg/__init__.py

Best,

Neil

On Friday, July 26, 2019 at 2:53:23 PM UTC-4, Anders Hovmöller wrote:
>
>
>
> > On 26 Jul 2019, at 20:34, Serhiy Storchaka  > wrote: 
> > 
> > 26.07.19 21:10, Anders Hovmöller пише: 
> >> This doesn't really solve the problem imo. Imported symbols shouldn't 
> be i portable elsewhere. Not by import * or explicitly. That's the problem. 
> > 
> > I do not think that this is always a problem. It is common to refactor 
> the code by defining names in submodules and then importing them in the 
> main module. For example, in `json/__init__.py`: 
> > 
> >from .decoder import JSONDecoder, JSONDecodeError 
> >from .encoder import JSONEncoder 
> > 
> > It is possible even to use a star import. 
> > 
> > So this change would break much more code. 
>
> I believe I covered that in my last email. I'll repeat it here for 
> clarity: if you indent to re-export you can do that explicitly: 
>
> from foo import bar 
> bar = bar 
>
> For "from x import *" you'd need to iterate over __import_dict__ (or 
> whatever we call it) and set them all. 
>
> / Anders 
>
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/EP3PK3C4ZPJSBIYT4OLFIBREOW7RX67Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/R7A2NFZD6NKWBYSJUEZOHBNGGGUP47OU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP-603: Adding a frozenmap type to collections

[Neil Girdhar]

I'll let other people comment on this wrt Python (even though I think it 
looks cool and useful to me).  Out of curiosity, why does frozenmap not 
have the same runtime and ordering guarantees as dict?

On Thursday, September 12, 2019 at 7:47:25 AM UTC-4, Yury Selivanov wrote:
>
> Hi! 
>
> I've just published a PEP to add a frozenmap type to Python; it should 
> be online shortly. 
>
> Read it here: 
> https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318
>  
>
> Here's an excerpt from the Abstract: 
>
> A *persistent data structure* is defined as a data structure that 
> preserves the previous version of the data when the data is modified. 
> Such data structures are effectively *immutable*, as operations on 
> them do not update the structure in-place, but instead always yield 
> a new updated structure (see [0]_ for more details.) 
>
> This PEP proposes to add a new fully persistent and immutable mapping 
> type called ``frozenmap`` to the ``collections`` module. 
>
> The bulk of ``frozenmap``'s reference implementation is already 
> used in CPython to implement the ``contextvars`` module. 
>
> Yury 
> ___ 
> Python-ideas mailing list -- python...@python.org  
> To unsubscribe send an email to python-id...@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/HYFR6Q6UT54ESFVH5MWCSIX4IRFTEHBU/
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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/LZWBQ6CILGL6VGUC7VWOSNGOYP5LZONN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Universal parsing library in the stdlib to alleviate security issues

[Neil Girdhar]

The documentation is beautiful.

One of the features I was looking for when evaluating parsers was the 
ability to run expression on the rules.  For example if you matching
"\begin{\w*}"
and \w* turns out to be "enumeration", then later when you match
"\end{\w*}"
then you want to check that that \w* is also enumeration or else raise an 
error.

A similar thing happens when you're trying to parse Python source code with 
the indentation level.  You might want to check that the next indentation 
level is the same or corresponds to a dedent.

Expressions on rules should be able to control whether something matches, 
should be able to store values in the parse tree, to store values that can 
be read by other expressions, and be able to raise parsing errors.

The beauty of expressions is that you can do the parsing and build the AST 
in one shot.  If you've ever looked at the Python source code, it is 
unfortunate that those tasks have to be done separately even though most 
changes to the AST require parsing changes.

The most modern parsing algorithms have this.  The old parsing libraries 
(lex/yacc, flex/bison, antlr) were very limited.

Also, I'm not sure the separation between tokenization and parsing is 
necessary if you're not worried about efficiency.

Best,

Neil

On Monday, July 15, 2019 at 9:45:59 PM UTC-4, Nam Nguyen wrote:
>
> Hello list,
>
> I sent an email to this list two or three months ago about the same idea. 
> In that discussion, there were both skepticism and support. Since I had 
> some time during the previous long weekend, I have made my idea more 
> concrete and I thought I would try with the list again, after having run it 
> through some of you privately.
>
> GOAL: To have some parsing primitives in the stdlib so that other modules 
> in the stdlib itself can make use of. This would alleviate various security 
> issues we have seen throughout the years.
>
> With that goal in mind, I opine that any parsing library for this purpose 
> should have the following characteristics:
>
> #. Can be expressed in code. My opinion is that it is hard to review 
> generated code. Code review is even more crucial in security contexts.
>
> #. Small and verifiable. This helps build trust in the code that is meant 
> to plug security holes.
>
> #. Less evolving. Being in the stdlib has its drawback that is development 
> velocity. The library should be theoretically sound and stable from the 
> beginning.
>
> #.  Universal. Most of the times we'll parse left-factored context-free 
> grammars, but sometimes we'll also want to parse context-sensitive grammars 
> such as short XML fragments in which end tags must match start tags.
>
> I have implemented a tiny (~200 SLOCs) package at 
> https://gitlab.com/nam-nguyen/parser_compynator that demonstrates 
> something like this is possible. There are several examples for you to have 
> a feel of it, as well as some early benchmark numbers to consider. This is 
> far smaller than any of the Python parsing libraries I have looked at, yet 
> more universal than many of them. I hope that it would convert the skeptics 
> ;).
>
> Finally, my request to the list is: Please debate on: 1) whether we want a 
> small (even private, underscore prefixed) parsing library in the stdlib to 
> help with tasks that are a little too complex for regexes, and 2) if yes, 
> how should it look like?
>
> I also welcome comments (naming, uses of operator overloading, features, 
> bikeshedding, etc.) on the above package ;).
>
> Thanks!
> Nam
>
___
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/MVULCAFJDAY4HHT7P6X4DCTW3HHEBF6T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Integer infinity and extended integers

[Neil Girdhar]

Now that Python is beginning to embrace type annotations, is it worth 
revisiting the idea of having extended integers and an integer infinity?

I found myself trying to annotate this line:

events_to_do: Union[int, float] = math.inf

where I am only including float in the union to accommodate math.inf.  

I'm interested in exploring this concrete proposal:

Add a class to the numeric hierarchy 
(https://www.python.org/dev/peps/pep-3141/) ExtendedIntegral whereby  Real 
:> ExtendedIntegral :> Integral.
Add a sentinel math.int_inf that obeys all of the same kinds of rules as 
math.inf does.

Then, I could annotate more simply:

events_to_do: ExtendedIntegral = math.int_inf

With respect to Python, this is discussed somewhat 
here 
https://stackoverflow.com/questions/24587994/infinite-integer-in-python/35725065#35725065.

The name "extended integer" is discussed somewhat 
here https://math.stackexchange.com/questions/1442961/extended-integers.  A 
quick search of papers shows that it is sometimes used in this 
sense: https://scholar.google.com/scholar?q=%22extended+integer

Best,

Neil
___
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/QFLWTFJMU2RSGBMYP2XMSYA36VYFRDDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dict joining using + and +=

[Neil Girdhar]

On Mon, Mar 4, 2019 at 3:58 PM Christopher Barker  wrote:
>
>
>
> On Mon, Mar 4, 2019 at 12:41 PM Guido van Rossum  wrote:
>>
>> Honestly I would rather withdraw the subtraction operators than reopen the 
>> discussion about making dict more like set.

I think that's unfortunate.
>
>
> +1
>
> I think the "dicts are like more-featured" sets is a math-geek perspective, 
> and unlikely to make things more clear for the bulk of users. And may make it 
> less clear.

I'd say reddit has some pretty "common users", and they're having a
discussion of this right now
(https://www.reddit.com/r/Python/comments/ax4zzb/pep_584_add_and_operators_to_the_builtin_dict/).
The most popular comment is how it should be |.

Anyway, I think that following the mathematical metaphors tends to
make things more intuitive in the long run.  Python is an adventure.
You learn it for years and then it all makes sense.  If dict uses +,
yes, new users might find that sooner than |.  However, when they
learn set union, I think they will wonder why it's not consistent with
dict union.

The PEP's main justification for + is that it matches Counter, but
counter is adding the values whereas | doesn't touch the values.   I
think it would be good to at least make a list of pros and cons of
each proposed syntax.

> We need to be careful -- there are a lot more math geeks on this list than in 
> the general Python coding population.
>
> Simply adding "+" is a non-critical nice to have, but it seems unlikely to 
> really confuse anyone.
>
> -CHB
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
___
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] Dict joining using + and +=

[Neil Girdhar]

On Mon, Mar 4, 2019 at 3:22 PM Guido van Rossum  wrote:
>
> On Mon, Mar 4, 2019 at 12:12 PM Neil Girdhar  wrote:
>>
>> On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum  wrote:
>> >
>> > * Dicts are not like sets because the ordering operators (<, <=, >, >=) 
>> > are not defined on dicts, but they implement subset comparisons for sets. 
>> > I think this is another argument pleading against | as the operator to 
>> > combine two dicts.
>> >
>>
>> I feel like dict should be treated like sets with the |, &, and -
>> operators since in mathematics a mapping is sometimes represented as a
>> set of pairs with unique first elements.  Therefore, I think the set
>> metaphor is stronger.
>
>
> That ship has long sailed.

Maybe, but reading through the various replies, it seems that if you
are adding "-" to be analogous to set difference, then the combination
operator should be analogous to set union "|".  And it also opens an
opportunity to add set intersection "&".  After all, how do you filter
a dictionary to a set of keys?

>> d = {'some': 5, 'extra': 10, 'things': 55}
>> d &= {'some', 'allowed', 'options'}
>> d
{'some': 5}

>>
>> > * Regarding how to construct the new set in __add__, I now think this 
>> > should be done like this:
>> >
>> > class dict:
>> > 
>> > def __add__(self, other):
>> > 
>> > new = self.copy()  # A subclass may or may not choose to override
>> > new.update(other)
>> > return new
>>
>> I like that, but it would be inefficient to do that for __sub__ since
>> it would create elements that it might later delete.
>>
>> def __sub__(self, other):
>>  new = self.copy()
>>  for k in other:
>>   del new[k]
>> return new
>>
>> is less efficient than
>>
>> def __sub__(self, other):
>>  return type(self)({k: v for k, v in self.items() if k not in other})
>>
>> when copying v is expensive.  Also, users would probably not expect
>> values that don't end up being returned to be copied.
>
>
> No, the values won't be copied -- it is a shallow copy that only increfs the 
> keys and values.

Oh right, good point.  Then your way is better since it would preserve
any other data stored by the dict subclass.
>
> --
> --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] Dict joining using + and +=

[Neil Girdhar]

On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum  wrote:
>
> * Dicts are not like sets because the ordering operators (<, <=, >, >=) are 
> not defined on dicts, but they implement subset comparisons for sets. I think 
> this is another argument pleading against | as the operator to combine two 
> dicts.
>

I feel like dict should be treated like sets with the |, &, and -
operators since in mathematics a mapping is sometimes represented as a
set of pairs with unique first elements.  Therefore, I think the set
metaphor is stronger.

> * Regarding how to construct the new set in __add__, I now think this should 
> be done like this:
>
> class dict:
> 
> def __add__(self, other):
> 
> new = self.copy()  # A subclass may or may not choose to override
> new.update(other)
> return new

I like that, but it would be inefficient to do that for __sub__ since
it would create elements that it might later delete.

def __sub__(self, other):
 new = self.copy()
 for k in other:
  del new[k]
return new

is less efficient than

def __sub__(self, other):
 return type(self)({k: v for k, v in self.items() if k not in other})

when copying v is expensive.  Also, users would probably not expect
values that don't end up being returned to be copied.

>
> AFAICT this will give the expected result for defaultdict -- it keeps the 
> default factory from the left operand (i.e., self).
>
> * Regarding how often this is needed, we know that this is proposed and 
> discussed at length every few years, so I think this will fill a real need.
>
> * Regarding possible anti-patterns that this might encourage, I'm not aware 
> of problems around list + list, so this seems an unwarranted worry to me.
>

I agree with these points.

Best,

Neil
> --
> --Guido van Rossum (python.org/~guido)
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "python-ideas" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/python-ideas/zfHYRHMIAdM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "python-ideas" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/python-ideas/zfHYRHMIAdM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
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] PEP: Dict addition and subtraction

[Neil Girdhar]

I think that sequence should be fixed.

On Fri., Mar. 1, 2019, 7:12 p.m. Brandt Bucher, 
wrote:

> While working through my implementation, I've come across a couple of
> inconsistencies with the current proposal:
>
> > The merge operator will have the same relationship to the dict.update
> method as the list concatenation operator has to list.extend, with dict
> difference being defined analogously.
>
> I like this premise. += for lists *behaves* like extend, and += for dicts
> *behaves* like update.
>
> However, later in the PEP it says:
>
> > Augmented assignment will just call the update method. This is
> analogous to the way list += calls the extend method, which accepts any
> iterable, not just lists.
>
> In your Python implementation samples from the PEP, dict subclasses will
> behave differently from how list subclasses do. List subclasses, without
> overrides, return *list* objects for bare "+" operations (and "+=" won't
> call an overridden "extend" method). So a more analogous
> pseudo-implementation (if that's what we seek) would look like:
>
> def __add__(self, other):
> if isinstance(other, dict):
> new = dict.copy(self)
> dict.update(new, other)
> return new
> return NotImplemented
>
>  def __radd__(self, other):
> if isinstance(other, dict):
> new = dict.copy(other)
> dict.update(other, self)
> return new
> return NotImplemented
>
> def __iadd__(self, other):
> if isinstance(other, dict):
> dict.update(self, other)
> return self
> return NotImplemented
>
> This is what my C looks like right now. We can choose to update these 
> semantics to be "nicer" to subclasses, but I don't see any precedent for it 
> (lists, sets, strings, etc.).
>
> Brandt
>
>
> On Fri, Mar 1, 2019 at 11:41 AM Brett Cannon  wrote:
>
>>
>>
>> On Fri, Mar 1, 2019 at 8:50 AM Brandt Bucher 
>> wrote:
>>
>>> I’ve never been part of this process before, but I’m interested in
>>> learning and helping any way I can.
>>>
>>
>> Thanks!
>>
>>
>>>
>>> My addition implementation is attached to the bpo, and I’m working today
>>> on bringing it in line with the PEP in its current form (specifically,
>>> subtraction operations).
>>>
>>> https://github.com/python/cpython/pull/12088
>>>
>>
>> When your proposed patch is complete, Brandt, just ask Steven to update
>> the PEP to mention that there's a proposed implementation attached to the
>> issue tracking the idea.
>>
>> -Brett
>>
>>
>>>
>>>
>>> Brandt
>>>
>>> On Mar 1, 2019, at 08:26, Steven D'Aprano  wrote:
>>>
>>> Attached is a draft PEP on adding + and - operators to dict for
>>> discussion.
>>>
>>> This should probably go here:
>>>
>>> https://github.com/python/peps
>>>
>>> but due to technical difficulties at my end, I'm very limited in what I
>>> can do on Github (at least for now). If there's anyone who would like to
>>> co-author and/or help with the process, that will be appreciated.
>>>
>>>
>>> --
>>> 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/
>>>
>> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/jq5QVTt3CAI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/jq5QVTt3CAI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] PEP: Dict addition and subtraction

[Neil Girdhar]

Looks like a good start.

I think you should replace all of the lines:
 if isinstance(other, dict):
with
 if isinstance(self, type(other)):


Since if other is an instance of a dict subclass, he should be the one to 
process the addition. On the other hand, if self is an instance of the 
derived type, then we are free to do the combination.


I think you should also change this wording:


"the result type will be the type of the left operand"


since the result type will be negotiated between the operands (even in your 
implemenation).


__sub__ can be implemented more simply as a dict comprehension.


Don't forget to return self in __isub__ and __iadd__ or they won't work.


I think __isub__ would be simpler like this:

def __isub__(self, it):
 if it is self:
  self.clear()
 else:
  for value in it:
 del self[value]
 return self

I don't see why you would bother looking for keys (iter will do that 
anyway).




On Friday, March 1, 2019 at 11:27:54 AM UTC-5, Steven D'Aprano wrote:
>
> Attached is a draft PEP on adding + and - operators to dict for 
> discussion. 
>
> This should probably go here: 
>
> https://github.com/python/peps 
>
> but due to technical difficulties at my end, I'm very limited in what I 
> can do on Github (at least for now). If there's anyone who would like to 
> co-author and/or help with the process, that will be appreciated. 
>
>
> -- 
> 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] Dict joining using + and +=

[Neil Girdhar]

On Friday, March 1, 2019 at 5:47:06 AM UTC-5, Steven D'Aprano wrote:
>
> On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote: 
>
> > Currently Counter += dict works and Counter + dict is an error. With 
> > this change Counter + dict will return a value, but it will be different 
> > from the result of the += operator. 
>
> That's how list.__iadd__ works too: ListSubclass + list will return a 
> value, but it might not be the same as += since that operates in place 
> and uses a different dunder method. 
>
> Why is it a problem for dicts but not a problem for lists? 
>
>
> > Also, if the custom dict subclass implemented the plus operator with 
> > different semantic which supports the addition with a dict, this change 
> > will break it, because dict + CustomDict will call dict.__add__ instead 
> > of CustomDict.__radd__. 
>
> That's not how operators work in Python or at least that's not how they 
> worked the last time I looked: if the behaviour has changed without 
> discussion, that's a breaking change that should be reverted. 
>
> Obviously I can't show this with dicts, but here it is with lists: 
>
> py> class MyList(list): 
> ... def __radd__(self, other): 
> ... print("called subclass first") 
> ... return "Something" 
> ... 
> py> [1, 2, 3] + MyList() 
> called subclass first 
> 'Something' 
>
>
> This is normal, standard behaviour for Python operators: if the right 
> operand is a subclass of the left operand, the reflected method __r*__ 
> is called first. 
>
>
> > Adding support of new operators to builting 
> > types is dangerous. 
>
> Explain what makes new operators more dangerous than old operators 
> please. 
>
>
> > >I do not understand why we discuss a new syntax for dict merging if 
> we 
> > >already have a syntax for dict merging: {**d1, **d2} (which works 
> with 
> > >*all* mappings). Is not this contradicts the Zen? 
> > > 
> > > 
> > >But (as someone else pointed out) {**d1, **d2} always returns a dict, 
> > >not the type of d1 and d2. 
> > 
> > And this saves us from the hard problem of creating a mapping of the 
> > same type. 
>
> What's wrong with doing this? 
>
> new = type(self)() 
>
> Or the equivalent from C code. If that doesn't work, surely that's the 
> fault of the subclass, the subclass is broken, and it will raise an 
> exception. 
>
> I don't think it is our responsibility to do anything more than call 
> the subclass constructor. If that's broken, then so be it. 
>
>
> Possibly relevant: I've always been frustrated and annoyed at classes 
> that hardcode their own type into methods. E.g. something like: 
>
> class X: 
> def spam(self, arg): 
> return X(eggs)   
> # Wrong! Bad! Please use type(self) instead. 
>
> That means that each subclass has to override every method: 
>
> class MySubclass(X): 
> def spam(self, arg): 
> # Do nothing except change the type returned. 
> return type(self)( super().spam(arg) ) 
>
>
> This gets really annoying really quickly. Try subclassing int, for 
> example, where you have to override something like 30+ methods and do 
> nothing but wrap calls to super. 
>

I agree with you here.  You might want to start a different thread with 
this idea and possibly come up with a PEP.  There might be some pushback 
for efficiency's sake, so you might have to reel in your proposal to 
collections.abc mixin methods and UserDict methods.

Regarding the proposal, I agree with the reasoning put forward by Guido and 
I like it.  I think there should be:
* d1 + d2
* d1 += d2
* d1 - d2
* d1 -= d2

which are roughly (ignoring steve's point about types)
* {**d1, **d2}
* d1.update(d2)
* {k: v for k, v in d1.items() if k not in d2}
* for k in list(d1): if k not in d2: del d1[k]

Seeing this like this, there should be no confusion about what the 
operators do.

I understand the points people made about the Zen of Python.  However, I 
think that just like with lists, we tend to use l1+l2 when combining lists 
and [*l1, x, *l2, y] when combining lists and elements.  Similarly, I think 
{**d1, **d2} should only be written when there are also key value pairs, 
like {**d1, k: v, **d2, k2: v2}.

Best,

Neil


>
> -- 
> Steven 
> ___ 
> Python-ideas mailing list 
> python...@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] Please consider adding an overrideable flag to abstractmethod

[Neil Girdhar]

Alternatively, the need for an overriding implementation to call super 
could be marked by a different decorator.  This would allow linters to 
check that subclasses call super when they should, which is a very useful 
check in my opinion.  Such a decorator could be called "@overrideable", and 
could be exposed in abc.   When used in combination with @abstractmethod, 
it could have the above behavior. 

On Sunday, February 17, 2019 at 5:28:49 AM UTC-5, Neil Girdhar wrote:
>
> Marking a method M declared in C with abstractmethod indicates that M 
> needs to be *implemented* in any subclass D of C for D to be instantiated.
>
> We usually think of overriding a method N to mean replacing one 
> implementation in some class E with another in some subclass of E, F.  
> Often, the subclass implementation calls super to add behavior rather than 
> replace it.
>
> I think that this concept of *implementing* is different than *overriding*.
>
> However, abstract classes can have reasonable definition, and should 
> sometimes be overridden in the sense that subclasses should call super.  
> For example, when inheriting from AbstractContextManager, you need to 
> *override* the abstractmethod (!) __exit__, and if you want your class to 
> work polymorphically, you should call super.
>
> This is extremely weird.  Understandably, the pylint people are confused 
> by it (https://github.com/PyCQA/pylint/issues/1594) and raise bad 
> warnings.
>
> It also makes it impossible for me to raise warnings in my ipromise (
> https://github.com/NeilGirdhar/ipromise) project.  See, for example, 
> https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py
>  
> classes Y and W, which ought to raise, but that would raise on reasonable 
> code.
>
> My suggestion is to add a rarely used flag to abstractmethod:
>
> class AbstractContextManager:
> @abstractmethod(overrideable=True)
> def __exit__(self, exc_type, exc_value, traceback):
> pass
>
> This would set a flag on the method like __abstractmethod_overrideable__, 
> which could be checked by ipromise's @overrides decorator, pylint's call 
> check, and anyone else that wants to know that a method should be 
> overridden.
>
> Best,
>
> Neil
>
___
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] Please consider adding an overrideable flag to abstractmethod

[Neil Girdhar]

Marking a method M declared in C with abstractmethod indicates that M needs 
to be *implemented* in any subclass D of C for D to be instantiated.

We usually think of overriding a method N to mean replacing one 
implementation in some class E with another in some subclass of E, F.  
Often, the subclass implementation calls super to add behavior rather than 
replace it.

I think that this concept of *implementing* is different than *overriding*.

However, abstract classes can have reasonable definition, and should 
sometimes be overridden in the sense that subclasses should call super.  
For example, when inheriting from AbstractContextManager, you need to 
*override* the abstractmethod (!) __exit__, and if you want your class to 
work polymorphically, you should call super.

This is extremely weird.  Understandably, the pylint people are confused by 
it (https://github.com/PyCQA/pylint/issues/1594) and raise bad warnings.

It also makes it impossible for me to raise warnings in my ipromise 
(https://github.com/NeilGirdhar/ipromise) project.  See, for 
example, 
https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py
 
classes Y and W, which ought to raise, but that would raise on reasonable 
code.

My suggestion is to add a rarely used flag to abstractmethod:

class AbstractContextManager:
@abstractmethod(overrideable=True)
def __exit__(self, exc_type, exc_value, traceback):
pass

This would set a flag on the method like __abstractmethod_overrideable__, 
which could be checked by ipromise's @overrides decorator, pylint's call 
check, and anyone else that wants to know that a method should be 
overridden.

Best,

Neil
___
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] NAN handling in the statistics module

[Neil Girdhar]

On Monday, January 7, 2019 at 3:16:07 AM UTC-5, Steven D'Aprano wrote:
>
> (By the way, I'm not outright disagreeing with you, I'm trying to weigh 
> up the pros and cons of your position. You've given me a lot to think 
> about. More below.) 
>
> On Sun, Jan 06, 2019 at 11:31:30PM -0800, Nathaniel Smith wrote: 
> > On Sun, Jan 6, 2019 at 11:06 PM Steven D'Aprano  > wrote: 
> > > I'm not wedded to the idea that the default ought to be the current 
> > > behaviour. If there is a strong argument for one of the others, I'm 
> > > listening. 
> > 
> > "Errors should never pass silently"? Silently returning nonsensical 
> > results is hard to defend as a default behavior IMO :-) 
>
> If you violate the assumptions of the function, just about everything 
> can in principle return nonsensical results. True, most of the time you 
> have to work hard at it: 
>
> class MyList(list): 
> def __len__(self): 
> return random.randint(0, sys.maxint) 
>
> but it isn't unreasonable to document the assumptions of a function, and 
> if the caller violates those assumptions, Garbage In Garbage Out 
> applies. 
>

I'm with Antoine, Nathaniel, David, and Chris: it is unreasonable to 
silently return nonsensical results even if you've documented it.  
Documenting it only makes it worse because it's like an "I told you so" 
when people finally figure out what's wrong and go to file the bug.
 

>
> E.g. bisect requires that your list is sorted in ascending order. If it 
> isn't, the results you get are nonsensical. 
>
> py> data = [8, 6, 4, 2, 0] 
> py> bisect.bisect(data, 1) 
> 0 
>
> That's not a bug in bisect, that's a bug in the caller's code, and it 
> isn't bisect's responsibility to fix it. 
>
> Although it could be documented better, that's the current situation 
> with NANs and median(). Data with NANs don't have a total ordering, and 
> total ordering is the unstated assumption behind the idea of a median or 
> middle value. So all bets are off. 
>
>   
> > > How would you answer those who say that the right behaviour is not to 
> > > propogate unwanted NANs, but to fail fast and raise an exception? 
> > 
> > Both seem defensible a priori, but every other mathematical operation 
> > in Python propagates NaNs instead of raising an exception. Is there 
> > something unusual about median that would justify giving it unusual 
> > behavior? 
>
> Well, not everything... 
>
> py> NAN/0 
> Traceback (most recent call last): 
>   File "", line 1, in  
> ZeroDivisionError: float division by zero 
>
>
> There may be others. But I'm not sure that "everything else does it" is 
> a strong justification. It is *a* justification, since consistency is 
> good, but consistency does not necessarily outweigh other concerns. 
>
> One possible argument for making PASS the default, even if that means 
> implementation-dependent behaviour with NANs, is that in the absense of 
> a clear preference for FAIL or RETURN, at least PASS is backwards 
> compatible. 
>
> You might shoot yourself in the foot, but at least you know its the same 
> foot you shot yourself in using the previous version *wink* 
>
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list 
> python...@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] async unittest.TestCase

[Neil Girdhar]

Why not just use pytest?

On Wednesday, October 10, 2018 at 7:12:02 AM UTC-4, David Shawley wrote:
>
> Hi everyone and good morning to some of you,
>
> Since asyncio and the async/await syntax are both part of Python, I think
> that we should extend TestCase to support it.  The simplest solution that
> I can think of is to create unittest.AsyncTestCase sub-class with the
> following extensions:
>
>  - create a new event loop and install it in AsyncTestCase.run
>  - make it possible for setUp, tearDown, and test methods to be async
>by calling asyncio.iscoroutinefunction
>
> I wrote my own in a local test before noticing that Martin Richard had
> already written and published asynctest [1].  Since then I found the
> following projects as well:
>
>  - https://github.com/kwarunek/aiounittest
>  - https://github.com/pytest-dev/pytest-asyncio
>
> I think that the community as a whole would benefit from basic support in
> unittest for async/await test "user methods".  I am personally fond of the
> approach of extending unittest.TestCase in asynctest [2] over some of the
> other approaches.
>
> Is this something that we want in our Standard Library?
>
> - dave
> --
> [1]: https://github.com/Martiusweb/asynctest
> [2]: https://github.com/Martiusweb/asynctest/blob/master/asynctest/case.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/

Re: [Python-ideas] Why shouldn't Python be better at implementing Domain Specific Languages?

[Neil Girdhar]

I prefer Python's syntax.  

In the Keras example, Python pays off compared to the XML or YAML or 
whatever as soon as you need to define something programmatically.  For 
example, if your model is generated based on some other input.  

Anyway, most of your time is not spent typing punctuation.  Most of your 
time is spent debugging.

I wish that LaTeX, the DSLs I use, were implemented as a Python package.  
There are a thousand terrible design decision in latex that could all be 
fixed if it had been done as one good Python package.  Maybe LuaTex will 
end up fullfilling the dream.

On Thursday, August 30, 2018 at 9:41:46 PM UTC-4, Guido van Rossum wrote:
>
> On Fri, Aug 31, 2018 at 3:19 AM, Michael Selik  > wrote:
>
>> On Thu, Aug 30, 2018 at 5:31 PM James Lu > 
>> wrote:
>>
>>> It would be nice if there was a DSL for describing neural networks 
>>> (Keras).
>>>
>>> model.add(Dense(units=64, activation='relu', input_dim=100))
>>> model.add(Dense(units=10, activation='softmax'))
>>>
>>>
>> Why not JSON or XML for cross-language compatibility?
>>
>
> Presumably because those are even harder to read and write for humans.
>
> I believe that the key issue with using Python as a DSL has to do with its 
> insistence on punctuation -- the above example uses nested parentheses, 
> commas, equal signs, and quotation marks. Those are in general needed to 
> avoid ambiguities, but DSLs are often highly stylized, and a language that 
> doesn't need them has a certain advantage. For example if a shell-like 
> language was adopted, the above could probably be written with spaces 
> instead of commas, parentheses and equal signs, and dropping the quotes 
> (though perhaps it would be more readable if the equal signs were kept).
>
> I'm not sure how we would go about this though. IIRC there was a proposal 
> once to allow top-level function calls to be written without parentheses, 
> but it was too hard to make it unambiguous (e.g. would "foo +1" mean 
> "foo(+1)" or "foo + 1"?)
>
> -- 
> --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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 9:03 AM Steven D'Aprano  wrote:

> On Wed, Aug 29, 2018 at 09:39:05PM -0700, Neil Girdhar wrote:
>
> > Would there be any problem with changing:
> >
> > In [4]: Fraction(1, 1) ** Fraction(2, 3)
> > Out[4]: 1.0
> >
> > In [5]: Fraction(-1, 1) ** Fraction(2, 3)
> > Out[5]: (-0.4998+0.8660254037844387j)
> >
> > In [6]: Fraction(0, 1) ** Fraction(2, 3)
> > Out[6]: 0.0
> >
> > I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
>
> If anyone else has mentioned the backward-compatibility issue by now, I
> haven't see it. I believe that would make it a fairly big problem.
>
>
I don't think it's that big a problem since Fraction < numbers.Real


> I expect that there is code out in the wild which (for good or ill) now
> expects 1**Fraction(2, 3) to return 1.0, rather than Fraction(1), and
> similarly for the other examples. Changing that could break people's
> code.
>
> Even if we had consensus that this was a good idea, or at least
> consensus from the maths-folk who care about this sort of thing (I'd
> like to know what Uncle Timmy and Mark think of this idea), it would
> still probably need a "__future__" import to activate it, or a
> deprecation period. Or some other annoyance.
>
> Possibly the simpler approach would be to add a subclass that does what
> you want. UnitRootFraction or something.
>
> Then the only argument will be whether such a subclass ought to go into
> the fractions module, or your own personal toolkit :-)
>
> I must admit though, I'm a bit curious as to what you are doing that
> having 1**Fraction(2,3) return 1.0 is an annoyance, but having
> 27**Fraction(2,3) return 8.998 instead of Fraction(9) isn't.
>
> You're right, it would have been better in my example (linked above) to
support all of those things.

>
>
> --
> 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/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

Hey, no worries.  I do think though that people should feel free to suggest
ideas even if they have never contributed anything.  I read python-ideas
for the discussion.  Thank you for your feedback about my suggestion.


On Thu, Aug 30, 2018 at 8:18 AM Jonathan Fine  wrote:

> Hi Neil
>
> When I wrote my previous message, I didn't know who you were, or your
> previous contributions. Perhaps I should have. But I didn't.
>
> If I had known, my remarks would have been different. In particular, I
> would have acknowledged your previous contributions. I apologise for
> any offence I may have caused you.
>
> Better late than never. Thank you for your contributions to
> implementing PEP 448.
>
> with best regards
>
> Jonathan
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

Yeah, you're right, my original mail was posted on google groups.  Sorry
for the trouble.

On Thu, Aug 30, 2018 at 8:15 AM Paul Moore  wrote:

> Thu, 30 Aug 2018 at 12:55, Neil Girdhar  wrote:
> >
> > On Thu, Aug 30, 2018 at 7:13 AM Paul Moore  wrote:
> >>
> >> (You're still not fixing your mail headers. Please do, it's hard to be
> >> bothered responding if I keep having to fix your mails in order to do
> >> so).
> >
> >
> > Sorry about that, I don't understand where it's coming from.   I'm never
> using google groups. I'm only replying to the emails that are sent to me.
> I guess gmail's reply-all is gathering the google groups mail from the
> thread.
>
> Your original mail was sent to Google Groups. Do you have the wrong
> address for the list in your mail client?
>
> Message ID<0067a655-4f82-479f-9970-5b72dc079...@googlegroups.com>
> Created on:30 August 2018 at 05:39 (Delivered after 74 seconds)
> From:Neil Girdhar 
> To:python-ideas 
> Subject:[Python-ideas] Fix some special cases in Fractions?
>
> Paul
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 7:13 AM Paul Moore  wrote:

> (You're still not fixing your mail headers. Please do, it's hard to be
> bothered responding if I keep having to fix your mails in order to do
> so).
>

Sorry about that, I don't understand where it's coming from.   I'm never
using google groups. I'm only replying to the emails that are sent to me.
I guess gmail's reply-all is gathering the google groups mail from the
thread.


> On Thu, 30 Aug 2018 at 11:28, Neil Girdhar  wrote:
> >
> > But I'm only asking for fractional powers of -1, 0, and 1.  Is that
> really a complex issue?
>
> Yes. (Even ignoring the oh-so-tempting complex number joke ;-)). As
> has been seen here there's no agreement on the "right" choice of which
> root of -1 to choose. Or possibly more accurately, no-one else is
> agreeing with your suggestion that we choose a different option for
> the case you're arguing over.
>
> And to be 100% precise, you asked for the results of three *very
> specific* calculations to change. I guess you actually want something
> more general - or are you really OK with (for example)
> Fraction(-1,1)**Fraction(2,3) changing as you request, but
> Fraction(-2,1)**Fraction(2,3) remaining as it currently is? You still
> haven't clarified (no-one has particularly asked yet - you may
> consider this a request to do so if you like) how you propose in
> general that the result of
>
> Fraction(-1,1) ** Fraction(a, b)
> and/or
> Fraction(1,1) ** Fraction(a, b)
> or maybe even more generally
> Fraction(c,d) ** Fraction(a,b)
>
> would change. What exactly are the special cases you want to define
> different results for? What is the process for choosing the result?
>
> > You are right that the fractional power of -1 and 1 has multiple values,
> but the fractional power of zero has a unique value.
>
> And that part of your proposal has not generated much controversy.
> Maybe if you proposed only that, you might get that change made? I
> haven't considered the ramifications of that because the discussions
> about -1 are obscuring it, but it might be relatively uncontroversial.
>
> Paul
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 7:03 AM Jonathan Fine  wrote:

> Hi Neil
>
> Summary: You say something should be done. But by who? Perhaps the
> should starts with you.
>

What does this mean?  Are you asking who is going to do the
implementation?  I posted here to get feedback about whether it would be a
good idea.


>
> Warning: This has been written quickly, and might have rough edges. If
> so, I apologise.
>
> You wrote
>
> > But I'm only asking for fractional powers of -1, 0, and 1.  Is that
> really a
> > complex issue?
>
> > You are right that the fractional power of -1 and 1 has multiple values,
> but
> > the fractional power of zero has a unique value.
>
> >> I'm not really sure a stdlib should even try do deal with that. If I
> want
> >> to have a symbolic way of handling complex power of fractions, I should
> >> import a specific math library whose specific job is to get this right
> (the
> >> same way if you want to do matrix stuff you have to import numpy).
>
> > That's how I use the fractions package.  If you look at my example code,
> > that seems like the kind of problem Fraction should make it easy to work
> > with.  And yet, there was a wrinkle where I had to calculate
> Fraction(-1) **
> > Fraction(a, b).
>
> Let's try to make the best of what we've got.
>
> First, the docs for the fraction module could be improved. Here's the
> page and it's history.
>
> https://docs.python.org/3/library/fractions.html
>
> https://github.com/python/cpython/commits/3.7/Doc/library/fractions.rst
>
> Already, doing this will help users. In particular, for a different
> approach, point them to
>
> https://www.sympy.org/en/index.html
>
> Second, assume you're right, when you say
>
> > [This sort of problem], Fraction should make it easy [...]
>
> The problem is, Python development resources are finite. They should
> be more, but they're not. It's hard to go from 'Fraction should' to
> ' should'. Perhaps the best one can come up with
> is the developers of fraction.py. Here's the page and history.
>
> https://github.com/python/cpython/blob/3.7/Lib/fractions.py
> https://github.com/python/cpython/commits/3.7/Lib/fractions.py


Thanks for linking the github.  I'm only posting on ideas to get feedback.
I think this is what the group is for.  Also, I don't know why you keep
bringing up the finite Python developer resources.  Like I said above, this
is a small change, (one that I coded below).  Besides that bit of code, I
could add a few tests, and modify the docs.  Someone would have to review
it, but it's not a big job.  The only question is: should it be done?  And
that's why I posted it here.

>
>
> Third, there is a way to go from 'Fraction should' to a group of
> persons. If you're correct, that 'Fraction should', then I'm happy to
> say that it follows that 'the Python community should'.
>
> Now, the Python community is vast. It's more than the core developers.
> I'm a member. You're a member. Everyone participating on this list is
> a member. It's got lots of resources.
>
> You want this problem solved. You've got clear ideas what should be
> done. You say it should be done. And you're a member of the Python
> community, who 'should fix this problem'.
>
> The module fractions.py is pure Python. You can fork it to develop
> your own solution, written as it should be. You can use this solution
> and share it with the community. And you can submit it as a pull
> request, for inclusion in the standard library.
>

Before I do that, I want to get feedback here.  The way I understand the
usual order with feature requests is that they are discussed, they turn
into PEPs, they are approved, they are implemented, they are reviewed, they
are checked in.  Someone will definitely correct me.  No one wants to spend
time writing documentation for code that will never be checked in.


> To summarise. You're part of the Python community, who you believe
> should solve this problem. Please, as a member of the community,
> accept some responsibility for do what you think should be done.


Maybe I'm interpreting this wrong, but what do you mean by "accept some
responsibility"?  The last time I felt strongly about a feature (PEP 448),
and after it had been approved by Guido, I spent a few months implementing
it along with Joshua Landau (https://bugs.python.org/issue2292).  Compared
to this tiny change, that was a huge change involving the parser, the
compiler, and the grammar.  I really don't understand what you're driving
at with this "accept some responsibility" comment.


>
And finally, thank you for drawing to our attention this blemish in
> the fractions module (or its documentation).
>
> --
> Jonathan
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

Thanks for the feedback.

On Thu, Aug 30, 2018 at 7:13 AM Paul Moore  wrote:

> (You're still not fixing your mail headers. Please do, it's hard to be
> bothered responding if I keep having to fix your mails in order to do
> so).
>
> On Thu, 30 Aug 2018 at 11:28, Neil Girdhar  wrote:
> >
> > But I'm only asking for fractional powers of -1, 0, and 1.  Is that
> really a complex issue?
>
> Yes. (Even ignoring the oh-so-tempting complex number joke ;-)). As
> has been seen here there's no agreement on the "right" choice of which
> root of -1 to choose. Or possibly more accurately, no-one else is
> agreeing with your suggestion that we choose a different option for
> the case you're arguing over.
>
> And to be 100% precise, you asked for the results of three *very
> specific* calculations to change. I guess you actually want something
> more general - or are you really OK with (for example)
> Fraction(-1,1)**Fraction(2,3) changing as you request, but
> Fraction(-2,1)**Fraction(2,3) remaining as it currently is?


Powers of other numbers have to keep the same behavior since in general
those kinds of expressions don't create rational numbers.


> You still
> haven't clarified (no-one has particularly asked yet - you may
> consider this a request to do so if you like) how you propose in
> general that the result of
>
> Fraction(-1,1) ** Fraction(a, b)
> and/or
> Fraction(1,1) ** Fraction(a, b)
> or maybe even more generally
> Fraction(c,d) ** Fraction(a,b)
>
> would change. What exactly are the special cases you want to define
> different results for? What is the process for choosing the result?
>

Here's my proposed method:

class Fraction:
def __pow__(a, b):
"""a ** b
If b is not an integer, the result will be a float or complex
since roots are generally irrational. If b is an integer, the
result will be rational.
"""
if isinstance(b, numbers.Rational):
if b.denominator == 1:
power = b.numerator
if power >= 0:
return Fraction(a._numerator ** power,
a._denominator ** power,
_normalize=False)
elif a._numerator >= 0:
return Fraction(a._denominator ** -power,
a._numerator ** -power,
_normalize=False)
else:
return Fraction((-a._denominator) ** -power,
(-a._numerator) ** -power,
_normalize=False)
elif a == -1 and b.denominator % 2 == 1:
return Fraction(-1 if b.numerator % 2 == 1 else 1)
elif a == 0:
if b > 0:
return Fraction(0)
else:
raise ZeroDivisionError(
"0 cannot be raised to a negative power")
elif a == 1:
return Fraction(1)
else:
# A fractional power will generally produce an
# irrational number.
return float(a) ** float(b)
else:
return float(a) ** b

Compare it with
https://github.com/python/cpython/blob/3.7/Lib/fractions.py#L448


>
> > You are right that the fractional power of -1 and 1 has multiple values,
> but the fractional power of zero has a unique value.
>
> And that part of your proposal has not generated much controversy.
> Maybe if you proposed only that, you might get that change made? I
> haven't considered the ramifications of that because the discussions
> about -1 are obscuring it, but it might be relatively uncontroversial.
>

Fair enough.

>
> Paul
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 5:51 AM Nicolas Rolin 
wrote:

>
>
>
>>> Right, but we already have some special cases:
>>
>> In [8]: Fraction(2, 3) ** Fraction(3, 1)
>> Out[8]: Fraction(8, 27)
>>
>> Fraction.__pow__ already tries to return Fraction objects where possible.
>>
>
>
> I think the main point to see here is what the scope of a built-in
> function should be.
> For a fraction module in the stdlib, I would expect that it handle
> "symbolically" any fraction multiplication or division of fractions, and
> integer power of fractions.
> Those are simple and useful cases, that can arise a bit anywhere. Power of
> non-integer is a way more complex issue (notably because power of a
> non-integer is not a function), and returning the same output as float is
> at least an honest way of dealing with those cases.
>

But I'm only asking for fractional powers of -1, 0, and 1.  Is that really
a complex issue?

You are right that the fractional power of -1 and 1 has multiple values,
but the fractional power of zero has a unique value.

>
> I'm not really sure a stdlib should even try do deal with that. If I want
> to have a symbolic way of handling complex power of fractions, I should
> import a specific math library whose specific job is to get this right (the
> same way if you want to do matrix stuff you have to import numpy).
>

That's how I use the fractions package.  If you look at my example code,
that seems like the kind of problem Fraction should make it easy to work
with.  And yet, there was a wrinkle where I had to calculate Fraction(-1)
** Fraction(a, b).


>
> --
>
> *Nicolas Rolin*
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 5:27 AM Greg Ewing 
wrote:

> Neil Girdhar wrote:
> > we want branch continuity in the power.
> > After all, floating point values have some inaccuracy, and we wouldn't
> > want chaotic behavior, i.e., small changes to the power to have drastic
> > changes to the result.
> >
> > This is not like Fraction where we know that x ** Fraction(1, 3) is a
> > genuine cube root, and so why not return the principal cube, which we
> > know to be real valued for real valued x?
>
> Because that would be possible only for a few special combinations
> of Fractions ** Fractions that happen to have rational solutions. All
> the others would still have to return float or complex results,
> which could then be discontinuous with the rational ones.
>
> Right, but we already have some special cases:

In [8]: Fraction(2, 3) ** Fraction(3, 1)
Out[8]: Fraction(8, 27)

Fraction.__pow__ already tries to return Fraction objects where possible.

-- 
> Greg
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 5:11 AM Jonathan Fine  wrote:

> Hi Neil
>
> We wrote
>
> >> This gives the same results as Python's Fraction, except for your
> >> example [6]. There, it gives the Fraction(0) you ask for.
> >>
> >> If the smart mathematicians and computer scientists that wrote gp/pari
> >> get the same answers, it suggests to me that improvement would be
> >> hard.
>
> > That's because these are just floating point numbers.  These are not
> being
> > processed symbolically.  Wolfram Alpha gives all three roots, including
> the
> > real root.
>
> I've not used Wolfram Alpha, nor I think have many people on this
> list. Please copy and paste the input and output from Alpha, so we can
> see for ourselves (and so there's a record on this list).
>

It's online for everyone to use:
http://www.wolframalpha.com/input/?i=(-1)+%5E+(1%2F3)


>
> If anyone has time and ready access, it would help to know what
> https://www.sympy.org/en/index.html does with this.
>
> Perhaps your innocent request conceals a request for symbolic handling
> of simple algebraic numbers.
>

Well, rational numbers.  Although an algebraic number type would be
interesting.  And, the way I see it, Fraction is the type corresponding to
the field of rational numbers.


>
> --
> best regards
>
> Jonathan
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 4:38 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Neil Girdhar writes:
>
>  > There are a lot of misunderstandings in this thread.  It's probably
>  > best to start by reading up on the roots of unity (
>  > https://en.wikipedia.org/wiki/Root_of_unity).
>
> That's not very polite, especially in context where somebody has
> already conceded that his "wrong" was over the top.
>
> Speaking of courtesy, please stop clean up your addressee list.  If
> you don't, GoogleGroups spams people who reply with "you're not a
> member".
>
>  > same for the cube root I imagine if we had a cube root function  Let's
> call
>  > that the principal cube root, which is always real for a
>  > real-valued input.
>
> That doesn't seem to be how Wolfram sees it:
>
> http://mathworld.wolfram.com/PrincipalRootofUnity.html


Right, I meant real root.   It just happens the principal square root is
the real root.
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 4:01 AM Paul Moore  wrote:

> On Thu, 30 Aug 2018 at 08:38, Neil Girdhar  wrote:
> >
> > There are a lot of misunderstandings in this thread.  It's probably best
> to start by reading up on the roots of unity (
> https://en.wikipedia.org/wiki/Root_of_unity).  The key ideas are that a
> real number has two complex square roots, three complex cube roots, and so
> on.
>
> The complexities of fractional powers aside, the type of a result
> should not depend on the values of the arguments. So I'm -1 on this
> change for that reason alone.
>
>
Just so you know, it already does depend on the type of the arguments.

In [4]: Fraction(2) ** Fraction(1, 2)
Out[4]: 1.4142135623730951

In [5]: Fraction(2) ** Fraction(3, 1)
Out[5]: Fraction(8, 1)

Like a lot of types, Fraction tries to return a Fraction if it can.  This
is consistent with how math.sqrt of a float returns a float and never a
complex, and same for numpy.cbrt.

Questions of which root it's appropriate to take are separate, and IMO
> the sensible option is to follow the behaviour of float, for which we
> have
>
> >>> (-1)**(2/3)
> (-0.4998+0.8660254037844387j)
>

But -1 ** Fraction(2, 3) is closer to cube_root(-1 ** 2) than it is to the
floating behavior.

The reason the floating behavior returns what it does is, if I understand
correctly, to try to stay on the same complex branch as the power varies.
In other words, we want branch continuity in the power.  After all,
floating point values have some inaccuracy, and we wouldn't want chaotic
behavior, i.e., small changes to the power to have drastic changes to the
result.

This is not like Fraction where we know that x ** Fraction(1, 3) is a
genuine cube root, and so why not return the principal cube, which we know
to be real valued for real valued x?

>>> (1)**(2/3)
> 1.0
> >>> (0)**(2/3)
> 0.0


> So current behaviour of Fraction is correct on that basis, IMO.
>
> Paul
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

There are a lot of misunderstandings in this thread.  It's probably best to
start by reading up on the roots of unity (
https://en.wikipedia.org/wiki/Root_of_unity).  The key ideas are that a
real number has two complex square roots, three complex cube roots, and so
on.

Normally, in Python, we return the principal square root (
http://mathworld.wolfram.com/PrincipalSquareRoot.html).  We would do the
same for the cube root I imagine if we had a cube root function  Let's call
that the principal cube root, which is always real for a real-valued input.

---

> For positive numbers, I believe you're correct. For negative numbers, no.

Actually, Jonathan is right.

>>> (-2)**(2/3)
(-0.7937005259840993+1.3747296369986026j)

This is just giving you one of the other two cube roots.

> Rounding error aside, raising -2 to 2/3 power and then raising the result
to 3/2 power gives back -2, as it should.

There is no way to guarantee that "it should do this".  A fractional power
is not a function, and so it has no inverse function.

> Doing it in two steps loses the negation, and then (again, within
rounding error) the end result is positive two.

I think you would see your mistake if you applied this logic to -1 ** 2 **
(1/2).


On Thu, Aug 30, 2018 at 3:08 AM Greg Ewing 
wrote:

> Jonathan Goble wrote:
> > How? Raising something to the 2/3 power means squaring it and then
> > taking the cube root of it.
>
> On reflection, "wrong" is not quite accurate. A better
> word might be "surprising".
>
> (-1) ** (2/3) == 1 would imply that 1 ** (3/2) == -1.

I suppose that could be considered true if you take the
> negative solution of the square root, but it seems a
> bit strange, and it's not what Python gives you for
> the result of 1 ** (3/2).
>

Python gives you the principle root when you do 1 ** (3/2), which is
exactly what I'm proposing for Fraction.


> If you want a solution that round-trips, you need
> complex numbers.


There is no solution that round trips since in general fractional powers
are not functions.  The case in which you can always round trip is when you
are taking a power c ** (a/b) where a is odd, and either c is positive or b
is odd.  Then, the result to the power of (b/a) gives you c.

That's what Python does when you use
> floats. Making Fractions do something different would
> make it inconsistent with floats.
>

Actually, my cases are all examples of the principal roots and are
consistent with floats.


>
> My calculator (which only does real floats) reports an
> error when trying to evaluate (-1) ** (2/3).
>

Yes, which is what Python does with reals.  The difference is the the
Fraction type has exact values, and it knows that the unique answer in the
field of Fraction objects is 1.

>
> --
> Greg
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

On Thu, Aug 30, 2018 at 2:09 AM Greg Ewing 
wrote:

> Jeroen Demeyer wrote:
> > On 2018-08-30 06:39, Neil Girdhar wrote:
> >
> >> I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
> >
> > Why? I cannot think of any natural use case why you would want Fractions
> > for a few special cases on an operation which returns non-Fractions
> > generically.
>
> Also, Fraction(1) for the second case would be flat-out wrong.
>

No, it's not "wrong".  1 is one of the cube roots of 1.  It's consistent
with 1 ** (2/3) == 1.

-- 
> Greg
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/aZIHpPhe0mw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Fix some special cases in Fractions?

[Neil Girdhar]

Would there be any problem with changing:

In [4]: Fraction(1, 1) ** Fraction(2, 3)
Out[4]: 1.0

In [5]: Fraction(-1, 1) ** Fraction(2, 3)
Out[5]: (-0.4998+0.8660254037844387j)

In [6]: Fraction(0, 1) ** Fraction(2, 3)
Out[6]: 0.0

I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
___
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] Python docs page: In what ways is None special

[Neil Girdhar]

Is None a builtin?

In [1]: from keyword import kwlist

In [3]: 'Ellipsis' in kwlist
Out[3]: False

In [4]: 'None' in kwlist
Out[4]: True

Maybe we should change
This type has a single value. There is a single object with this value. 
This object is accessed through the built-in name None. It is used to 
signify the absence of a value in many situations, e.g., it is returned 
from functions that don’t explicitly return anything. Its truth value is 
false.

to

This type has a single value. There is a single object with this value. 
This object is accessed through the keyword None. It is used to signify the 
absence of a value in many situations, e.g., it is returned from functions 
that don’t explicitly return anything. Its truth value is false.

Best,

Neil

On Monday, July 23, 2018 at 2:31:21 PM UTC-4, Jörn Heissler wrote:
>
> On Mon, Jul 23, 2018 at 10:03:10 +0100, Jonathan Fine wrote:
> > I thought, a page on how None is special would be nice.
> > I've not found such a page on the web. We do have
> > ===
> > https://docs.python.org/3/library/constants.html
>
> Hi,
>
> there's also
>
> https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
>
> None
>
> This type has a single value. There is a single object with this
> value. This object is accessed through the built-in name None. It is
> used to signify the absence of a value in many situations, e.g., it
> is returned from functions that don’t explicitly return anything.
> Its truth value is false.
>
>
> Cheers
> Jörn Heissler
> ___
> Python-ideas mailing list
> python...@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] Reminder about intent of messages (Was: Syntactic sugar to declare partial functions)

[Neil Girdhar]

I don't really want to get involved in this, but I feel like everyone is
piling up on Abe unfairly.

On Mon, Aug 13, 2018 at 1:14 AM Ryan Gonzalez  wrote:

> Now that the discussion has officially devolved into something that has
> absolutely nothing to do with the original topic, I'd like to point out
> something: (Note that I have no affiliation with the managers of this
> mailing list at all and am just posting this as an outsider.)
>
> In Steven D'Aprano's original message, I didn't see anything there as
> being a personal attack or as having an angry tone, at least based on his
> normal posting style. Maybe a bit critical and stern, but not really
> personal. You may have interpreted it as that, but I seriously doubt it was
> the intention.
>

When Abe wrote just this: "but I think they would (or do in the case of
'lambda') harm Python" — which is nothing but an opinion.  We're all
welcome to our opinions without having to prove them like lawyers.

Steve replied this:  "That's an extreme overreaction.

Do you mean to imply that there are people who looked at Python, loved
the language, but decided to use something else because they didn't like
the choice of the keyword "lambda"?

If not, in what way is Python harmed? Would it be faster if the keyword
was "function", or use less memory, or more expressive?"

To my perhaps tender Canadian ears, that is incredibly abrasive.  Steve
could have just explained why he felt differently without slamming Abe's
opinion as "an extreme overreaction" and then diving into a set of
rhetorical questions that assume an extreme reading of Abe's statement.

Now, as you say, this is Steve's usual posting style.  But new people don't
know him.  I also found him quite abrasive when I started posting here, but
then I noticed that it's not personal and he treats everyone this way.

There are some great posters here, and I like to read python-ideas because
I learn so much from them: Nick, Antoine, Brett, and Nathaniel to name a
few, but there are many more.  I think it's important for newcomers to try
to be respectful, but it's also important to treat newcomers with the same
kindness you would treat a guest in your home.

Best,

Neil


> I'd like to propose an alternative to Hanlon's razor, the Internet razor:
>
> Never attribute to malice that which is adequately explained by lack of
> context in online conversations.
>
> Online, there is no tone of voice, facial expressions, or extra context to
> really help distinguish intent. Misinterpreting has been a classic issue
> that's been around for ages and has only gotten worse. When writing a
> message, we're responsible for ensuring that the intent is clearly
> portrayed. When reading a message, we're responsible for correctly
> interpreting such intent, and everyone is usually better off if, when in
> doubt, the interpretation leans towards ambiguity over malice.
>
> On Sun, Aug 12, 2018, 11:57 PM Abe Dillon  wrote:
>
>> [Alex Walters]
>>
>>> He is questioning the concept that the lambda keyword has caused any
>>> harm.  You assert that it caused minor harm.  Minor harm can still be real,
>>> significant, and non-trivial.
>>
>> What, exactly, is the difference between "minor" and "non-trivial" and
>> when did I say the harm was "significant and non-trivial"?
>>
>> [Alex Walters]
>>
>>> You will find no evidence to support your argument.
>>>
>> You could read what I wrote to Neil Girdhar who was able to engage with
>> me without implying that I've lost my mind.
>>
>> [Chris Angelico]
>>
>>> If your reaction was extreme, saying so isn't attacking you.
>>
>> Is this a hypothetical now? I said "*I think* they would (or do in the
>> case of 'lambda') harm Python." I wasn't aware the word "harm" was
>> something only deranged maniacs use.
>>
>> [Chris Angelico]
>>
>>> Explain, please, what the HARM is that comes from the use of the word
>>> "lambda".
>>
>>
>> I HAVE.
>>
>> [Chris Angelico]
>>
>>> Also, the signature is most decidedly NOT obvious from context
>>
>> Who decided this? It's been decided by some committee? When you write a
>> key function, you don't know how many arguments are going to be passed?
>>
>> [Chris Angelico]
>>
>>> nor is it insignificant.
>>
>>
>> I never said it was. I just said that the logic is more important from
>> the standpoint of the reader.
>>
>> [Chris Angelico]
>>
>>> Putting it first gives context to the body of the
>>> function. Python made the correct choice here.
>>

Re: [Python-ideas] Is this PEP-able? "with" statement inside genexps / list comprehensions

[Neil Girdhar]

On Monday, July 30, 2018 at 3:55:25 PM UTC-4, Kyle Lahnakoski wrote:
>
> Rudy,
>
> I think your proposal may be very specific to iterable context managers;
>

I don't think his proposal is specific to iterable context managers.  You 
can have a with clause that is used in a following for clause. 

in which case, make a method that makes that assumption:
>
> > def iter_with(obj):
> > with obj as context:
> > yield from context
>
> and use it
>
> > g = (
> > f.read()
> > for fn in filenames
> > for f in iter_with(open(fn))
> > )
>
> On 2018-07-30 15:15, Rudy Matela wrote:
> > Hello,
> >
> > Do you think it would be nice to allow with statements inside genexps or
> > list comprehensions?  The functions __enter__ and __exit__ would be
> > automatically called as iterables are traversed.  I am thinking of
> > drafting a PEP about this.  Examples:
> >
> >
> > This 
> >
> > g = (f.read() for fn in filenames with open(fn) as f)
> >
> > would be equivalent to the following use of a generator function:
> >
> > def __gen():
> > for fn in filenames:
> > with open(fn) as f:
> > yield f.read()
> > g = __gen()
> >
> >
> > This
> >
> > list = [f.read() for fn in filenames with open(fn) as f]
> >
> > would be equivalent to the following:
> >
> > list = []
> > for fn in filenames:
> > with open(fn) as f:
> > list.append(f.read())
> >
> > --
> > Rudy
> > ___
> > Python-ideas mailing list
> > python...@python.org 
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> python...@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] Consider adding an iterable option to dataclass

[Neil Girdhar]

My only motivation for this idea is so that I can forget about namedtuple.
Thinking about it again today, I withdraw my suggestion until I one day see
a need for it.

On Fri, Aug 10, 2018 at 10:14 PM Eric V. Smith  wrote:

> On 8/10/2018 7:01 PM, Neil Girdhar wrote:
> > It would be nice if dataclasses
> > (
> https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass)
> > had an option to make them a sequence.  This would make
> >
> > dataclass(frozen=True, order=True, sequence=True)
> >
> > an optionally-typed version of namedtuple.  It would almost totally
> > supplant it except that namedtuples have a smaller memory footprint.
>
> Note that type.NamedTuple already gives you typed namedtuples.
> Admittedly the feature set is different from dataclasses, though.
>
> > sequence would simply inherit from collections.abc.Sequence and
> > implement the two methods __len__ and __getitme__.
>
> Unless I'm misunderstanding you, this falls in to the same problem as
> setting __slots__: you need to return a new class, in this case since
> you can't add inheritance after the fact. I don't think
> __isinstancecheck__ helps you here, but maybe I'm missing something (I'm
> not a big user of inheritance or ABCs).
>
> Not that returning a new class is impossible, it's just that I didn't
> want to do it in the first go-round with dataclasses.
>

That's a fair point.  I'm sure you know that your decorator could always
return a new class that inherits from both Sequence and the original
class.  As a user of dataclass, I never assumed that it wouldn't do this.


> For slots, I have a sample @add_slots() at
> https://github.com/ericvsmith/dataclasses/blob/master/dataclass_tools.py.
> Maybe we could do something similar with @add_sequence() and test it
> out? It would have to be a little more sophisticated than @add_slots(),
> since it would need to iterate over __dataclass_fields__, etc.
>
> I'm on vacation next week, maybe I'll play around with this.
>

Cool, have a great vacation.

>
> Eric
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/8C9iVJsba5A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Consider adding an iterable option to dataclass

[Neil Girdhar]

It would be nice if dataclasses 
(https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass) 
had an option to make them a sequence.  This would make

dataclass(frozen=True, order=True, sequence=True)

an optionally-typed version of namedtuple.  It would almost totally 
supplant it except that namedtuples have a smaller memory footprint.

sequence would simply inherit from collections.abc.Sequence and implement 
the two methods __len__ and __getitme__.

Best,

Neil
___
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] Syntactic sugar to declare partial functions

[Neil Girdhar]

On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon  wrote:

> [Neil Girdhar]
>
> I prefer partial since many programmers studied computer science
>
>
> Many did not. I studied electrical engineering and wouldn't have been able
> to tell you what the word 'partial' meant four years ago even though I've
> been programming in one form or another since the late nineties. Many
> programmers are scientists, engineers, financial analysts, etc. I'm pretty
> sure I know what a closure is or what currying is, but if you put me on the
> spot, I'd probably turn to Wikipedia to make sure I don't screw up the
> definition.
>
> [Neil Girdhar]
>
>> It makes the concepts easier to google.
>
>
> That can be an important criteria, but it can also be a red-herring. If an
> implementation is clear enough, few people would have to google it. If,
> however, you use obscure enough words like "lambda", people will google it
> every day and still find it confusing. The ternary expression is difficult
> to google if you don't know the jargon "ternary", but there's less of a
> need to google it because it's pretty obvious how it works based simply on
> its implementation.
>
> [Steven D'Aprano]
>
>> It's a clear, *generic* meaning that doesn't have any association with
>> partial application.
>> We'd be trying to create that association from scratch.
>
>
> Sure, that's a good point. I don't think that sounds like such a big
> problem, but I also don't hate 'partial'. I just prefer 'given'.
> At any rate, I don't find the google-ablilty argument super strong because
> there are many constructs that are difficult to google, but still pretty
> great (e.g. comprehensions).
>
Not that it matters, but comprehension is a standard term in mathematics
and computer science apparently:

https://en.wikipedia.org/wiki/List_comprehension
https://en.wikipedia.org/wiki/Set-builder_notation


> [Steven D'Aprano]
>
> > Words like 'partial', 'curry', 'lambda', and 'closure' are fine
>> > for text books, published papers, and technical discussion,
>> And programmers.
>>
>
> Yes, technical discussion among programmers.
>
> [Steven D'Aprano]
>
> Programming is a technical skill with its own jargon. Classes,
>> inheritence, exceptions, trampolining, processes, threads, protocols,
>> imports, decorator, builders... we are happy with all those, why should
>> we fear partial and lambda?
>
>
> I get that programming carries it's own jargon and I understand that it
> has a beneficial function. It can facilitate concise communication of
> nuanced concepts. It can also be a needlessly confusing way to convey
> otherwise simple concepts. In the latter case, it can feel like the intent
> is to create an air of superiority through esoteric language. I feel like
> "curry" and "lambda" are needlessly un-descriptive and confusing. "partial"
> really isn't that bad, I just prefer "given" because I think it's pretty
> clear. I've never heard of "trampolining", but if I had to guess: it's
> probably related to recursion that involves more than one function?
>
> I suspect that most programmers couldn't describe the difference between a
> type and a class.
> I suspect that most programmers couldn't tell you the difference between
> an exception or an error.
> I know that lots of programmers refer to the "__init__" method as a
> "constructor" instead of an "initializer".
>
> Precision is less of a problem In a programming language. `func.given`
> doesn't have dozens of possible meanings. It's meaning has to be completely
> unambiguous to the machine.
>
> [Steven D'Aprano]
>
> > but I think
>> > they would (or do in the case of 'lambda') harm Python.
>> That's an extreme overreaction.
>
>
> Extreme? I thought it was a rather benign opinion. I'm not exactly
> frothing at the mouth here. It's not like I'm declaring holy war on Python
> for using the word 'lambda'. I just think it was a mistake (and thatdeath
> should come to all non-believers).
>
> [Steven D'Aprano]
>
> Do you mean to imply that there are people who looked at Python, loved
>> the language, but decided to use something else because they didn't like
>> the choice of the keyword "lambda"?
>
>
> No. Not at all. Is that what you got out of my sentence? Am I really the
> one being extreme?
>

I didn't think you were being extreme at all.  I think you're making a
reasonable point about keeping things simple.

I disagree with you though when it comes to avoiding the technical terms.
It's easier for people new to a field to learn the jargon of that field
than it is to try

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Neil Girdhar]

I prefer partial since many programmers studied computer science, and also
it makes the concepts easier to google.

Anyway, I don't actually want either a partial member nor new syntax for
this, but if I had to choose, I'd choose no new syntax.

On Thu, Aug 9, 2018 at 2:32 PM Abe Dillon  wrote:

> I'd like to push for the less jargon-y `func.given()` version if this
> gains traction. Not only is it shorter, it's a much more common term with a
> clear meaning. Words like 'partial', 'curry', 'lambda', and 'closure' are
> fine for text books, published papers, and technical discussion, but I
> think they would (or do in the case of 'lambda') harm Python. I know the
> correct term for the 'if-else' expression is a 'ternary' expression, but
> that doesn't mean Python should have used the word 'ternary' in the syntax.
>
> On Thu, Aug 9, 2018 at 12:14 PM, Neil Girdhar 
> wrote:
>
>> That's a nicer solution to me.
>>
>> On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin <
>> desmoulinmic...@gmail.com> wrote:
>>
>>> I'd rather have functools.partial() to be added as a new method on
>>> function objects.
>>>
>>> >
>>> > fromfunctools importpartial
>>> >
>>> >
>>> > def add(x:int,y:int)->int:
>>> > returnx +y
>>> >
>>> >
>>> > add_2 = partial(add,2)
>>> >
>>>
>>> Would become:
>>>
>>> add_2 = add.partial(2)
>>>
>>> Nothing to change on the parser, no obscure syntax for future readers,
>>> and we can get the opportunity of rewriting partial() in C as right now
>>> it is amazingly way, way slower than a lambda.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "python-ideas" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/python-ideas/jOMinivFCcQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> python-ideas+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> ___
>> 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] Syntactic sugar to declare partial functions

[Neil Girdhar]

That's a nicer solution to me.

On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin 
wrote:

> I'd rather have functools.partial() to be added as a new method on
> function objects.
>
> >
> > fromfunctools importpartial
> >
> >
> > def add(x:int,y:int)->int:
> > returnx +y
> >
> >
> > add_2 = partial(add,2)
> >
>
> Would become:
>
> add_2 = add.partial(2)
>
> Nothing to change on the parser, no obscure syntax for future readers,
> and we can get the opportunity of rewriting partial() in C as right now
> it is amazingly way, way slower than a lambda.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/jOMinivFCcQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Revisiting dedicated overloadable boolean operators

[Neil Girdhar]

Oh, I see, I thought he wanted to override the original logical operators.

I don't like adding more operators just to make symbolic equation
generation simpler.  I think keeping the language simple and using the
"numpy.logical_and" function is better than making the language more
complicated for a small fraction of users.

There will always be a gap between Python and symbolic equation generation.

On Mon, Aug 6, 2018 at 9:03 PM Steven D'Aprano  wrote:

> On Mon, Aug 06, 2018 at 02:44:24PM -0700, Neil Girdhar wrote:
>
> > This doesn't work because the logical Boolean operators short circuit in
> > Python.  So you could not even define these operators for the regular
> > Python types.
>
> Todd is not proposing to add dunder methods for the existing "or" and
> "and" operators.
>
> Todd is proposing four new operators spelled "bAND", "bOR", "bXOR" and
> "bNOT", which aren't short-circuiting and call dunder methods, just like
> other operators including "in".
>
> You seem to be saying that "this" (defining new operators that call
> dunder methods) doesn't work because a set of *completely different*
> existing operators short-circuit. If that's not what you meant, I
> don't understand what you actually did mean.
>
>
> > Your two examples numpy and SQLAlchemy don't want this
> > short-circuiting behavior, so you would never want to write anything like
> >
> > (some_array or some_other_array)
> >
> > The reader of this code might imagine that there is some short
> circuiting
> > or conversion to Boolean.
>
> Fortunately Todd isn't proposing that.
>
>
> --
> 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/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/LgwmlPp6YqM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Syntactic sugar to declare partial functions

[Neil Girdhar]

By the way, these are not "partial functions", and shouldn't be called 
that.  These are "partial function applications".

On Saturday, August 4, 2018 at 12:03:50 PM UTC-4, Fabrizio Messina wrote:
>
>  
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment we have to load the *partial* function from the *functool* 
> library, and apply it to an existing function, e.g. 
>
> from functools import partial
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
>
> add_2 = partial(add, 2)
>
>
>
> While partial expose the mechanism excellently its instantiation method 
> is, at times, not very friendly, I would like to propose a syntactic sugar 
> to create partial functions, in the case you create a partial function 
> using *curly braces*:
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add{2}
>
>
> At the moment this causes SyntaxError so the change is retro-compatible.
>
> In the case of key word arguments we could have:
>
> sort_by_x = sort{key=lambda element: element.x}
>
>
> That could be good as it would be an easy way to pre-load functions 
> without having to eagerly compute it, but without needing to pass the 
> entire function parameters to to other scopes.
>
>
> # prepare the function
> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda 
> user: user.creation_date}
>
> # continue with job at hand
> ...
>
> # some where else, maybe another process
> sorted_users = list(get_sorted_users())
>
>
>
> Even create a factory method on the fly:
> @dataclass
> class Product:
> name: str
> category: Category
> price: Decimal
>
>
> smartphone_factory = Product{category=smartphone_category}
>
>
>
> Now all this can already be done with partial, but adding this syntactic 
> sugar would reduce the perception of `partial` as an advanced feature, 
> alleviating the use of closures created only for the sake of avoiding an 
> explicit partial.
>
> In my opinion this syntactic sugar has a lot of potential adoption seen 
> the general interest in functional programming.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/