[Python-ideas] Re: Pickle security improvements

On 12/07/20 1:01 pm, Edwin Zimmerman wrote: As I see it, the unsafe callables (eval, exec, os.system, etc) are generally functions, and safe ones(int, list, dict) are generally classes, though there certainly would be exceptions. Where security is concerned, "there certainly would be exceptio

[Python-ideas] Re: Faster object representation for UIs

On 26/07/20 1:34 am, Elizabeth Shashkova wrote: 1. We need this lazy `__repr__` calculation inside our debugger, where we work with different user's objects. Usually it isn't some specific type, for which you know that it'll be big and its `__repr__` calculation will be slow Seems to me it wo

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

How about we just document the whole feature as deprecated and never speak of it again? -- Greg ___ 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] Re: Access (ordered) dict by index; insert slice

On 31/07/20 4:04 am, Christopher Barker wrote: (Side note: why ARE the views provided by methods, rather than properties? Probably because they construct objects, and are therefore somewhat more expensive than is usually expected for an attribute access. -- Greg ___

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

On 4/08/20 9:20 am, Todd wrote: Another approach could be too simply pass the labelled indices in a dict as a third/fourth positional argument. Has anyone suggested attaching the keyword args as attributes on the slice object? This would avoid changing the signature of __getitem__, and existin

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

On 4/08/20 6:35 pm, Greg Ewing wrote: Has anyone suggested attaching the keyword args as attributes on the slice object? Realised after sending that this idea is rubbish, because there can be more than one slice object. -- Greg ___ Python-ideas

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

On 4/08/20 1:16 pm, Steven D'Aprano wrote: Why would we want to even consider a new approach to handling keyword arguments which applies only to three dunder methods, `__getitem__`, `__setitem__` and `__delitem__`, instead of handling keyword arguments in the same way that every other method hand

[Python-ideas] Re: Decorators for class non function properties

On 5/08/20 9:13 pm, Serhiy Storchaka wrote: the code can be written as class Neuron: activation = linear_activation(activation) I do not see reasons to introduce special syntax for this very specific code. A considerable number of moons ago, I suggested that @my_property

[Python-ideas] Re: Decorators for class non function properties

On 6/08/20 1:35 am, Marco Sulla wrote: I suppose that what Greg Ewing suggests is a way to define a sort of custom simple statement. you could write @print "Hello" My suggestion was only for decorating assignments to a bare name, so that wouldn't have been legal. But that

[Python-ideas] Re: Decorators for class non function properties

On 6/08/20 6:42 am, David Mertz wrote: @unit("meter") a = 3  # a = unit("meter")("a", 3) @unit("foot") b = 4   # b = unit("foot")("b", 4) This still doesn't explain why the decorator syntax would be significantly better than just calling the function directly. meters = unit("meter") feet = uni

[Python-ideas] Re: Decorators for class non function properties

On 7/08/20 2:47 am, David Mertz wrote: The only difference is that in the usual existing style, 'a' doesn't know that it's called "a".  You and Steven have both, basically, said "Why would you possibly care about that?" I've only really been thinking about attributes, but I suppose it might be

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 8/08/20 4:09 am, Ricky Teachey wrote: If that incongruity were to be fixed, it seems to me it would become *obvious* that the semantic meaning of ` m[1, 2, a=3, b=2]` should definitely be: m.__get__(1, 2, a=3, b=4) It would certainly achieve that goal. The question is whether it would be

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

On 4/08/20 9:12 am, Guido van Rossum wrote: then presumably calling `c[1, index=2]` would just be an error (since it would be like attempting to call the method with two values for the `index` argument), Hmmm, does this mean that classes providing index notation would now need to document the

[Python-ideas] Re: Inline Try-Except Clause

On 8/08/20 3:24 am, Paul Moore wrote: def is_valid_specifier(s): try: packaging.specifiers.SpecifierSet(s) return True except packahing.specifiers.InvalidSpecifier: return False This doesn't quite follow the pattern, because it doesn't return the result of t

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On 9/08/20 10:43 am, Guido van Rossum wrote: But integer ranges? I guess they would be useful to catch array indexing mistakes, I'm not sure they would. For an index error to be caught at compile time, the thing being indexed has to have a size known to the compiler. This was always the case in

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

On 14/08/20 10:03 pm, Jonathan Fine wrote: NO POSITIONAL ARGUMENTS I'd like     >>> d[x=1, y=2] to be valid syntax. It's not clear to me that all agree with this. If keywords are to be allowed, it seems reasonable to me that this should be legal.     >>> d[x=1, y=2] = 42     >>> d[x=1, y=2

[Python-ideas] Re: basic matrix object

Another class of folks who might find something like this useful is those playing around with computer graphics using pygame, pyglet, etc. where coordinate transformations are used a lot. Bringing in numpy for that can seem like massive overkill for a tiny game. -- Greg __

[Python-ideas] Re: basic matrix object

On 14/08/20 9:05 pm, Marco Sulla wrote: Another big problem with tensors is the covariance and contravariance. Usually in informatic you denote the covariance with the subscript operator, that on paper is written as subscript. Contravariant index on the contrary is a superscript. Not sure how a p

[Python-ideas] Re: Not-so-basic tensors [was: basic matrix object]

On 15/08/20 5:31 am, Stephen J. Turnbull wrote: It seems to me you could have a Tensor class whose constructor takes a bool argument 'contravariant' (default False), and then recommend that users adopt a naming convention to distinguish covariant Tensors from contravariant Tensors. You would ne

[Python-ideas] Re: basic matrix object

On 16/08/20 4:26 am, Ricky Teachey wrote: There are certainly instances where I've needed to used matrices to solve a system of equations in an automated way. But most of time it's simply not needed, If we're going to have a class that supports matrix multiplication, I think we should at leas

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

On 16/08/20 11:49 am, Guido van Rossum wrote: SEMANTICS OF NO ARGUMENTS I can see two basic ways of allowing no arguments. One is for the interpreter to construct an object that is the argument passed to __getitem__ and so forth. The other is to not pass an argument at all. I

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

On 17/08/20 8:19 am, Sebastian Berg wrote: [1] The difference is that `arr[()]` extracts a scalar, while `arr[...]` returns the array (container) unchanged. This difference only matters for zero dimensional arrays. There may be reasons to prefer one over the other, but I can't think of any righ

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

On 17/08/20 9:58 pm, Antoine Pitrou wrote: Probably because exploiting Python abstraction facilities to build DSLs has/had long been frown upon in this community? That was the leitmotiv back when people were marvelling over Ruby's flexibility in the area. As far as I remember, what was frowned

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

On 18/08/20 6:00 am, Christopher Barker wrote: But from a language design perspective, the [] operator is a way to "index" a container -- get part of the container's contents. And from this perspective, no index makes no sense. It can make sense if you have a zero-dimensional array. Or as much

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

On 18/08/20 6:37 am, Jonathan Fine wrote: if     >>> something[*argv] is allowed, then what was a syntax error becomes a run-time error. I don't think so. If argv is empty, this is more akin to x = () something(x) which we presumably still want to allow. Opponents of a[] aren't trying

[Python-ideas] Re: Custom keywords (from: Decorators for class non function properties)

On 18/08/20 7:58 am, Marco Sulla wrote: My proposal is to add a way for third party modules to add custom keywords. Example: from mykeywords import @const @const a = 1 What would that mean? -- Greg ___ Python-ideas mailing list -- python-ideas@pytho

[Python-ideas] Re: Custom keywords (from: Decorators for class non function properties)

On 18/08/20 5:39 pm, Marco Sulla wrote: The new `@const` will be added as a hook to the PEG parser. if the PEG parser finds a `@const`, it will invoke the miniparser of `mykeywords` module inherent to `@const`. I don't think this is likely to be accepted into the language. Guido has always been

[Python-ideas] Re: Improve error message for trying to import itself

Maybe check whether the module being imported from is shadowing another module further along the search path and warn about that? -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.

[Python-ideas] Re: Improve error message for trying to import itself

On 22/08/20 6:43 am, Serhiy Storchaka wrote: It would have non-zero cost. There is a common idiom: try: from foo import bar except ImportError: def bar(): ... In this case you would need to try importing foo from other locations. I wouldn't suggest going that far.

[Python-ideas] Re: Deferred, coalescing, and other very recent reference counting optimization

On 24/08/20 3:24 am, Raihan Rasheed Apurbo wrote: In CPython we have reference counting. My question is can we optimize current RC using strategies like Deferred RC and Coalescing? If no then where would I face problem if I try to implement these sorts of strategies? I gather there have been so

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 26/08/20 10:03 am, Stefano Borini wrote: But you have a point that whatever the implementation might be, it has to play nice with the current dict() behavior. Yet, if we were to add an enhanced dunder, nothing for the current dict would change. Despite arguing against it earlier, I think I'm

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

As a point of interest, is get() considered an official part of the mapping protocol, or just nice-to-have? The docs don't seem to be very clear about that. There used to be some tables listing the methods making up the core sequence and mapping protocols, but I can't find them now. Have they bee

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 26/08/20 1:59 pm, Steven D'Aprano wrote: Most existing uses of subscripts already don't fit that key:value mapping idea, starting with lists and tuples. Not sure what you mean by that. Given `obj[spam]`, how does the interpreter know whether to call `__getitem__` or `__getindex__`? What if

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 12:53 am, Steven D'Aprano wrote: Presumably the below method is provided by `object`. If not, what provides it? def __getindex__(self, *args, **kwds): if kwds: raise TypeError("Object does not support keyword indexes") if not args: r

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On 27/08/20 2:32 am, Guido van Rossum wrote: The mixins are part of the contract. You are free to override them, their implementation is just a helpful,default. That doesn't really answer my question. To put it another way: If someone wanted to implement an object that obeys the mapping protoco

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 3:51 am, Ricky Teachey wrote: On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: No, it would be done by checking type slots, no MRO search involved. Can you elaborate on this for my understanding? For frequently-used special met

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 4:32 am, Ricky Teachey wrote: class Q:     def __subscript__(self, method_name, *args, **kwargs):          return getattr(self, method_name)(*args, **kwargs)     def __getitem__(self, *args, **kwargs): ...     # Note that I have made the RHS value the first argument in __setitem_

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 8:00 am, Christopher Barker wrote: Translating to: thing.__setitem__(self, (ind1, ind2), value, kwd1=v1, kw2=v2) which is pretty darn weird If we use a new set of dunders, the signature of the one for setting could be def __setindex__(self, value, *args, **kwds) which is not

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 10:53 am, Todd wrote: On Wed, Aug 26, 2020, 18:04 Stefano Borini > wrote: On Wed, 26 Aug 2020 at 17:50, David Mertz mailto:me...@gnosis.cx>> wrote: you want this acquired_data[time, detector] to be allowed to be written as acqui

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 3:56 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 03:28:07AM +1200, Greg Ewing wrote: > We're falling back to __getitem__ here, which doesn't currently allow keywords, Point of order: **the getitem dunder** already allows keywords, and always has, and alwa

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On 29/08/20 12:06 am, David Mertz wrote: I only thought of it because `mydict[foo=bar]` now raises a SyntaxError, so raising something different would technically be a change in behavior. It's going to be a change in behaviour whatever you raise, because it's currently a compile time error. -

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 29/08/20 2:07 pm, Steven D'Aprano wrote: Better would be to add a new future directive to change the parsing of subscripts, and allow people to opt-in when they are ready on a per-module basis. from __future__ import subscript_arguments I don't think that would help, at least not on it

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 29/08/20 4:50 pm, Ricky Teachey wrote: (however [Greg Ewing was] talking about 3 dunders-- still hoping he and others might come around to the idea of just one) Whereas I'm hoping that you might come around to the idea of three, :-) Your version is simpler in the sense that it uses

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

Another idea: Instead of new dunders, have a class attribute that flags the existing ones as taking positional and keyword arguments. class ILikeMyIndexesPositional: __newstyleindexing__ = True def __getitem__(self, i, j, spam = 42): ... Advantages: No new dun

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 3:49 am, Adam Johnson wrote: def _parse_subscripts(self, /, x, y): return x, y def __getitem__(self, item=MISSING, /, **kwargs): if item is MISSING: args = () elif isintance(item, tuple): args = item else: args = (item,) x, y = sel

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 2:10 pm, Steven D'Aprano wrote: > I wrote: So I'd be fine with having to write a[(1,)] to get a one-element tuple in both the old and new cases. But the problem is that this is a change in behaviour, Sorry, I got that backwards! What I should have said was that a[1,] would continu

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 30/08/20 3:06 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote: a[17, 42] a[time = 17, money = 42] a[money = 42, time = 17] I don't think that something like that is exactly the intended use-case for the feature, I don't

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 7:45 pm, Guido van Rossum wrote: Do we want to support d[**kwargs]? It can be done, alternatively we could just ask the user to write the __getitem__/__setitem__ call explicitly. I thought we usually discouraged directly calling dunders unless there's no alternative, because there

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

A thought just occurred to me. If we hadn't got rid of tuple unpacking in argument lists, we would have been able to write def __getitem__(self, (x, y, z), **kwds): ... -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To uns

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

I've written a decorator to go along with Guido's proposed implementation, to make it easier to write item dunders that take positional args that can also be specified by keyword. #--- from inspect import signature def positional_indexing(m): def f(s

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:37 am, Guido van Rossum wrote: I recall a law from evolutionary biology that went something like “once a feature is gone it won’t evolve a second time (in the same species)”. I have no interest in restoring argument unpacking. That can't be an absolute law. If a species loses a f

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:35 pm, Random832 wrote: x[(1,)] old arg=(1,); new args=((1,),)? > x[(1,2)] old arg=(1,2); new args=((1,2),)? No, I proposed *not* to do those -- putting parens around the arguments would continue to make no difference, regardless of which dunder was being called. Also, do we wa

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 4:11 pm, Guido van Rossum wrote: Can I write a.__getitem__((1, 2), k=3) and the function will see (i, j, k) == (1, 2, 3)? Yes. Okay, and if I write a.__getitem__((1, 3), k=2) will the function see the same thing? No, it will see (i, j, k) == (1, 3, 2). It's the same as if you w

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 4:23 pm, Guido van Rossum wrote: On Sun, Aug 30, 2020 at 2:43 AM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: On 30/08/20 7:45 pm, Guido van Rossum wrote: > I think we should say no to d[*args], because that will just become > d[(*args)]

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 2/09/20 2:24 am, Steven D'Aprano wrote: On Sun, Aug 30, 2020 at 05:49:50PM +1200, Greg Ewing wrote: On 30/08/20 3:06 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote: a[17, 42] a[time = 17, money = 42] a[money = 42, time = 17] &

[Python-ideas] Re: PEP-0472 revisited - draft

On 2/09/20 3:20 am, Christopher Barker wrote: I think that type hints are used in specific places, and thus the interpreter could know if a given [] was a type hint or an indexing operation, and thus could dispatch it differently. I don't think so. We need to be able to do things like Wib

[Python-ideas] Re: Proposed new syntax for subscripting (was PEP 472)

On 2/09/20 3:44 am, Steven D'Aprano wrote: (9) Keyword-only subscripts are permitted: obj[spam=1, eggs=2] # calls type(obj).__getitem__(spam=1, eggs=2) del obj[spam=1, eggs=2] # calls type(obj).__delitem__(spam=1, eggs=2) An alternative is to pass an empty tuple as the ind

[Python-ideas] Re: Proposed new syntax for subscripting (was PEP 472)

On 2/09/20 5:14 am, Stephan Hoyer wrote: On Tue, Sep 1, 2020 at 9:59 AM David Mertz I think we need this for the same reason why we need **kwargs in normal function calls: it makes it possible to forward dictionaries of arguments to another method. If we don't have dict unpacking, you'd have t

[Python-ideas] Re: On blessed abuse of operators [was: Changing item dunder ...]

On 2/09/20 8:35 am, Chris Angelico wrote: Maybe we need a different term for this kind of overloading, where we're not even TRYING to follow the normal semantics for that operation, but are just doing something because it "feels right". Operator repurposing? -- Greg ___

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

On 5/09/20 10:15 am, Chris Angelico wrote: Remember that if this matters to you, you can "from math import inf". But you still need to use full eval on your repr, which could be a serious security problem in some contexts. If it were a built-in constant, ast.literal_eval could be used instead.

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

On 5/09/20 10:51 am, Chris Angelico wrote: If you make "inf" a keyword, then even the Python standard library is broken. The OP didn't suggest that, he suggested adding a new name such as Infinity that reprs could use. -- Greg ___ Python-ideas mailin

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

On 6/09/20 8:08 am, David Mertz wrote: Lots of people have noted that being able to eval a repr is only a vague goal in Python, that works *often* at most. Still, the fact that it *almost* works for floats, except for certain specific values, is a bit annoying. Maybe the solution is for the re

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

On 6/09/20 8:08 am, David Mertz wrote: The only real goal I've seen is that you hope that `x == eval(repr(x))` for floating point numbers.  But that is doomed to failure since it cannot work for NaN by its very definition. I think that just means the definition needs a bit more finesse. It wou

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

On 7/09/20 6:03 am, Christopher Barker wrote: Would that require that it be a keyword? I don't think so, couldn't it be "just a name" in most contexts, like "True" was in py2, which did work in ast.literal_eval()? There could be a special bytecode that looks it up as a name, and if that doesn'

[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?

On 12/09/20 12:21 pm, Guido van Rossum wrote: I had heard of this concept in another language (C++? Smalltalk?) Probably C++ or Java. Smalltalk doesn't have static methods, only a form of class method. IMO, static methods are a kludge only needed in languages that make classes do double duty a

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

On 12/09/20 8:36 pm, Serhiy Storchaka wrote: it is not hard to write your own helper with interface and defaults that suit you. It will take less time than writing a letter in a mailing list. Obviously what's needed is an IDE feature such that whenever you write a 3-line function that you haven

[Python-ideas] Re: f-strings as assignment targets

On 20/09/20 7:45 am, Christopher Barker wrote: In [4]: from parse import parse In [5]: parse("{x}{y}{z}", a_string) Out[5]: In [6]: parse("{x:d}{y:d}{z:d}", a_string) Out[6]: So that's interesting -- different level of "greadiness" for strings than integers Hmmm, that seems really unintuit

[Python-ideas] Re: f-strings as assignment targets

On 20/09/20 9:25 pm, Stephen J. Turnbull wrote: Are you sure that shouldn't be "I was told to expect three things, but I found six?" ;-) And why not parse a_string using the "grammar" "{x}{y}{z}" as {'x': 2345, 'y': 6, 'z': 7}? As a human I tend to expect input formats to be somewhat sensible

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 21/09/20 6:59 pm, Steven D'Aprano wrote: On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote: I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals. There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 22/09/20 6:13 am, Abdur-Rahmaan Janhangeer wrote: All law projects remain law projects. But we call law projects which has been accepted as law. I take it you're referring to the fact that (in some places at least) a proposed law is called a "bill" and when accepted becomes an "act". That'

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 22/09/20 6:39 am, Abdur-Rahmaan Janhangeer wrote: I referred PEP8, a meta-pep as PAP8 in the first mail itself If such PEPs are included under PAPs, the 'authorative' point holds Informational PEPs such as PEP 8 are relatively rare. I don't think the whole PEP process should be warped just b

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 4:32 am, Oscar Benjamin wrote: annotations could be used to document in a statically analysable way what the "expected" exceptions are. A type checker could use those to check whether a caller is handling the *expected* exceptions But that would be inappropriate. Even if an exceptio

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 5:27 am, Wes Turner wrote: Safe coding styles (in other languages) do specify that *there may not be any unhandled exceptions*. I don't think a blind rule like that actually makes a program any safer. It encourages a coding style that covers up problems and carries on to produce ga

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 7:26 am, Oscar Benjamin wrote: The suggestion ... was not that it would be a type-checking error to call the inverse function without catching the exception. It only becomes a type-checking error if a function calls the inverse function and claims not to raise the exception. This is

[Python-ideas] Re: PEP 637 and keyword only subscripts

On 27/09/20 3:43 pm, Ricky Teachey wrote: telling people "either provide a default argument for both index AND value in your __setitem__ method, or neither" is also a perfectly legitimate way forward. Giving the value parameter of a __setitem__ a default seems like a weird thing to do, since u

[Python-ideas] Re: PEP 637 and keyword only subscripts

On 27/09/20 7:10 pm, Steven D'Aprano wrote: kw = get_keywords() # oops, this returns an empty dict obj[**kw] = value If an explicit d[] is going to be a compile-time error, maybe anything that has the same effect at run time should be an error too? -- Greg __

[Python-ideas] Re: PEP 637 and keyword only subscripts

On 29/09/20 4:19 pm, Ben Rudiak-Gould wrote: it's worth mentioning that Haskell has tuples of length 0, 2, 3, ..., but no tuples of length 1. Tuples are meant for putting n values where 1 value is expected, and when n=1 you just put the value there. To elaborate on that a bit, the length of a

[Python-ideas] Re: A new suggestion for Python

On 1/10/20 4:25 pm, David Mertz wrote: In all the years I've used and taught namedtuples, I think I've never used the ._replace() method.  The leading underscore is a hint that the method is "private" Usually that would be true, but namedtuple is a special case. The docs make it clear that the

[Python-ideas] Re: CPP Namespaces For Python

In Python 3 you can do this without any decorators. The following works and produces the same output: class AA: def greet(A_instance): print("Hello", A_instance.name) class BB: def greet(A_instance): print("Hi", A_instance.name) class A: def __init__(self, state, name): self.

[Python-ideas] Re: CPP Namespaces For Python

On 7/10/20 2:45 pm, Random832 wrote: I think the feature should allow for the functions to directly access each other from the namespace's scope without requiring an attribute lookup. That got me thinking, and I came up with this: def submodule(f): return type(f.__name__, (), f()) @submodul

[Python-ideas] Re: CPP Namespaces For Python

New improved version: def submodule(f): co = f.__code__ i = len(co.co_consts) b = bytes([0x64, i, 0x83, 0x0, 0x53, 0x0]) f.__code__ = co.replace( co_consts = co.co_consts + (locals,), co_code = co.co_code[:-4] + b ) return type(f.__name__, (), f()) @submodule def Stuff():

[Python-ideas] Re: Variadic generics PEP draft

On 7/10/20 11:05 pm, Matthew Rahtz via Python-ideas wrote: Something that's on many of our wishlists is support for variadic generics. Here's a first draft of a PEP detailing how they might work. https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE318/edit Generally lo

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

On 12/10/20 3:44 pm, Wes Turner wrote: [Microscopic] black holes do deal with infinity in certain regards.) Not really. General relativity predicts that matter will collapse into a point of zero size and infinite density inside a black hole. But that's more likely to mean that GR is wrong under

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

On 12/10/20 10:39 am, Wes Turner wrote: We should not discard the scalar in scalar*infinity expressions. I don't think that would help as much as you seem to imagine it would. Consider f(x) = 1/x**2, g(x) = 1/x**3, h(x) = f(x) / g(x). Keeping a scalar multiplier attached to infinities isn't

[Python-ideas] Re: Exceptions as function calls to kill boilerplate

On 13/10/20 10:16 am, jmwar...@gmail.com wrote: class MySpecialException(Exception): def __init__(self, some, variables, i, am, tracking): self.some = some ... ... try: if some_test_that_fails(variables): raise MySpecialException(a, b, c, d, e, f) except MySpecialException

[Python-ideas] Re: Exceptions as function calls to kill boilerplate

On 14/10/20 6:55 am, jmwar...@gmail.com wrote: Why waste the lines defining them anywhere other than where they are thrown and where they are handled for most of them? If you expect people to catch these exceptions, they need to be documented somewhere. A class statement does a much better job o

[Python-ideas] Re: Exact decimal multiplication and division operations

On 15/10/20 1:59 pm, Tim Peters wrote: I suggested following the standards' rules (the constructor works the same way as everything else - it rounds) for Python's module too, but Mike Cowlishaw (the decimal spec's primary driver) overruled me on that. Did he offer a rationale for that? -- Greg

[Python-ideas] Making the for statement work better with nested functions

Starting a new thread for this as suggested by Guido. On 18/11/20 7:20 pm, Guido van Rossum wrote: On Tue, Nov 17, 2020 at 22:12 Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: If there's anything I would change, it would be to have the for statement create a

[Python-ideas] Re: Adding PyInstaller to the standard library

On 19/11/20 5:59 pm, Chris Angelico wrote: What's the advantage of having it as an official part, rather than remaining a third-party tool? The advantage is that you know it will always be there and will be compatible with the relevant Python, rather than being at the mercy of a 3rd party to ke

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 12:24 am, Chris Angelico wrote: Have you considered the value of using zipapp You get all the advantages of a single runnable file, and all the advantages of NOT including the full Python interpreter with it. It won't have all the properties of an app bundle on MacOSX, though.

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 8:17 am, Steven D'Aprano wrote: Firstly, does that matter? And secondly, what would it take to give it those additional properties? It matters because it won't look or behave like a MacOSX app to the user. An app bundle comes with metadata that specifies a bunch of things, such as

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 11:32 am, Chris Angelico wrote: It's very tempting to think "oh, I could just make it easier for my users, and then they don't have to think about anything". But what happens when there's a security patch for Python? Are they going to continue to not > think about the dependency? T

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 12:24 pm, Paul Moore wrote: I'm not sure about an installer. To me that means integrating with system "installed apps" mechanisms. By "installer" I just mean something that gets installed the way users expect on that platform. On Windows that means something you run that puts the ri

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 9:17 pm, Andrew Svetlov wrote: Digging into the problem more, I've figured out that PyInstaller has hooks for a bunch of popular libraries to make them work. I've seen this sort of thing in other app bundl

[Python-ideas] Re: Adding PyInstaller to the standard library

On 21/11/20 3:03 am, Paul Moore wrote: For my own purposes, what I *actually* want is to specify a list of 3rd party packages ... I *don't* want clever logic to decide how to strip out "unused" bits. I concur. With venvs, it seems like it should be possible to have a very simple tool that just

[Python-ideas] Re: Adding PyInstaller to the standard library

On 21/11/20 3:59 pm, Christopher Barker wrote: On Fri, Nov 20, 2020 at 4:18 PM Greg Ewing With venvs, it seems like it should be possible to have a very simple tool that just packages up everything in your venv. > conda is similar -- there is even the "conda constructor&qu

[Python-ideas] Re: Adding PyInstaller to the standard library

On 22/11/20 4:31 pm, Christopher Barker wrote: unfortunately, that's not how most python packages are set up -- you install the whole thing at once. As an example, it's really tricky to use even one function from scipy without installing the whole thing. Something needs to change about how Pyt

[Python-ideas] Re: Adding PyInstaller to the standard library

On 23/11/20 11:38 pm, Mathew Elman wrote: I would argue this sounds like a case for a "python_runner", i.e. a lightweight python vm that can run python apps, e.g. zipapps. Something like the blender_runner for blender. Making it explicitly an app that runs via some other engine. How would tha

[Python-ideas] Re: Adding PyInstaller to the standard library

On 24/11/20 9:05 pm, Chris Angelico wrote: It CAN be a proper point-and-click GUI thing. You can have a fully executable Python script if it has no dependencies (just distribute a single .py file with a shebang at the top) ... But to most people a "proper point and click GUI thing" includes hav

[Python-ideas] Re: Adding PyInstaller to the standard library

On 25/11/20 11:48 am, Steven D'Aprano wrote: In a language without declarations, how do you know that something is unused? Personally, I don't mind if I have to *tell* it what I'm using. I don't insist on the stripping-out being automatic, and I would actually prefer it not to be. To support t

<    1   2   3   4   5   6   7   8   9   >