[Python-ideas] Re: Additional LRU cache introspection facilities

[Sebastian Kreft]

Actually you can get the cache data from the python version, for that you
need to force the use of the python version of functools

def get_cache(f):
freevars = f.__code__.co_freevars
index = freevars.index('cache')
return f.__closure__[index].cell_contents

import importlib.abc

class ForcePythonLruCache(importlib.abc.MetaPathFinder):
def find_spec(self, fullname, path, target=None):
if fullname == '_functools':
raise ImportError('_functools not available')

import sys
del sys.modules['functools']
del sys.modules['_functools']



import functools

@functools.lru_cache
def test(x):
return x

test(1)
test(2)
test('a')
test('foo')

print(list(get_cache(test).keys()))

On Tue, Jan 12, 2021 at 4:09 PM Paul Moore  wrote:

> On Tue, 12 Jan 2021 at 17:16, Christopher Barker 
> wrote:
> >
> > Is the implementation of lru_cache too opaque to poke into it without an
> existing method? Or write a quick monkey-patch?
> >
> > Sorry for not checking myself, but the ability to do that kind of thing
> is one of the great things about a dynamic open source language.
>
> I've only looked at the Python implementation, but the cache is a
> local variable in the wrapper, unavailable from outside. The cache
> information function is a closure that references that local variable,
> assigned as an attribute of the wrapped function.
>
> It's about as private as it's possible to get in Python (not
> particularly because it's *intended* to hide anything, as far as I can
> tell, more likely for performance or some other implementation
> reason).
>
> 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/C6YULKSV5RV36WSWMGKWPMLUFDL7YN2Y/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/EK5DBSL57BMXEQTD7JYC3GVRN2T3YH6K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow writing optional types as ?int

[Sebastian Kreft]

There's already a proposal. See
https://gist.github.com/MaggieMoss/c848cb3a581979f445d075c15629c950 and
https://mail.python.org/archives/list/typing-...@python.org/thread/SWAY6V7WZLVPGYQEMHXJROT2747OXSRX/


On Wed, Oct 7, 2020 at 9:50 AM Sebastian Noel Lübke 
wrote:

> Hey,
> python 3.9 introduced the | operator for union types. it would be nice to
> have something like that for optional types. maybe like
>
> name: ? int
> or
> name: int ?
>
> best regards
> Sebastian Lübke
> ___
> 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/UPQHZKZTG4UTWKF4Z5GO65PXOZBAEBUT/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/327HT6VZ2L6NKGNV6EMF6AS6BPMALLCY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

[Sebastian Kreft]

On Wed, Sep 30, 2020 at 2:44 AM Steven D'Aprano  wrote:

> On Sun, Sep 27, 2020 at 07:59:18AM -0300, Sebastian Kreft wrote:
>
> > Hi Steven, could you share some examples of what you have in mind.
> Having a
> > more concrete example of an API that would benefit from
> mixed-subscripting
> > would allow us to better understand its usefulness.
>
> I have an experimental Matrix class:
>
> https://en.wikipedia.org/wiki/Matrix_(mathematics)
>
> There are (at least) three indexing operations needed:
>
> - row
> - column
> - individual cell
>
> The first two support get, set and delete; the last supports
> only get and set.
>
> One obvious API would be a keyword to disambiguate between the first two
> cases:
>
> matrix[3, 4]   # unambiguously a cell reference
> matrix[3]  # ambiguous, forbidden
> matrix[3, axis='row']  # unambiguously a row
> matrix[3, axis='col']  # unambiguously a column
>

Have you considered using matrix[row=3], matrix[col=3]? In that case it
would be a keyword only access. What advantages do you see with your
current API?

Or alternatively, using numpy's current syntax matrix[3, :], matrix[:, 3]
(maybe `...` could be another option, if `:` is too magic)

>
> These could be supported for all of get, set and delete (except for
> cells) operations. A quick sketch of the implementation with minimal
> error checking for brevity:
>
>
> def __setitem__(self, index, value, *, axis=None):
> if isinstance(index, tuple):
> # Operate on a cell.
> if axis is not None:
> raise TypeError('cell ops don't take axis keyword')
> i, j = index
> ... # bind a single cell
>
> elif isinstance(index, int):
> if axis == 'row':
> ... # bind the row
> elif axis == 'col':
> ... # bind the column
> else:
> raise ValueError('bad axis')
>
> else:
> raise TypeError
>
>
> --
> 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/CGMHA4LIE6EIFJWLQ5SEMLQWPKRCIY2V/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/SZ3TEMFWHPFYGYS4LGQ36H6WFR7Z4ZEM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

[Sebastian Kreft]

On Tue, Sep 29, 2020 at 7:27 PM David Mertz  wrote:

> On Tue, Sep 29, 2020 at 12:09 PM Sebastian Kreft  wrote:
>
>> On Tue, Sep 29, 2020 at 6:56 PM David Mertz  wrote:
>>
>>> I still think it would improve the PEP significantly if it added one
>>> case of mixed positional/keyword indexing.  Lots of suggestions have
>>> floated by, and I don't care which one is used, but something to
>>> demonstrate that within the PEP.
>>>
>> I agree, that use case should ideally be one that could have get, set and
>> delete semantics. As most of the examples provided seem to only be meant
>> for accessing the data.
>>
>
> Both the units and source examples I gave would be very natural with set
> and del semantics; enough that I just assumed those were understood.
> Probably units moreso.
>
> internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]]  # Stores
> [[157.48, ...], [..., ...]] in block
>

You mean that internally_inches means the stored values are in inches, and
that by specifying a unit, you will scale up all the passed values?

So that, internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]]
would save in the (4:6, 8:10) block the value [[157.48, 78.7402], [39.3701,
118.11]]? Is that right?

When I originally read these examples, I thought the unit modifier would
change the block location. It feels weird to me to have the unit
disassociated from the actual value being stored.

If I understood correctly what's going on, what would the difference
between

del internally_inches[4:6, 8:10, unit="meters"] and
del internally_inches[4:6, 8:10, unit="inches"]



> internally_cm[4:6, 8:10, unit="metres"] = [[4, 2], [1, 3]]   # apparently
> allow two spellings
>
> del internally_inches[1, unit="furlong"]   # Delete one row, unit ignored
>

>
-- 
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
>


-- 
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/OEXEE5H2OO5QSP3VQWZANVZFILR2RLKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

[Sebastian Kreft]

On Tue, Sep 29, 2020 at 6:56 PM David Mertz  wrote:

> I still think it would improve the PEP significantly if it added one case
> of mixed positional/keyword indexing.  Lots of suggestions have floated by,
> and I don't care which one is used, but something to demonstrate that
> within the PEP.
>
I agree, that use case should ideally be one that could have get, set and
delete semantics. As most of the examples provided seem to only be meant
for accessing the data.


>
> On Tue, Sep 29, 2020 at 11:43 AM Guido van Rossum 
> wrote:
>
>>  At this point I think we're all set for use cases, both for keyword-only
>> and for mixed use. Clearly a lot of libraries are going to be able to
>> provide better APIs using this PEP, and mixed use of positionals and
>> keywords will be quite useful to some of these.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>> ___
>> 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/7KTEXJX5BCXQTJDFIN4N3VIFF4OY3WYO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/2FDXU6H2VNYBKBEN3DCRADY2DFBEBZG7/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/5CA2X4BSRVEHUXEDJ4AYYW7F7TNOWPCB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

[Sebastian Kreft]

On Sun, Sep 27, 2020 at 12:43 AM Steven D'Aprano 
wrote:

> On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:
>
> > In this fashion have you considering having keyword only indices, that is
> > to only allow either obj[1, 2] or obj[row=1, col=2] (if the class
> supports
> > it), and disallow mixing positional and keyword indices, meaning obj[1,
> > col=2] would be a SyntaxError.
>
> That would severely reduce the usefulness of this feature for me,
> probably by 80 or 90%, and possibly make it useless for xarray and
> pandas.
>
> (I don't speak for the pandas or xarray devs, I'm happy to be
> corrected.)
>
> But for my own code, my primary use-case is to have a mixed positional
> index and keyword arguments. I would *much* rather give up keyword-only
> subscripting. Keyword-only subscripting would be a convenience and a
> useful feature, but it's mixed subscripting that I am really hungry for.
>

Hi Steven, could you share some examples of what you have in mind. Having a
more concrete example of an API that would benefit from mixed-subscripting
would allow us to better understand its usefulness.

I'm uneasy with the abuse-of-notation potential of this proposed feature,
especially around the use of **kwd and mixed subscripting. That being said,
I do understand why it may be appealing to others, as that could open the
door for a more expressive language and maybe even better suited for some
DSLs.



>
> Hmmm, that's a thought... maybe we should just prohibit keyword-only
> calls for now? People who want a "keyword only" call can provide their
> own "do nothing" sentinel as the index.
>
> For my own purposes, I could easily adapt the keyword-only cases to use
> None as an explicit sentinal:
>
> matrix[row=1]  # Nice to have.
> matrix[None, row=1]  # Good enough for my purposes.
>
> so for my own purposes, if keyword-only is too hard, I'd be happy to
> drop it out of the PEP and require an explicit index.
>
>
> > If we followed that path, then adding a new set of dunders may not be
> that
> > problematic as the use case would be slightly different than the current
> > semantics.
>
> I don't see how "the use case is different" solves the problems with
> adding new dunders.
>
> Adding new dunders is problematic because:
>
> * they probably require new C level slots in objects, increasing
>   their size;
>
> * and the added complexity and likelihood of confusion for
>   developers. Do I write `__getitem__` or `__getindex__`?
>
> We had this back in Python 1 and 2 days with `__*item__` and
> `__*slice__` dunders and moved away from that, let's not revert back to
> that design if we can avoid it.
>
>
> > I also agree with Stefano that something like a[1, 2, unit="meters"]
> feels
> > really odd,
>
> Could be because of the misspelling of metres (unit of measurement)
> versus meters (things you read data from) *wink*
>
> Without knowing what the object `a` represents, or what the meaning of
> the subscript is, how can we possibly judge whether this is a reasonable
> use of a keyword subscript or not?
>
>
>
> Stefano wrote:
>
> > > a[1, 2, unit="meters"]
> > >
> > > makes me feel uncomfortable, although I might learn to accept it. In
> > > particular, the above case becomes kind of odd when you use it for
> > > setitem and delitem
> > >
> > > a[1, 2, unit="meters"] = 3
> > >
> > > what does this mean? convert 3 to meters and store the value in a?
>
> You made the example up, so you should know what it means :-)
>
> I don't even know what `a[1, 2, unit="meters"]` means since we don't
> know what `a` is.
>
>
> > > Then why isn't the unit close to 3, as in
> > >
> > > a[1,2] = 3 * meters
> > >
> > > and what about this one?
> > >
> > > del a[1, 2, unit="meters"] # and this one?
>
> In my own use-case, all three get/set/delete operations will support the
> same keywords, but just because we syntactically allow subscripts
> doesn't make it mandatory to use them identically useful for all three
> opperations in all cases. There is no need for the dunder to support a
> keyword that makes no sense for that dunder.
>
> For example, suppose we had a sequence-like mapping that supports this
> get operation:
>
> table[index, default="index out of range"]
>
> That doesn't mean that table has to support the same keyword
> when setting or deleting, it can use different keywords that make no
> sense when getting:
>
> table = Table([1, 2, 3, 4])
> table[10, f

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

[Sebastian Kreft]

On Sat, Sep 26, 2020 at 7:51 AM Stefano Borini 
wrote:

> On Sat, 26 Sep 2020 at 04:02, Steven D'Aprano  wrote:
>
> > Did you just completely undermine the rationale for your own PEP?
> >
> > Isn't the entire purpose of this PEP to allow subscripts to include
> > keyword arguments? And now you are describing it as "poor design"?
>
> Not really. to _me_, an indexing operation remains an indexing
> operation. My personal use cases are two:
>
> 1. naming axes (e.g. replace, if desired obj[1, 2] with obj[row=1, col=2])
> 2. typing generics MyType[T=int]
>

In this fashion have you considering having keyword only indices, that is
to only allow either obj[1, 2] or obj[row=1, col=2] (if the class supports
it), and disallow mixing positional and keyword indices, meaning obj[1,
col=2] would be a SyntaxError.

If we followed that path, then adding a new set of dunders may not be that
problematic as the use case would be slightly different than the current
semantics.

One could implement the current set of dunders __[get|set|del]item__ in
case you want to support keywordless indexing, and this hypothetical new
set of dunders if you wanted to support keyword indices. If you want both
you need to implement both. However, a decorator may be added to easily
allow both semantics.

Has anyone provided compelling use cases for mixing indices with
and without keywords?

I also agree with Stefano that something like a[1, 2, unit="meters"] feels
really odd, but maybe by adding the names to the first 2 dimensions
the intent could be clearer.


> Other use cases are certainly allowed, but to me, something like
>
> a[1, 2, unit="meters"]
>
> makes me feel uncomfortable, although I might learn to accept it. In
> particular, the above case becomes kind of odd when you use it for
> setitem and delitem
>
> a[1, 2, unit="meters"] = 3
>
> what does this mean? convert 3 to meters and store the value in a?
> Then why isn't the unit close to 3, as in
>
> a[1,2] = 3 * meters
>
> and what about this one?
>
> del a[1, 2, unit="meters"] # and this one?
>
> I feel that, for some of those use cases (like the source one),
> there's a well established, traditional design pattern that fits it
> "better" (as it, it feels "right", "more familiar")
>
> > I'm not really sure why this hypothetical call:
> >
> > snapshot1 = remote_array[300:310, 50:60, 30:35, source=worker1]
> >
> > is "abuse" or should make us more uneasy that this hypothetical call:
>
> I don't know... it just doesn't feel... "right" :) but maybe there's a
> logic to it.
> You are indexing on the indexes, and also on the source.
>
> Yeah, makes sense.
>
> Sold.
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/IUGWBNNFF275HVRNDRJ2RWR53ZJYMPBN/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/J7TL7UEMRQB5LNZTGGX4MUTW2Z66GLPI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

[Sebastian Kreft]

On Sun, Aug 23, 2020 at 9:42 PM Todd  wrote:

> I think it is worth directly discussing the availability of slices in PEP
> 472-style keyword indices, since we seem to have mostly converged on a
> dunder method signature.  This is an issue that has been alluded to
> regarding keyword-based (labelled) indices but not directly addressed.  The
> basic syntax would be something like d[x=1:3].
>

As I mentioned in another thread, I think the syntax in which the initial
argument of the slice is missing may be visually confusing, as it is too
similar to the walrus operator.

d[x=:3] or d[x=:]

There's precedent for combinations of symbols that have different meanings
when swapped. For example:

x += 3 vs x =+ 3

However, the second case will be usually formatted as x = +3, as per PEP 8
<https://www.python.org/dev/peps/pep-0008/#other-recommendations>

So unless PEP8 is updated to require/suggest spaces around a keyword index
(which I'm not proposing), then I am -1 for the suggested feature, at least
when the initial element is missing.


>
> I am strongly in favor of having slices.  The main motivating factor for
> me, labelled dimensions in xarray, would be much, much less useful without
> support for slices.  In fact, as PEP 472 currently mentions, the big
> benefit of indexing over method calls is that indexing supports slice
> syntax while method calls don't.
>
> In a more general sense, I feel not allowing slices would create an
> artificial distinction between labelled and positional indices that I don't
> think is justified.  They would work the same, except for slices where
> labelled indices behave differently.  It would be a strange gotcha.
>
> So I think any revision to PEP 472 or new PEP should directly and
> explicitly support the use of slices.
> ___
> 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/TOABKD7A5X653BTTU3MZICWURNGPMY47/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/IQJNOQS2LKHWSSYAJX7KDNWJ5ZFZ25N4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Sebastian Kreft]

On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine  wrote:

> Todd wrote:
>
> It has the same capabilities, the question is whether it has any
>> additional abilities that would justify the added complexity.
>>
>
> The most obvious additional ability is that always
> >>> d[SOME_EXPRESSION]
> is equivalent to
> >>> d[key]
> for a suitable key.
>
> This is a capability that we already have, which would sometimes be lost
> under the scheme you support.  Also lost would be the equivalence between
>>>> val = d[key]
>>>> getter = operator.itemgetter(key)
>>>> val = getter(d)
>
> More exactly, sometimes it wouldn't be possible to find and use a key.
> Docs would have to be changed.
> See: https://docs.python.org/3/library/operator.html#operator.itemgetter
>
> As I understand it, xarray uses dimension names to slice data.  Here's an
> example from
>
> http://xarray.pydata.org/en/stable/indexing.html#indexing-with-dimension-names
> >>> da[dict(space=0, time=slice(None, 2))]
>
> Presumably, this would be replaced by something like
> >>> da[space=0, time=:2]
>
Was the slicing notation already explicitly proposed for kwargs? I find it
too similar to the walrus operator when the first argument is missing.

I could only find an example in this section
https://www.python.org/dev/peps/pep-0472/#use-cases, but the first argument
is defined.

rain[time=0:12, location=location]


> Now, the commands
>>>> da[space=0, time=:2]
>>>>  da[space=0, time=:2] = True
>>>> del da[space=0, time=:2]
> would at the begging of the call, presumably, do the same processing on
> the keyword arguments. (Let this stand for a wide range of examples.)
>
> It is arguable that making it easier for the implementer of type(da) to do
> all that processing in the same place would be a REDUCTION of complexity.
> Allowing the processing to produce an intermediate object, say
> >>> key = dict(space=0, time=slice(None, 2))
>  would help here.
>
> Real world examples are required, I think, to ground any discussions of
> complexity and simplicity. We want to optimise for what people do, for the
> problems they face. And this is a new feature.
>
> We have a perfectly good way of handling keywords, so it is up to you to
>> explain why we shouldn't use it.
>>
>
> The scheme you support does not distinguish
> >>> d[1, 2, x=3, y=4]
> >>> d[(1, 2), x=3, y=4]
> I don't regard that as being perfectly good.
>
> In addition, I would like
> >>> d = dict()
> >>> d[x=1, y=2] = 5
> to work. It works out-of-the-box for my scheme. It can be made to work
> with a subclass of dict for the D'Aprano scheme.
>
> I think that is enough for now.
>
> I'd prefer to discuss this further by writing Python modules that contain
> code that can be tested. The testing should cover both the technical
> correctness and the user experience. To support this I intend not to focus
> on the next version of kwkey.
> https://pypi.org/project/kwkey/
>
> --
> Jonathan
> ___
> 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/3XRS7WVSFJAZJ6TODL62KZYEDRUV3CRI/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/766LV6UK6NJBXBS43K52HGIGBUE5W5I3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Function suggestion: itertools.one()

[Sebastian Kreft]

 else.
>>> 3. The one() function allows you to use the result inside an expression
>>> without assigning it to a variable. Therefore, I think it encourages
>>> writing better code. It's very easy to write:
>>> print([p for p in people if p.id == '1234][0])
>>> (which has the problem of not verifying the assumption that there's no
>>> more than one result), and I find it easier to replace _[0] with one(_)
>>> than to be required to name a new variable, and instead of having an
>>> operation on the iterable, change the way I'm assigning to it.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> Noam
>>>
>>>
>>> ___
>>> 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/6OLEL4XTUWXRI7ENODKEDOYFBRVDYKI7/
>>> 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/RKRPD5DXG3GOXHGVJFTAURFY3XROQHBK/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/WIGGAB57L75RFCFY6XF5BNJOHXD2F3YB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

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-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/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 
https://mail.python.org/archives/list/python-ideas@python.org/message/4OYYVFNFOWY6ONW5YQAPF7R7QDS55YSL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: AVG Function as Built-in

[Sebastian Kreft]

Just use `from statistics import mean as avg` (see
https://docs.python.org/3/library/statistics.html#statistics.mean).

Please provide some justification on why do you think it's desirable to
make `avg` a builtin, considering, that doing so is a backwards
incompatible change due to the more than likely name clash.

On Thu, Dec 26, 2019 at 10:52 AM Kemal Diri  wrote:

> Hello,
>
> I think it would be nice to introduce an avg method for lists as a
> built-in function in python3.
> To get average of the list, I need to use some libs (eg numpy).
> In my opinion, if I can get *sum* of the list, I should get *avg *also in
> a same way.
>
> For ex [python3]:
>
> >>> l = [5, 9, 7,]
> ...
> ... import numpy as np
> ... print(np.mean(l))
> 7.0
> >>> sum(l) / len(l)
> 7.0
> >>> avg(l)
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'avg' is not defined
>
> Cordialement/Regards
> Kemal DIRI
>
>
>
>
> ___
> 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/NQB6VU6QSC253JT2SWUO3IWCZ3IG36XP/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/3P4SXG4VFWDZBBGBQMNEA6BVVVAVE7T7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()

[Sebastian Kreft]

To overcome Github's search limitations, one can use Chrome's codesearch or
the public github dataset available on bigquery (note: it's only a sample
from 2012 if I'm not mistaken).

https://cs.chromium.org/search/?q=lang:py+re%5C.findall%5C(.*%5C)%5C%5B0%5C%5D=package:chromium=cs
returns
5 results

while the following query:

SELECT COUNT(*) FROM (SELECT
  c.id id,
  c.content content,
  f.repo_name repo_name,
  f.path path
FROM
  `bigquery-public-data.github_repos.sample_files` f
JOIN (
  SELECT
*
  FROM
`bigquery-public-data.github_repos.sample_contents`
 ) c
ON
  f.id = c.id
WHERE
  ENDS_WITH(f.path, ".py") AND
  REGEXP_CONTAINS(c.content, "re\\.findall\\(.*\\)\\[0\\]")
)

returns 84 entries.

On Thu, Dec 5, 2019 at 6:51 PM Kyle Stanley  wrote:

>
> Serhiy Storchaka wrote:
> > We still do not know a use case for findfirst. If the OP would show his
> > code and several examples in others code this could be an argument for
> > usefulness of this feature.
>
> I'm not sure about the OP's exact use case, but using GitHub's code search
> for .py files that match with "first re.findall" shows a decent amount of
> code that uses the format ``re.findall()[0]``. It would be nice if GitHub's
> search properly supported symbols and regular expressions, but this
> presents a decent number of examples. See
> https://github.com/search?l=Python=first+re.findall=Code.
>
> I also spent some time looking for a few specific examples, since there
> were a number of false positives in the above results. Note that I didn't
> look much into the actual purpose of the code or judge it based on quality,
> I was just looking for anything that seemed remotely practical and
> contained something along the lines of ``re.findall()[0]``. Several of the
> links below contain multiple lines where findfirst would likely be a better
> alternative, but I only included one permalink per code file.
>
>
> https://github.com/MohamedAl-Hussein/my_projects/blob/15feca5254fe1b2936d39369365867496ce5b2aa/fifa_workspace/fifa_market_analysis/fifa_market_analysis/items.py#L325
>
> https://github.com/MohamedAl-Hussein/FIFA/blob/2b1390fe46f94648e5b0bcfd28bc67a3bc43f09d/fifa_data/fifa_data/items.py#L370
>
> https://github.com/democracyworks/dog-catcher/blob/9f6200084d4505091399d36ab0d5e3379b04588c/new_jersey.py#L82
>
> https://github.com/democracyworks/dog-catcher/blob/9f6200084d4505091399d36ab0d5e3379b04588c/connecticut.py#L182
>
> https://github.com/jessyL6/CQUPTHUB-spiders_task1/blob/db73c47c0703ed01eb2a6034c37edd9e18abb2e0/ZhongBiao2/spiders/zhongbiao2.py#L176
>
> https://github.com/kerinin/giscrape/blob/d398206ed4a7e48e1ef6afbf37b4f98784cf2442/giscrape/spiders/people_search.py#L26
>
> https://github.com/songweifun/parsebook/blob/529a86739208e9dc07abbb31363462e2921f00a0/dao/parseMarc.py#L211
>
> I'm sure there are far more examples and perhaps some more "realistic"
> ones, I only went through the first few pages of results.
>
> On Thu, Dec 5, 2019 at 3:08 PM Serhiy Storchaka 
> wrote:
>
>> 05.12.19 21:07, Guido van Rossum пише:
>> > The case for findfirst() becomes stronger! There seem plenty of ways to
>> > get this wrong.
>>
>> I write several functions every day. There are many ways to get this
>> wrong. But I do not propose to include all these functions in the
>> stdlib. If I want to include even a single function, I try to find
>> several examples that would benefit from adding this function in the
>> stdlib. If I found less examples than I expected I withdraw my idea.
>>
>> We still do not know a use case for findfirst. If the OP would show his
>> code and several examples in others code this could be an argument for
>> usefulness of this feature.
>> ___
>> 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/YKVXRQAST6B7CRNN7LFBZXWVHH6G42YC/
>> 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/7P4ZZMIL2ZFJOONUSZPNUBOZTAAEMASY/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/3Y4FHNORMERUZCXJS7XX2ZE4O4KIJCKN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

What Eric Fahlgren wants is basically the deprecated contextlib.nested
function, that function should have the right semantics. See
https://github.com/python/cpython/blob/2.7/Lib/contextlib.py#L88-L129

On Wed, Nov 13, 2019 at 6:55 PM Chris Angelico  wrote:

> On Thu, Nov 14, 2019 at 8:48 AM Eric Fahlgren 
> wrote:
> > I have used 'with' for so long that I was under the impression that the
> as-target was just a name as in MRAB's simplified syntax above, so imagine
> my surprise when I tried putting parentheses around the target and didn't
> get a syntax error straight away.  I of course had to explore a bit, and
> came up with this.  The ugly formatting of the with is simply to show that
> the parens behave as expected.
> > class opener:
> > def __init__(self, *files):
> > self.files = [open(file) for file in files]
> > def __enter__(self):
> > return [file.__enter__() for file in self.files]
> > def __exit__(self, *exc_info):
> > for file in self.files:
> > file.__exit__(*exc_info)
> > return True
> >
> > with opener(
> > 'x', 'y', 'z'
> > ) as (
> > f1,  f2,  f3
> > ):
> > print(f1)
> > print(f1.closed)
> > print(f2)
> > print(f3)
> >
> > print(f1.closed)
>
> Note that the semantics here are NOT the same as the semantics of
> either ExitStack or a single large 'with' statement. (And I'm not sure
> whether or not those two are the same.) With your opener, you first
> open each file, then enter each file; and only then are you considered
> to be inside the context. With a large 'with' statement, they should
> (I believe) be opened and entered individually. If one of the files
> fails to open, your constructor will fail, and self.files won't be set
> - you won't exit each of the files that you *did* open.
>
> 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/RT3RFVV7KRZ2Z6G2CI3GLHCFLTDUS6DG/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZOUTPHHTNZ2EEZZNNSMVHGIP5CSYLVXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

On Wed, Oct 23, 2019 at 1:19 PM Christopher Barker 
wrote:

> On Wed, Oct 23, 2019 at 5:42 AM Rhodri James  wrote:
>
>> > I'm surprised by that description. I don't think it is just newcomers
>> > who either suggest or prefer plus over pipe, and I don't think that pipe
>> > is "more accurate".
>>
>> +1 (as one of the non-newcomers who prefers plus)
>>
>
> me too.
>
> frankly, the | is obscure to most of us. And it started as "bitwise or",
> and evokes the __or__ magic method -- so why are we all convinced that
> somehow it's inextricably linked to "set union"? And set union is a bit
> obscure as well -- I don't think that many people (newbies or not) would
> jump right to this logic:
>
In my particular case I do know what `|` means in a set context. However,
when I see code using it, it takes me a while to understand what it means
and I tend to replace the operator with an explicit call to the union
method.

The only problem with that is when `dict_keys` are in use, as they do
implement the `|` operator, but not the `union` method. They only have
`isdisjoint`.


>
> I need to put two dicts together
> That's kind of like a set union operation
> The set object uses | for union
> That's probably what dict uses -- I'll give that t try.
>
> Rather than:
>
> I need to put two dicts together
> I wonder if dicts support addition?
> I'll give that a try.
>
> so, I'm
>
> +1 on +
> +0 on |
>
> if | is implemented, I'll bet you dollars to donuts that it will get used
> far less than if + were used.
>
> (though some on this thread would think that's a good thing :-) )
>
> -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
> 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/TE2IFV2PIUADS35TD6BHPEO5KG6DDTNT/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/MV3P7FXG6VBIDB5WEYYPQF3KCSRYPBTV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional dict declarations

[Sebastian Kreft]

How is this different to the discussion
https://mail.python.org/archives/list/python-ideas@python.org/thread/MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27/#MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27
 ?

On Thu, Sep 5, 2019 at 9:24 AM  wrote:

> Okie, looks like my code got munched in the web view -- how do I make
> it not do that?
> ___
> 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/JNUMEIHLYVLC64MOVZ4P7ABMOOY3SJC4/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/6JJWWUBAARDBCMW2BD2DWDMDHXT52S2V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Exceptions with Message Templates

[Sebastian Kreft]

On Fri, Aug 9, 2019 at 12:55 PM Brett Cannon  wrote:

>
>
> On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft  wrote:
>
>>
>>
>> On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
>> python-ideas@python.org> wrote:
>>
>>> On Aug 8, 2019, at 15:01, Ryan Fox  wrote:
>>>
>>> I don't see why you would want to access arguments by their position.
>>>
>>>
>>> Because that’s the way it’s worked since Python 1.x, and there’s tons of
>>> existing code that expects it, including the default __str__ and __repr__
>>> for exceptions and the code that formats tracebacks.
>>>
>> I don't really understand what you mean here. This property was broken
>> since ImportError started accepting keyword arguments.
>>
>
> The property isn't broken for ImportError, it just isn't being given the
> keyword arguments because it didn't makes sense to pass them down with no
> information attached to it. The 'args' attribute still gets the message
> which is the key detail.
>
The "broken" property was alluding to Andrew's comment that exception
arguments need to be positional and cannot/shouldn't be keywords and I was
giving an example from the standard library in which we can pass keyword
arguments which are not stored in the exception's arguments.

Also note that my comment mentioned that passing the formatted message as
the only argument to the super constructor would solve the compatibility
problem.


>
> -Brett
>
>
>>
>> For example:
>>
>> >>> ImportError("message", name="name", path="path").args
>> ('message',)
>>
>> >>> ImportError("message", "foo", name="name", path="path").args
>> ('message', 'foo')
>>
>> For the case of str and repr, one could just call super with the
>> formatted message as the only positional argument.
>>
>>
>> I suggest taking a look at PEP 473
>> <https://www.python.org/dev/peps/pep-0473/> for ideas on why having
>> structured arguments is a good idea.
>>
>>>
>>> The user-defined exceptions in the Python documentation don't pass
>>> arguments to the base class either:
>>> https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions
>>>
>>>
>>> Yes they do. Try it:
>>>
>>> >>> e = InputError('[2+3)', 'mismatched brackets')
>>> >>> e.args
>>> ('[2+3)', 'mismatched brackets')
>>> >>> e
>>> InputError('[2+3)', 'mismatched brackets')
>>>
>>> If you’re wondering why this works, it’s because Error and InputError
>>> don’t override __new__. Which should make it obvious why a tutorial aimed
>>> at novices doesn’t get into the details, but that’s why Python has
>>> reference manuals instead of just a tutorial.
>>>
>>> Also, notice that the tutorial examples don’t even try to create a
>>> formatted message; they expect that the type name and the args will be
>>> enough for debugging. I’m not sure that’s a great design, but it means that
>>> your intended fix only solves a problem they didn’t even have in the first
>>> place.
>>>
>>> So let's go ahead and assume my implementation is flawed. The fact that
>>> people prefer to copy their format strings all over their projects implies
>>> that the current exception scheme is suboptimal. Can we agree on that? If
>>> not, there's no need to continue this discussion.
>>>
>>>
>>> I agree that it would be nice for more people to move their message
>>> formatting into the class, but you need a design that encourages that
>>> without fighting against the fact that exception args are positional, and
>>> I’m not sure what that looks like. And I don’t think it’s your
>>> implementation that’s bad (it seems to do what it says perfectly well), but
>>> that the design doesn’t work.
>>>
>>> Of course if you were designing a new language (or a new library from
>>> builtins up for the same language), this would be easy. Exceptions would
>>> look like (maybe be) @dataclasses, storing their arguments by name and
>>> generating repr/str/traceback that takes that into account, and all of them
>>> would actually store the relevant values instead of half of them making you
>>> parse it out of the first arg, and there would be a special message
>>> property or method instead of args[0] being sort of special but not special
>>> enough, and so o

[Python-ideas] Re: Exceptions with Message Templates

[Sebastian Kreft]

On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> On Aug 8, 2019, at 15:01, Ryan Fox  wrote:
>
> I don't see why you would want to access arguments by their position.
>
>
> Because that’s the way it’s worked since Python 1.x, and there’s tons of
> existing code that expects it, including the default __str__ and __repr__
> for exceptions and the code that formats tracebacks.
>
I don't really understand what you mean here. This property was broken
since ImportError started accepting keyword arguments.

For example:

>>> ImportError("message", name="name", path="path").args
('message',)

>>> ImportError("message", "foo", name="name", path="path").args
('message', 'foo')

For the case of str and repr, one could just call super with the formatted
message as the only positional argument.


I suggest taking a look at PEP 473
<https://www.python.org/dev/peps/pep-0473/> for ideas on why having
structured arguments is a good idea.

>
> The user-defined exceptions in the Python documentation don't pass
> arguments to the base class either:
> https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions
>
>
> Yes they do. Try it:
>
> >>> e = InputError('[2+3)', 'mismatched brackets')
> >>> e.args
> ('[2+3)', 'mismatched brackets')
> >>> e
> InputError('[2+3)', 'mismatched brackets')
>
> If you’re wondering why this works, it’s because Error and InputError
> don’t override __new__. Which should make it obvious why a tutorial aimed
> at novices doesn’t get into the details, but that’s why Python has
> reference manuals instead of just a tutorial.
>
> Also, notice that the tutorial examples don’t even try to create a
> formatted message; they expect that the type name and the args will be
> enough for debugging. I’m not sure that’s a great design, but it means that
> your intended fix only solves a problem they didn’t even have in the first
> place.
>
> So let's go ahead and assume my implementation is flawed. The fact that
> people prefer to copy their format strings all over their projects implies
> that the current exception scheme is suboptimal. Can we agree on that? If
> not, there's no need to continue this discussion.
>
>
> I agree that it would be nice for more people to move their message
> formatting into the class, but you need a design that encourages that
> without fighting against the fact that exception args are positional, and
> I’m not sure what that looks like. And I don’t think it’s your
> implementation that’s bad (it seems to do what it says perfectly well), but
> that the design doesn’t work.
>
> Of course if you were designing a new language (or a new library from
> builtins up for the same language), this would be easy. Exceptions would
> look like (maybe be) @dataclasses, storing their arguments by name and
> generating repr/str/traceback that takes that into account, and all of them
> would actually store the relevant values instead of half of them making you
> parse it out of the first arg, and there would be a special message
> property or method instead of args[0] being sort of special but not special
> enough, and so on. And then, providing an easier way to create that message
> property would be an easy problem. But I think with the way Python is
> today, it’s not.
>
> Of course I’d be happy to be proven wrong on that.  :)
> ___
> 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/5ULPVNH6RBFXY24P76YZCAKIKOLHWF2B/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZOLTXVQPUFWFJXO66JT7JEP2BMLVC5OF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

rvation. How do I convince you that complex input validation
> tasks should be left to a parser?
>
> 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/FCPU4ZW43G3G6JZHJTD33MT7SYI3DBQY/
> 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 
https://mail.python.org/archives/list/python-ideas@python.org/message/6G5NSRL63GW2SOWONWHENLC6JTQN3YJR/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntax to conditionally define a field in a dict

[Sebastian Kreft]

On Fri, Apr 26, 2019 at 11:07 AM Joshua Marshall 
wrote:

> Hello all,
>
> I have a use case where I need to send a `dict` to a module as an
> argument.  Inside of this, it has a multi-level structure, but each field I
> need to set may only be set to a single value.  Fields must be valid,
> non-empty strings.  It looks a lot like the following in my code:
>
> ```
> def my_func(val_1, val_2):
> return {
> "field_1": val_1,
> "next_depth": {
> "field_2": val_2
> }
> }
> ```
>
> What I want to do is:
> ```
> def my_func(val_1, val_2):
> return {
> "field_1": val_1 if val_1,
> "next_depth": {
> "field_2": val_2 if val_2
> }
> }
> ```
>
If val_2 here evaluates to falsey, will next_depth still be defined? From
the code I would say that no. But your use case may require to not define
the next_depth subdict without any values, as that may break the receiver
expectations (think of JSON Schema).


>
> Or:
> ```
> def my_func(val_1, val_2):
> return {
> if val_1 : "field_1": val_1,
> "next_depth": {
> if val_2: "field_2": val_2
> }
> }
> ```
>
> Where each conditional in this context functions as:
> ```
> if value:
> d["your_key"] = value
> ```
> for each conditionally added and set key.
>
> From the slack channel #learning_python, there are a number of more
> general points which need to be handled.  The more core syntax, which
> should be valid throughout the language, would be to have statements like
> `x = y if cond` and `x[y if cond]`.  The first of these intuitively
> reorganizes to `if cond: x = y`, but the second is not as clear, with a
> likely equivalent of `if cond: x[y] else raise Exception`.
>
> Thanks to Tom Forbes and Jim Kelly for helping critique the idea thus far.
>
>
> Please be advised that this email may contain confidential information.
> If you are not the intended recipient, please notify us by email by
> replying to the sender and delete this message. The sender disclaims that
> the content of this email constitutes an offer to enter into, or the
> acceptance of, any agreement; provided that the foregoing does not
> invalidate the binding effect of any digital or other electronic
> reproduction of a manual signature that is included in any attachment.
>
> <https://twitter.com/arroyo_networks>
> <https://www.linkedin.com/company/arroyo-networks>
> <https://www.github.com/ArroyoNetworks>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Sebastian Kreft
___
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] Powerset

[Sebastian Kreft]

Hi Hassan,
I think this is unlikely to get added to the standard library as it is
listed as a recipe in the itertools module (
https://docs.python.org/3/library/itertools.html#itertools-recipes).

You may want to check out the more-itertools package (
https://more-itertools.readthedocs.io/en/latest/) which includes all the
recipes listed, as well as some other functions.

On Mon, Oct 15, 2018 at 8:16 PM Hasan Diwan  wrote:

> [if this isn't the correct spot, let me know and I'll gladly take it
> elsewhere]
> I have found myself needing powerset functionality several times
> recently to the point where I wondered if there's interest in making
> it part of the standard library. I have a working implementation and
> tests. Would take but 3 minutes to add it in and issue a pull request,
> but I'd like to know if there's interest from esteemed group members.
> Thanks for the quick turnaround. -- H
>
> --
> OpenPGP:
> https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1
> If you wish to request my time, please do so using
> bit.ly/hd1AppointmentRequest.
> Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.
>
> Sent from my mobile device
> Envoye de mon portable
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

Re: [Python-ideas] datetime.timedelta literals

[Sebastian Kreft]

Please read the discussions on
*https://mail.python.org/pipermail//python-ideas/2016-August/041890.html
<https://mail.python.org/pipermail//python-ideas/2016-August/041890.html>*,
https://mail.python.org/pipermail//python-ideas/2016-August/041939.html,
https://mail.python.org/pipermail//python-ideas/2016-August/042028.html,
https://mail.python.org/pipermail//python-ideas/2016-August/041899.html

They are more general than your proposal but they still cover pitfalls that
may affect yours. It would be better if you could expand your proposal to
the concerns raised on those threads.

On Sun, Jun 3, 2018 at 12:53 PM, Pål Grønås Drange 
wrote:

> > What about
> >
> > 2.5*h - 14*min + 9300*ms * 2
>
> That doesn't seem feasible to implement, however, that is essentially how
> the
> Pint [1] module works:
>
> import pint
> u = pint.UnitRegistry()
> (2.5*u.hour - 14*u.min + 9300*u.ms) * 2
> #  
>
> ((2.5*u.hour - 14*u.min + 9300*u.ms) * 2).to('sec')
> #  
>
> > However why be limited to time units ? One would want in certain
> > application to define other units, like meter ? Would we want a litteral
> > for that ?
>
> Pint works with all units imaginable:
>
> Q = u.Quantity
> Q(u.c, (u.m/u.s)).to('km / hour')
> #  
>
>
> However, the idea was just the six (h|min|s|ms|us|ns) time literals; I
> believe
> time units are used more often than other units, e.g. in constructs like
>
> while end - start < 1min:
>poll()
>sleep(1s)  # TypeError
>sleep(1s.total_seconds())  # works, but ugly
>
>
> [1] https://pypi.org/project/Pint/
>
> Best regards,
> Pål Grønås Drange
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Sebastian Kreft
___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[Sebastian Kreft]

This has been brought up multiple times. Last time was on this thread
https://mail.python.org/pipermail/python-ideas/2016-October/043024.html.

On Tue, Nov 21, 2017 at 3:13 AM, bunslow <buns...@gmail.com> wrote:

> Nothing so bombastic this time. The heapq functions are basically all
> named "heapsomething", and basically all take a "heap" for their first
> argument, with supplementary args coming after. It's a textbook example of
> the (hypothetical) Object Oriented Manifesto™ where defining a class
> increases type safety and programmers' conceptual clarity. There're
> practically no drawbacks, and the code to be added would be very simple.
> Updating the tests and docs would probably be harder.
>
> In pure Python, such a class would look like this:
>
> class Heap(list):
>
> def __init__(self, iterable=None):
> if iterable:
> super().__init__(iterable)
> else:
> super().__init__()
>
> self.heapify()
>
> push = heapq.heappush
> pop = heapq.heappop
> pushpop = heapq.heappushpop
> replace = heapq.heapreplace
> heapify = heapq.heapify
>
> # This could be a simple wrapper as well, but I had the following
> thoughts anyways, so here they are
> def nsmallest(self, n, key=None):
> # heapq.nsmallest makes a *max* heap of the first n elements,
> # while we know that self is already a min heap, so we can
> # make the max heap construction faster
> self[:n] = reversed(self[:n])
> return heapq.nsmallest(n, self, key)
>
> # do we define nlargest on a minheap??
>
>
> Wrapping around the C builtin functions (which aren't descriptors) would
> be a bit harder, but not much so:
>
> from functools import partial
>
> class Heap(list):
> def __init__(self, iterable=None):
> if iterable:
> super().__init__(iterable)
> else:
> super().__init__()
>
> self.heapify = partial(heapq.heapify, self)
> self.push = partial(heapq.heappush, self)
> ...
>
> self.heapify()
>
>
> Thoughts?
>
> _______
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Sebastian Kreft
___
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] Decorator to avoid a mistake

[Sebastian Kreft]

Related thread
https://mail.python.org/pipermail/python-ideas/2016-July/041095.html

On Nov 23, 2016 20:30, "François Leblanc"  wrote:

>
> I can imagine using a metaclass specialized witch can be activate or
> desactivate but the cost of decorator
> call still be here...
>
> I think its will be a good improvement if we can provide a solution for
> this, and i ask myself if this can be set
>
> in interpreter with a flag to activate for exemple and with no performance
> cost without the flag set, so you
>
> will have the choice and a good way to check youre code.
>
> To have no performance cost perhaps the best way it's to use docstring and
> pylint...
>
>
>
> 2016-11-23 10:10 GMT+01:00 Paul Moore :
>
>> On 23 November 2016 at 08:08, François Leblanc 
>> wrote:
>> > It's why I'd prefer this integrate in language, but if there no way to
>> get
>> > it without performance cost
>> > I will have a look to a pylint solution...
>>
>> The point here is that if there is a way to get it without a
>> performance cost (I can't imagine there would be, it's got to add a
>> check for whether you're overriding a method at a minimum, but you may
>> be able to come up with something) then you can do that within the
>> language as it stands. It may need a specialised metaclass, but that's
>> not a problem. At least, if it *is* an issue to you, you can argue for
>> having it be the behaviour of the default metaclass once you've
>> demonstrated that it works and doesn't hurt performance. And if there
>> is a performance hit, then having the behaviour as opt-in based on a
>> custom metaclass means that people can choose if they want to pay that
>> cost.
>>
>> 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/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/