Mailman 3 June 2016 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

Implicit string literal concatenation considered harmful?
by Guido van Rossum March 14, 2018

March 14, 2018

I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b'). This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden). Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' … [View More]

51 165

https://docs.python.org/fr/ ?
by Julien Palard Feb. 2, 2017

Feb. 2, 2017

o/ The french translation of the Python Documentation [1][2] has translated 20% of the pageviews of docs.python.org. I think it's the right moment to push it do docs.python.org. So there's some questions ! And I'd like feedback. TL;DR (with my personal choices): - URL may be "http://docs.python.org/fr/" - For localized variations of languages we should use dash and lowercase like "docs.python.org/pt-br/" - po files may be hosted on the python's github - existing script to build … [View More]doc may be patched to build translations - each translations may crosslink to others - untranslated strings may be visually marked as so I also opened: http://bugs.python.org/issue26546. # Chronology, dependencies The only blocking decision here is the URL, (also reviewing my patch ...), with those two, translated docs can be pushed to production, and the other steps can be discussed and applied one by one. # The URL ## CCTLD vs path vs subdomain I think we should use a variation of "docs.python.org/fr/" for simplicity and clarity. I think we should avoid using CCTLDs as they're sometime hard or near impossible to obtain (may cost a lot of time), also some are expensive, so it's time and money we clearly don't need to loose. Last possibility I see is to use a subdomain, like fr.docs.python.org or docs.fr.python.org but I don't think it's the role / responsibility of the sub-domain to do it. So I'm for docs.python.org/LANGUAGE_TAG/ (without moving current documentation inside a /en/). ## Language tag in path ### Dropping the default locale of a language I personally think we should not show the region in case it's redundant: so to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the possibility to use a locale code when it's not redundant like for "pt-br" or "de-AT" (German ('de') as used in Austria ('AT')). I think so because I don't think we'll have a lot of locale variations (like de-AT, fr-CH, fr-CA, ...) so it will be most of the time redundant (visually heavy, longer to type, longer to read) but we'll still need some locale (pt-BR typically). ### gettext VS IETF language tag format gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5]. As sphinx is using gettext, and gettext uses underscore we may choose underscore too. But URLs are not here to leak the underlying implementation, and the IETF looks like to be the standard way to represent language tags. Also I visually prefer the dash over the underscore, so I'm for the dash here. ### Lower case vs upper case local tag RFC 5646 section-2.1 tells us language tags are not case sensitive, yet ISO3166-1 recommends that country codes (part of the language tag) be capitalized. I personally prefer the all-lowercase one as paths in URLs typically are lowercase. I searched for `inurl:"pt-br"` to see if I'm not too far away from the usage here and usage seems to agree with me, although there's some "pt-BR" in urls. # Where to host the translated files Currently we're hosting the *po* files in the afpy's (Francophone association for python) [6] github [1] but it may make sense to use (in the generation scripts) a more controlled / restricted clone in the python github, at least to have a better view of who can push on the documentation. We may want to choose between aggregating all translations under the same git repository but I don't feel it's useful. # How to Currently, a python script [7] is used to generate `docs.python.org`, I proposed a patch in [8] to make this script clone and build the french translation too, it's a simple and effective way, I don't think we need more ? Any idea welcome. In our side, we have a Makefile [12] to build the translated doc which is only a thin layer on top of the Sphinx Makefile. So my proposed patch to build scripts "just" delegate the build to our Makefile which itself delegate the hard work to the Sphinx Makefile. # Next ? ## Document how to translate Python I think I can (should) write a documentation on "how to start a Python doc translation project" and "how to migrate existing [9][10][11] python doc translation projects to docs.python.org" if french does goes docs.python.org because it may hopefully motivate people to do the same, and I think our structure is a nice way to do it (A Makefile to generate the doc, all versions translated, people mainly working on latest version, scripts to propagating translations to older version, etc...). ## Crosslinking between existing translations Once the translations are on `docs.python.org`, crosslinks may be established so people on a version can be aware of other version, and easily switch to them. I'm not a UI/UX man but I think we may have a select box right before the existing select box about version, on the top-left corner. Right before because it'll reflect the path: /fr/3.5/ -> [select box fr][select box 3.5]. ## Marking as "untranslated, you can help" the untranslated paragraphs The translations will always need work to follow upstream modifications: marking untranslated paragraphs as so may transform the "Oh they suck, this paragraph is not even translated :-(" to "Hey, nice I can help translating that !". There's an opened sphinx-doc ticket to do so [13] but I have not worked on it yet. As previously said I'm real bad at designing user interfaces, so I don't even visualize how I'd like it to be. [1] http://www.afpy.org/doc/python/3.5/ [2] https://github.com/afpy/python_doc_fr [3] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html [4] http://tools.ietf.org/html/rfc5646 [5] https://en.wikipedia.org/wiki/IETF_language_tag [6] http://www.afpy.org/ [7] https://github.com/python/docsbuild-scripts/ [8] http://bugs.python.org/issue26546 [9] http://docs.python.jp/3/ [10] https://github.com/python-doc-ja/python-doc-ja [11] http://docs.python.org.ar/tutorial/3/index.html [12] https://github.com/AFPy/python_doc_fr/blob/master/Makefile [13] https://github.com/sphinx-doc/sphinx/issues/1246 -- Julien Palard [View Less]

7 8

proposal: "python -m foo" should bind sys.modules['foo']
by Cameron Simpson Jan. 18, 2017

Jan. 18, 2017

Hello all, This is a writeup of a proposal I floated here: https://mail.python.org/pipermail/python-list/2015-August/694905.html last Sunday. If the response is positive I wish to write a PEP. Briefly, it is a natural expectation in users that the command: python -m module_name ... used to invoke modules in "main program" mode on the command line imported the module as "module_name". It does not, it imports it as "__main__". An import within the program of "module_name" makes a new … [View More]instance of the module, which causes cognitive dissonance and has the side effect that now the program has two instances of the module. What I propose is that the above command line _should_ bind sys.modules['module_name'] as well as binding '__main__' as it does currently. I'm proposing that the python -m option have this effect (python pseudocode): % python -m module.name ... runs: # pseudocode, with values hardwired for clarity import sys M = new_empty_module(name='__main__', qualname='module.name') sys.modules['__main__'] = M sys.modules['module.name'] = M # load the module code from wherever (not necessarily a file - CPython # already must do this phase) M.execfile('/path/to/module/name.py') Specificly, this would have the following two changes to current practice: 1) the module is imported _once_, and bound to both its canonical name and also to __main__. 2) imported modules acquire a new attribute __qualname__ (analogous to the recent __qualname__ on functions). This is always the conanoical name of the module as resolved by the importer. For most modules __name__ will be the same as __qualname__, but for the "main" module __name__ will be '__main__'. This change has the following advantages: The current standard boilerplate: if __name__ == '__main__': ... invoke "main program" here ... continues to work unchanged. Importantly, if the program then issues "import module_name", it is already there and the existing instance is found and used. The thread referenced above outlines my most recent encounter with this and the trouble it caused me. Followup messages include some support for this proposed change, and some criticism. The critiquing article included some workarounds for this multiple module situation, but they were (1) somewhat dependent on modules coming from a file pathname and (2) cumbersome and require every end user to adopt these changes if affected by the situation. I'd like to avoid that. Cheers, Cameron Simpson <cs(a)zip.com.au> The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw [View Less]

5 13

Importing public symbols and simultainiously privatizing them, is too noisy
by Rick Johnson Dec. 29, 2016

Dec. 29, 2016

Has anyone else found this to be too syntactically noisy? from module import Foo as _Foo, bar as _bar That is horrifically noisy IMO. The problem is, how do we remove the noise without sacrificing intuitiveness? My first idea was to do this: from module import_private Foo, bar And while it's self explanatory, it's also too long. So i thought... from module _import Foo, bar I'm leaning more towards the latter, but i'm not loving it either. Any ideas?

9 17

Smoothing transition to Python 3
by Neil Schemenauer July 10, 2016

July 10, 2016

I'm nearly finished porting a decently size application from Python 2 to Python 3. It has been a lot of work. I am dubious as to whether the port was really the best use of time. I can imagine there is still millions, possibly billions of lines of Python 2 code that has not yet been converted. Further, my guess is the lines of Python 2 code are still growing faster than the lines of Python 3 compatible code. IMHO, we need to do better in making it easier for people to port code. Here is a … [View More]

30 68

should `dict` supply a default `__missing__` implementation?
by Matt Gilson July 6, 2016

July 6, 2016

The following code raises an `AttributeError`: >>> class D(dict): ... def __missing__(self, k): ... super(D, self).__missing__(k) ... >>> d = D() >>> d['key'] Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in __missing__ AttributeError: 'super' object has no attribute '__missing__' I find this behavior to be a little bit odd as I would have expected the default implementation to have … [View More]

8 20

Unpacking a dict
by Michael Selik July 5, 2016

July 5, 2016

Python's iterable unpacking is what Lispers might call a destructuring bind. py> iterable = 1, 2, 3, 4, 5 py> a, b, *rest = iterable py> a, b, rest (1, 2, (3, 4, 5)) Clojure also supports mapping destructuring. Let's add that to Python! py> mapping = {"a": 1, "b": 2, "c": 3} py> {"a": x, "b": y, "c": z} = mapping py> x, y, z (1, 2, 3) py> {"a": x, "b": y} = mapping Traceback: ValueError: too many keys to unpack This will be … [View More]

32 131

Re: [Python-ideas] Chaining asyncio futures?
by Vincent Michel June 30, 2016

June 30, 2016

>> Wouldn't this be a nice feature in asyncio.Future? It does exist actually, as `asyncio.futures._chain_future`: https://github.com/python/asyncio/blob/master/asyncio/futures.py#L411 It is used in `loop.run_in_executor` and `run_coroutine_threadsafe` to connect asyncio futures and concurrent futures together. > As best as I can work out, the only reason that asyncio Future?s don?t behave this way is that asyncio strongly emphasises the use of coroutines to program in this … [View More]

1 0

Chaining asyncio futures?
by Mark E. Haase June 30, 2016

June 30, 2016

Other async frameworks have constructs similar to asyncio.Future, e.g. JavaScript has Promise[1] and Dart has a Completer/Future pair[2][3]. (For the purpose of this e-mail, I'll call the generic concept a "Future".) JavaScript and Dart allow futures to be chained, such that one Future's callback is invoked only when the other Future completes. For example, consider an API that fetches a string from a URL and returns it, but also has an MRU cache. This API returns a Future because the caller … [View More]

2 1

Re: [Python-ideas] Submitting a job to an asyncio event loop
by Vincent Michel June 27, 2016

June 27, 2016

I did remove it, because the feature has been implemented after the discussion: https://docs.python.org/3/library/asyncio-task.html?highlight=run_coroutine… https://docs.python.org/3/library/asyncio-dev.html#asyncio-multithreading https://github.com/python/asyncio/pull/273 2016-06-27 22:53 GMT+02:00 David Ford <firefighterblu3(a)gmail.com>: > Vincent, your github repo referenced here is 404. did you rename/move it? > > > > On Saturday, September 26, 2015 at 2:29:43 PM UTC,… [View More]

1 0

Re: [Python-ideas] Statically checking purity of functions
by CFK June 22, 2016

June 22, 2016

Why does the checking have to be static? How about a 'trust but verify' approach? If a function is marked pure, python trusts that it is, but turns on code to check for side effects at runtime. If impure code is executed in a pure function, then an exception is raised. That will deal with the weird corner cases brought up earlier, at the cost of not being able to statically type check code. It will also deal with old code that wasn't marked, but happens to be pure. Not sure how to write the … [View More]checks though; maybe with Perl's data tainting approach? Thanks, Cem Karan On Jun 22, 2016 8:39 AM, "Joonas Liik" <liik.joonas(a)gmail.com> wrote: On 22 June 2016 at 13:23, Jukka Lehtosalo <jlehtosalo(a)gmail.com> wrote: > On Fri, Jun 10, 2016 at 11:57 AM, Christoph Groth < christoph(a)grothesque.org> > wrote: >>> >>> This means that any pure function would have to accept as parameters >>> everything it operates on, and you'd need to error on any call to a pure >>> function with impure arguments. >> >> >> You mean because one can never be sure about the purity of global >> variables? That's true, but exactly to the same extent that one cannot be >> sure about the typing annotations of global variables. >> >> I believe that such "weak" checking for purity would still be useful, just >> as the equally weak verification of typing by mypy is useful. > > > I'm late to the discussion, but I agree with Christoph. I doubt purity > checking can reliably enforce anything without making it impractically > restrictive, but even best-effort, partial purity checking could be useful, > similar to how mypy is useful. A checker could catch many (but not all) > purity violations and purity annotations would make programs easier to > reason about for humans and tools. I've thought about this a bit in the past > -- mostly in the context of mypy. I'm not sure whether purity checking would > be more than marginally useful, but at least in some use cases it might be a > valuable a tool. For example, purity checking might help with reasoning > about concurrency and parallelism. However, writing a purity checking tool > for Python that is flexible enough that many programmers would actually want > to use it sounds like a difficult (research?) project. > > Here are some practical considerations: > > 1) We'd need to annotate library functions with respect to purity, as Python > derives much of its value from the available libraries, and we'd want pure > functions to be able to use (pure) libraries. Perhaps stubs in typeshed > would have purity annotations for individual functions. Alternatively, there > could be a typeshed-like repository for purity information only, and a tool > could use information from both repositories. The safest thing would be to > default to impure, unless a function is explicitly annotated as pure. > > 2) Type annotations would likely be needed for practical checking of purity, > as otherwise things like method calls would be hard to check for purity. > Thus purity checking would be a stricter form of static type checking. > > 3) For consistency with PEP 484 style gradual typing, we may want to allow > functions without annotations to be called from pure functions. Tools might > make this user-configurable, as this is clearly a big hole in a purity > checking system. > > 4) It may be necessary to allow impure operations to be used within a pure > function as long the impurity won't be visible outside the function. For > example, perhaps this function should be fine, as an external observer can't > tell whether the function uses pure operations only: > > def squares(n: int) -> List[int]: > a = [] > for i in range(n): > a.append(i * i) > return a > > I`m not sure if I know how to implement this in a useful way, though. I > believe that there is some prior work in this area (not specific to Python). > > Jukka > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ we could have eg: def parallel_map(f, data): if is_pure(f): # <impl that does special optimisations to take advantage of the fact f is truly pure> # special case that uses light weight threads or sth (maybe can run bits of it GIL free or sth, less overhead or sth) # its ok to share immutable data else: #<impl that has no issue with impure f> # eg: multiprocessing process pools.. #its ok to mutate everything becauuse we no longer truly share anything. in other words, even if only a small subset of code can be proven pure it can be useful to help optimise code (in this example to avoid locking by knowing that no 2 parrallel instances of the callback can mock with mutually shared state) for some scenarios it - might be - ok even if we leave the proving to the programmer. (eg a C extension could implement the optimised parallel map in this example and a user defined decorator is enough to shove a flag on to the function f to trigger the optimised code path) if this it is not truly pure tho despite the assertion it might cause issues so in that case it probably is not something that should ship with python by default? _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

1 0

Statically checking purity of functions
by Christoph Groth June 22, 2016

June 22, 2016

Hello, As far as I can tell the following has not been discussed yet on the searchable internet. It may seem that my idea concerns only mypy, but since "typing" is part of the stdlib, I believe it is appropriate for this mailing list. Even though Python is a very dynamic language, in practice many routines (when called with arguments of the intended type) are pure in the functional programming sense, i.e. they have no observable side effects and the result reproducibly depends on the … [View More]

11 14

Re: [Python-ideas] package management is not python-dev's problem :-(
by Victor Stinner June 21, 2016

June 21, 2016

Le 8 juin 2016 1:02 PM, "Thomas Güttler" <guettliml(a)thomas-guettler.de> a écrit : > This statement make me sad. Why is this not python-dev's problem? It was the case in the past, but most discussions ended with bikeshedding, trolls, etc. instead of trying to discuss solutions to fix issues. Since distutils-sig was created, many PEP were aproved and pip evolved faster than before. Victor

1 0

Make Python front end to the C math module
by Steven D'Aprano June 21, 2016

June 21, 2016

Currently the math module is written in C, not Python. This greatly increases the barrier to contributions to math. I suggest that we treat the existing math module as an accelerator module: - rename math.so to _math.so; (or whatever platform-specific name it uses) - add math.py with something like the following content: from _math import * and we're done! That will make it easier for people to contribute pure Python functions in the future. Currently all math functions, regardless … [View More]

5 5

collections.abc.Stream
by Ram Rachum June 19, 2016

June 19, 2016

Is there a way to check in Python whether an object is file-like? (Like `open`, `StringIO`, etc.) I would think that an abc in collections.abc will be the standard solution, like we have for so many other data types, but I can't find one. Thanks, Ram.

7 13

Why aren't slices hashable?
by Ed Minnix June 18, 2016

June 18, 2016

Hello, I was experimenting in the repl and I noticed something odd: slices are not hashable. I was wondering why this would be since, I would think slices are immutable, and most immutable objects are hashable. Thanks, Ed

2 1

Object for accessing identifiers/names
by Koos Zevenhoven June 15, 2016

June 15, 2016

Inspired by the discussions regarding Guido's "M atch statement brainstorm " and " Quick idea: defining variables from functions..." threads, here's an idea regarding names/identifiers. Currently, there is no direct way to work with variable names from within Python. Yes, you can fiddle with __dict__s and locals() and globals(), but there is no convenient general way. To solve this, there could be a way (probably new syntax) for creating an object that can examine and … [View More]

4 4

Wild idea about mutability
by Rob Cliffe June 15, 2016

June 15, 2016

I was prompted to post this after seeing comments on "Proposal to change List Sequence Repetition (*) so it is not useless for Mutable Objects" that you cannot in general tell whether an object is mutable or not. Well, why shouldn't you be able to tell? Python is superb at introspection, but ISTM there's a gap here. Here's an idea for Python N (N>=4): Every object has a boolean __mutable__ attribute. It would e.g. be False for ints and strings, True by default for objects that … [View More]

8 18

Strings can sometimes convert to bytes without an encoding
by Franklin? Lee June 15, 2016

June 15, 2016

Current behavior (3.5.1): >>> bytes('') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: string argument without an encoding Suggestion: If the character size is 1, the `bytes`/`bytearray` constructor doesn't need a specified encoding. High-level idea: If the string only has code points in range(128), encoding is optional (and useless anyway). The new error message could be TypeError: non-ASCII string argument without … [View More]

11 14

Proposal for special name and qualname symbols
by Steven D'Aprano June 14, 2016

June 14, 2016

This is an new thread inspired by the "Quick idea: defining variables from functions that take the variable name" thread. For the benefit of those who haven't read that thread, in a nutshell, there are some functions or classes that find it useful or necessary to know their own name or qualified name. At the moment, apart from a few special cases where the compiler does the work behind the scenes (function and class definitions), the only way to do this is to hard-code the name/qualname … [View More]as a string. The classic example from the standard library is namedtuple: Record = namedtuple('Record', fields) Proposal: we introduce two special symbols to represent the name and qualname at any point. They can be used anywhere an identifier can be used. We could use special dunder names, let's say __NAME__ and __QNAME__, but for now I'm going to use two special symbols: @ for the unqualified bare name; @@ for the qualified name. The namedtuple example would become: Record = namedtuple(@, fields) If your function takes its name parameter somewhere other than the first argument, that's not a problem: MyClass = make_a_class(spam, eggs, name=@, fnord=True) '@' takes on the name, or dotted name, on the left-hand side of an assignment: x = function(@) # @ == 'x' spam.x = function(@) # @ == 'spam.x' If there are multiple targets, and they are all simple or dotted names, @ is a tuple of names: a, b, c.d = function(@) # @ == ('a', 'b', 'c.d') a = b = c.d = function(@) # @ == ('a', 'b', 'c.d') Those two cases are indistinguishable by @. I'm not sure if that's a bug or a feature :-) For now, any other assignment target will be a syntax error. That restriction may be relaxed in the future, if necessary. spam['key'] = function(@) # SyntaxError @ is not restricted to appear inside function calls: element = mapping[@] # like mapping['element'] The qualified name @@ gets the module name: x = function(@@) # @@ = 'module.x' or, inside a class or function, the class/function name: class K: attr = @@ # 'module.K.attr' def method(self): x = @@ # 'module.K.method.x' Whether dunder names or symbols, assignment to them will be illegal: @ = "myname" # SyntaxError Questions and answers: Q: Why @ rather than $? A: $ is too similar to S for my liking, and I believe that Guido has said that $ will never be used for syntax in Python. Q: What's the use-case for qualified names? A: Classes need to know their qualified name for pickling. Q: Isn't this rather magical? A: Of course it is, but the `def` and `class` statements already make use of that compile magic, this just extends it to other things. Q: Are you sure about the module being part of the qualified name? A: I'm not wedded to that idea. If it's not necessary, take it out. Q: Wait a minute, isn't @ used for matrix multiplication now? And @@ may be used for matrix exponentiation in the future? A: Oh yeah, I forgot that. Damn. Guess we'll have to use the dunder names then. Q: But the dunder names are too long to type. A: Then think of your own symbols and propose them :-) -- Steve [View Less]

18 27

bool.from_config_str()
by jab＠math.brown.edu June 14, 2016

June 14, 2016

Dear Python-Ideas, (New here... hope this idea contributes something!) Several times I've had to implement a silly function that converts the odd environment variable (or some other value from the outside world that, perforce, comes in as a string) to the boolean it actually represents. I say "silly" because, for other commonly-needed types of primitive values, we have concise, idiomatic ways to convert them from strings, leaving no need for wheel reinvention: int(os.getenv('NUM_FJORDS')) … [View More]

12 16

eval_literal
by jab＠math.brown.edu June 13, 2016

June 13, 2016

(Riffing off some discussion in another thread, I had another idea I wanted to throw out there.) Given that Eval Really Is Dangerous[1], has something like this ever been considered?: >>> int(str(42)) 42 >>> float(str(42.0)) 42.0 >>> bool(str(False)) # :( True >>> eval_literal('42') 42 >>> eval_literal('42.0') 42.0 >>> eval_literal('False') # :) False >>> eval_literal('', default=False) # shout out to PEP 463 / Michael Selik … [View More]

5 5

Quick idea: defining variables from functions that take the variable name
by Guido van Rossum June 9, 2016

June 9, 2016

In mypy we have a need for type variables, which are created like this: from typing import TypeVar T = TypeVar('T') I just saw a lightning talk about sympy where they define symbols to be used in mathematical equations, like this: from sympy import Symbol x = Symbol('x') I'm sure this is not a new idea, but so far I've always thought that this is pretty esoteric and the approach here is good enough. But maybe we can actually do better, and whatever solution we come up with might … [View More]

29 120