Re: [Python-ideas] PEP draft: Unifying function/method classes

lowing Cython/CFFI/etc to use the existing fast paths for native Python functions and/or builtin C functions is a reasonable justification for flipping that switch and doing the extra work needed to make it robust - it's just likely to involve adding a number of `*_CheckExact()` calls in va

Re: [Python-ideas] Sets, Dictionaries

biguating empty container notation" that allowed all four options: * Unambiguous empty dict: {:} * Syntactic empty set: {,} * Empty tuple with optional comma: (,) * Empty list with optional comma: [,] Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Python-ideas] Fixing class scope brainstorm

On 30 March 2018 at 02:53, Paul Moore <p.f.mo...@gmail.com> wrote: > On 29 March 2018 at 16:27, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 28 March 2018 at 04:47, Paul Moore <p.f.mo...@gmail.com> wrote: >>> To me, that would be the ideal. I assume there are

Re: [Python-ideas] Fixing class scope brainstorm

its quirks, I'm still happy enough with it a decade later to call it a successful approach. Cheers, Nick. P.S. This is also a contributing factor to one of the aspects of the sublocals proposal: disallowing closing over them means that a renaming based approach *can* be used to keep them separate fr

Re: [Python-ideas] Fixing class scope brainstorm

On 28 March 2018 at 03:19, Guido van Rossum <gu...@python.org> wrote: > On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> [...] The implicit functions used in the >> comprehension & generator expression cases are just potentially &

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 28 March 2018 at 00:52, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/25/2018 09:46 AM, Ethan Furman wrote: >> >> On 03/24/2018 09:24 PM, Nick Coghlan wrote: >> >>> No, the fact that the expression defining the outermost iterable gets >>> eva

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 27 March 2018 at 01:57, Guido van Rossum <gu...@python.org> wrote: > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> By contrast, the sublocals idea strives to keep the *lifecycle* impact >> of naming a subexpression as negligible

Re: [Python-ideas] Fixing class scope brainstorm

pressions are called and then immediately thrown away, they don't need a persistent cell reference to the closed over variable name. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

expression might live a little longer than it used to as an anonymous subexpression (or substantially longer in the case of compound statement headers), it still wouldn't survive past the end of the statement where it appeared. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

Re: [Python-ideas] Fixing class scope brainstorm

class locals, it would prebind references to builtins and module globals as well. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

esirable). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

nment statements" and "assignment expressions", rather than between "local assignments" and "sublocal assignments"). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

the evaluation order could suddenly shift when a local name > binding was added). One that surprised me earlier today is that it looks like we never transferred the generator expression wording about the scope of evaluation for the outermost iterable over to the sections describing comp

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

of the intended semantic equivalence between "[x for x in sequence]" and "list(x for x in sequence)". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org ht

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 25 March 2018 at 13:51, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman <et...@stoneleaf.us> wrote: > > On 03/24/2018 01:35 AM, Nick Coghlan wrote: > > > >> In comprehensions and generator expressions, we'd need to

Re: [Python-ideas] PEP proposal: unifying function/method classes

On 25 March 2018 at 07:38, Jeroen Demeyer <j.deme...@ugent.be> wrote: > Dear Nick Coghlan, > > First of all, thanks for your insightful comments! > > On 2018-03-24 09:09, Nick Coghlan wrote: > >> As Antoine notes, unifying user-defined functions and builtin

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 25 March 2018 at 01:03, Kirill Balunov <kirillbalu...@gmail.com> wrote: > > > 2018-03-24 17:14 GMT+03:00 Nick Coghlan <ncogh...@gmail.com>: >> >> >> They can be distinguished, just not at module or function scope. To give >> a concrete

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 25 March 2018 at 02:34, Eric Fahlgren <ericfahlg...@gmail.com> wrote: > On Sat, Mar 24, 2018 at 7:14 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> ​​ >> >>> class C: >> ... sequence = range(10) >> ... listcomp = [x for

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

ause relying solely on closures broke too much code (in addition to the class namespace case, you can create a situation with similar constraints by passing a separate locals namespace to exec). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

ails may > differ). > PEP 572 is *mostly* immune, in that it's only the rest of the same statement that can see the name binding. The variant that *doesn't* introduce statement local scoping just leaks outright into the surrounding scope. Cheers, Nick. -- Nick Coghlan | ncogh...@g

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

o double-check the surrounding code and make sure that you're not overwriting an "m" variable already used somewhere else in the current scope. With PEP 572, you don't even need to look, since visibility of the "m" in the following snippet is automatically limited to the sta

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

and think it would avoid a lot of the quirks that otherwise arise when allowing expression level assignments. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

P.S. Pascal was one of the first languages I used to write a non-trivial application (a game of Battleships), so I'm predisposed towards liking ":=" as an assignment operator :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] PEP proposal: unifying function/method classes

e base would then need to be reviewed to determine which of them should be replaced with PyFunction_CheckExact(). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org ht

Re: [Python-ideas] Disallow importing the same module under multiple names

s the directory of the script being added to > the path, not the current working directory. > Scripts add the directory of the script, but the "-m" switch adds the current directory in order to locate modules and packages it can find there (although it's possible we'll attempt to fig

Re: [Python-ideas] Disallow importing the same module under multiple names

On 20 March 2018 at 16:25, Gregory P. Smith <g...@krypto.org> wrote: > On Thu, Mar 15, 2018 at 3:26 AM Nick Coghlan <ncogh...@gmail.com> wrote: > >> If we did head in this direction, then we'd also need to accept & >> implement PEP 499 [1] (which proposes aliasin

Re: [Python-ideas] New PEP proposal -- Pathlib Module Should Contain All File Operations

in its place as a lower level procedural API behind pathlib's object-oriented facade, since raw strings are still frequently going to be easier to work with when mixing and matching Python code and native operating system shell code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Bri

Re: [Python-ideas] Disallow importing the same module under multiple names

hich proposes aliasing __main__ as __main__.__spec__.name in sys.modules when executed with "-m") to avoid causing problems. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0499/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] PEP 506: some thoughts on the output length of token_bytes (and why I think it should be split in half)

id we might change it at any time!" caveat on the default length, and we included that caveat because we weren't sure of the potential future security implications of quantum computing, not because 32 byte tokens are harder to read than 16 byte ones) Cheers, Nick. -- Nick Coghlan | ncogh...@

Re: [Python-ideas] Class autoload

ns can then be aggregated back together into a single public API (e.g. in a package `__init__.py` file) As Chris has noted, function level lazy imports are also already supported, and we've (begrudgingly) made the import system work harder to successfully resolve circular imports in recent release

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

just as 3.x comprehensions do. Adopting such an approach would *dramatically* lower the impact that hiding the bindings from the surrounding scope would have on the overall name resolution semantics. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

me = expr" change, allowing with clauses in comprehensions would let you do (by way of a suitably defined "bind" CM): pairs = [(f(y), g(y)) for x in things with bind(h(x)) as y] Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 3 March 2018 at 03:51, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/02/2018 02:47 AM, Nick Coghlan wrote: > >> On 2 March 2018 at 16:39, Ethan Furman wrote: >> >>> On 03/01/2018 09:08 PM, Nick Coghlan wrote: >>> >> > Adding statemen

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 3 March 2018 at 10:09, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Nick Coghlan wrote: > >> I don't think it should be possible to close over statement locals. >> > > Why not? I gave a more detailed answer to that in https://mail.python.org/pipermail/pytho

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

behind it. (Although it may be worth explicitly answering "Why not use the exact same semantics as 'name = expr'? in the PEP itself, since it's a reasonable question to ask) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 21:50, Paul Moore <p.f.mo...@gmail.com> wrote: > On 2 March 2018 at 11:15, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 2 March 2018 at 19:05, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> The problem with statement local

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

fined anywhere. Even if it's missing, you may still need to check for dynamic injection of module level names via globals(). Seeing ".name" would be different (both for the compiler and for the human reader): if such a reference can't be resolved explicitly within the scope of the curren

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 16:39, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/01/2018 09:08 PM, Nick Coghlan wrote: > >> Adding statement local variables into that mix *without* some form of >> syntactic marker would mean taking an already >> complicated system, and m

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 1 March 2018 at 19:30, Paul Moore <p.f.mo...@gmail.com> wrote: > On 1 March 2018 at 06:40, Chris Angelico <ros...@gmail.com> wrote: > > On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> Since ".NAME" is illegal for b

Re: [Python-ideas] Upgrading python-ideas to MM3?

On 1 March 2018 at 20:11, Antoine Pitrou <solip...@pitrou.net> wrote: > On Thu, 1 Mar 2018 11:08:10 +0100 > Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 1 Mar 2018 15:28:57 +1000 > > Nick Coghlan <ncogh...@gmail.com> wrote: > > > Hi folk

Re: [Python-ideas] Upgrading python-ideas to MM3?

On 1 March 2018 at 17:33, Serhiy Storchaka <storch...@gmail.com> wrote: > 01.03.18 07:28, Nick Coghlan пише: > >> A number of smaller python.org <http://python.org> mailing lists have >> been successfully migrated to the PSF's Mailman 3 infrastructure, for >>

Re: [Python-ideas] Upgrading python-ideas to MM3?

gs through the web UI (since that changes to the MM3 admin) * anyone creating links to emails archived post-migration (since the old pipermail archives will stop getting updated, but post-migration emails will have their archive link in the Archived-At header) Cheers, Nick. -- Nick Coghlan |

[Python-ideas] Upgrading python-ideas to MM3?

associated with it, or else go to https://mail.python.org/mm3/accounts/signup/ and create a new account directly with the appropriate email address. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

o allow statement local name bindings in for loops as well: for .i in range(10): print(.i) # This is fine print(.i) # This is an error (unless an outer statement also sets .i) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

rences .a .a[b].c = (x as .a) # Syntax error (persistent bindings can't target statement locals) b[.a].c = (x as .a) # LHS references .a We may still decide that even the syntactically distinct variant poses a net loss to overall readability, but I do think it avoids many of the confusability problems

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

ble to readers as well as to the compiler, and also reduces the syntactic ambiguity in with statements and exception handlers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-id

Re: [Python-ideas] List assignment - extended slicing inconsistency

lly gets raised, such that when "step == 1" we emit the deprecation warning and then call the same function as the existing early return does. In 3.9+, we'd delete that additional fallback code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-ideas] List assignment - extended slicing inconsistency

So the next step would be to file an issue pointing back to this thread for acknowledgement that this is a design bug to be handled with a DeprecationWarning in 3.8, and a ValueError in 3.9+. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

https://github.com/pypa/python-packaging-user-guide/issues/355 to note that there are more options we should at least mention in the binary extensions guide, even if we don't go into the same level of detail as we do for cffi/Cython/SWIG. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On 20 February 2018 at 16:17, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 19 Feb 2018 20:15:27 +0100 > Stefan Behnel <stefan...@behnel.de> wrote: >> Nick Coghlan schrieb am 02.02.2018 um 06:47: >> > to make the various extension module authoring tools >

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

"integer" rather than "integral". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Coming up with an alternative to PEP 505's None-aware operators

On 17 February 2018 at 02:31, Ethan Furman <et...@stoneleaf.us> wrote: > On 02/15/2018 11:55 PM, Nick Coghlan wrote: >> However, while I think that looks nicer in general, we'd still have to >> choose between two surprising behaviours: >> >> * implicitly

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

uot; is already used for name binding related purposes (albeit not for simple assignments) * "python as expression" and "python as keyword" are both things search engines will accept as queries (search engines tend not to cope very well when you try to search for punctuation characters

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

which means references to subexpressions may last longer than expected (and we'd have the problem where embedded assignments could overwrite existing local variables) The interaction with compound statements would also be tricky to figure out (especially if we went with the "delete after th

[Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

wouldn't* be amenable to the "if expr as name:" syntax extension, as there wouldn't be a single defined pronoun expression to bind the name to. However, the extension to PEP 3150 would allow the statement local namespace to be given an arbitrary name: sorted_data = sorted(data, key=?ns.so

Re: [Python-ideas] Extending __format__ method in ipaddress

On 15 February 2018 at 08:29, Eric Osborne <e...@notcom.com> wrote: > Nick Coghlan suggested I instead extend __format__, which is what the > diffs in the current pull request do. This allows a great deal more > flexibility: the current code takes 'b', 'n', or 'x'

Re: [Python-ideas] Give ipaddresses an __index__ method

o the numbers.Integral ABC?" (IP addresses definitely don't, as there's no concept of addition, subtraction, multiplication, division, etc - they're discrete entities with a numeric representation, not numbers) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, A

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

no mechanism to say "this *is* a boolean value that can be losslessly converted to and from the builtin boolean constants". That isn't a distinction the standard library makes, but it sounds like it's one that NumPy cares about (and NumPy was also the main driver for introducing __ind

Re: [Python-ideas] Consider making Decimal's context use PEP 567

clean solution. The context=None feature is there so that developers can write pure Decimal operations if they choose to do so, rather than always depending on implicit dynamic state. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Bris

Re: [Python-ideas] Support WHATWG versions of legacy encodings

ndividually, and if you're already using ftfy to figure out which fixes are needed, then it shouldn't be a big deal to keep it around for the more relaxed codecs that it provides. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-ideas] Format mini-language for lakh and crore

On 2 February 2018 at 08:23, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Nick Coghlan wrote: >> >> - "," would be short for ",3," with decimal digits >> - "_" would be short for "_3_" with decimal digits >

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On 2 February 2018 at 06:15, Barry Scott <ba...@barrys-emacs.org> wrote: > > > On 30 Jan 2018, at 05:45, Nick Coghlan <ncogh...@gmail.com> wrote: > > I'll also note that one of the things we (and others) *have* been > putting quite a bit of time into is the question o

Re: [Python-ideas] Format mini-language for lakh and crore

On 1 February 2018 at 14:11, Nick Coghlan <ncogh...@gmail.com> wrote: > On 1 February 2018 at 08:14, Eric V. Smith <e...@trueblade.com> wrote: >> On 1/29/2018 2:13 AM, Nick Coghlan wrote: >>> Given the example, I think a more useful approach would be to allow

Re: [Python-ideas] Format mini-language for lakh and crore

On 1 February 2018 at 08:14, Eric V. Smith <e...@trueblade.com> wrote: > On 1/29/2018 2:13 AM, Nick Coghlan wrote: >> Given the example, I think a more useful approach would be to allow an >> optional digit grouping specifier after the comma separator, and allow >> t

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

readily map Python pyc files and extension modules back to the corresponding lines of source code), but the idea of "What about precompiling an extension module?" is already markedly less painful than it used to be. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane,

Re: [Python-ideas] Adding str.isascii() ?

ocations But it's also a readability question: "is_ascii()" and "is_UCS2()/is_BMP()" just require knowing what 7-bit ASCII and UCS-2 (or the basic multilingual plane) *are*, whereas the current ways of checking for them require knowing how they *behave*. Cheers, Nick. --

Re: [Python-ideas] Format mini-language for lakh and crore

P.S. While writing this I noticed that the current format mini-language docs are incorrect and say "integer" where they should be saying "digit+": https://bugs.python.org/issue32720 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Format mini-language for lakh and crore

mport locale >>> locale.setlocale(locale.LC_ALL, "en_IN.utf8") 'en_IN.utf8' >>> locale.format("%d", 10e9, grouping=True) '10,00,00,00,000' Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

AM-second gives a clear financial incentive to investing in software performance improvements). -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/py

Re: [Python-ideas] Official site-packages/test directory

out to its own sdist can be fairly annoying in practice. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Cod

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

ype(msg) There's no need to involve the compiler if you're never going to optimise the code out, and code-rewriters like the one in pytest can be taught to recognise "ensure(condition)" as being comparable to an assert statement. Cheers, Nick. -- Nick Coghlan | ncogh...@

Re: [Python-ideas] Support WHATWG versions of legacy encodings

3/library/codecs.html#codecs.register_error and https://docs.python.org/3/library/exceptions.html#UnicodeError for an overview of the information they're given and what they can do about it). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Syntax to import modules before running command from the command line

On 10 January 2018 at 18:30, Paul Moore <p.f.mo...@gmail.com> wrote: > On 10 January 2018 at 02:39, Nick Coghlan <ncogh...@gmail.com> wrote: >> For the coverage.py use case, an environment-based solution is also >> genuinely helpful, since you typically can't modify sub

Re: [Python-ideas] Support WHATWG versions of legacy encodings

ot;windows-874" doesn't work as an alias for it the > way that "windows-1252" works as an alias for "cp1252". That alias should be > added, right? Aye, that would make sense. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-ideas] Support WHATWG versions of legacy encodings

like a better option to me than offering multiple versions of the codecs (and that could then be done as a tracker enhancement request along the lines of "Make the windows-* text encodings match MultiByteToWideChar"). Cheers, Nick. -- Nick Coghlan | ncogh...@gmai

Re: [Python-ideas] Syntax to import modules before running command from the command line

rage.process_startup()"` would be a fair bit clearer about what was actually going on. That example also shows why I'm wary of offering an import-only version of this: I believe it would encourage folks to write modules that have side effects on impo

Re: [Python-ideas] pdb to support running modules

in order for us to migrate them away from using those private interfaces. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-id

Re: [Python-ideas] make Connections iterable

connections, then the lack of iteration support seems equally reasonable. Hence my suggestion of providing a docs recipe showing an example of wrapping a connection in a generator in order to define a suitable way of getting from a raw bytestream to iterable chunks. Cheers, Nick. -- Nick Coghlan

Re: [Python-ideas] make Connections iterable

s) while also showing how to adapt the connection to the iterator protocol, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/ma

Re: [Python-ideas] Syntax to import modules before running command from the command line

hen is that "python -M numpy" would just be a less flexible alternative to a command like "python -C 'import numpy as np'". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Pyt

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

without reporting a type error seems like a bug magnet to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Repr of lambda

On 22 Dec. 2017 12:32 pm, "Chris Angelico" wrote: On Fri, Dec 22, 2017 at 9:43 AM, Chris Barker wrote: > Every python object has an object identity, and the way to get it is with > the id() function. The id is also part of the default object repr, but

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

y cause surprising behaviour). Indexing & slicing were the primary original use case for that approach (hence the method name), but it's also used for sequence repetition, and other operations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Python-ideas] PEP 447: Adding type.__getdescriptor__

On 3 December 2017 at 21:36, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > >> On 3 Dec 2017, at 03:58, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> On 2 December 2017 at 01:12, Ronald Oussoren <ronaldousso...@mac.com> wrote: >>> On 1 D

Re: [Python-ideas] Provide a way to import module without exec body

On 3 December 2017 at 13:22, Nick Coghlan <ncogh...@gmail.com> wrote: > On 2 December 2017 at 07:55, Brett Cannon <br...@python.org> wrote: >> As for the completely separating the loading and execution, I don't have a >> need for what's being proposed so I don't have a

Re: [Python-ideas] Provide a way to import module without exec body

btleties around handling backwards compatibility with __import__ overrides (essentially, CREATE_MODULE would have to revert to doing all the work, while EXEC_MODULE would become a no-op), but the basic idea seems plausible. Cheers, Nick. -- Nick Coghlan | ncogh...@g

Re: [Python-ideas] PEP 505 vs matrix multiplication

def call_if_not_none(lhs, deferred_rhs): return lhs if lhs is not None else deferred_rhs(lhs) first_seen = call_if_not_none(site.first_seen, (??.isodate()) However, I think that would actually be less clear and more confusing than the inline impli

Re: [Python-ideas] PEP 447: Adding type.__getdescriptor__

On 2 December 2017 at 01:12, Ronald Oussoren <ronaldousso...@mac.com> wrote: > On 1 Dec 2017, at 12:29, Nick Coghlan <ncogh...@gmail.com> wrote: >> 2. Define it as a class method, but have the convention be for the >> *caller* to worry about walking the MRO, and hence a

Re: [Python-ideas] PEP 505 vs matrix multiplication

On 1 December 2017 at 04:49, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 29 Nov 2017 18:14:36 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: >> >> As far as utility goes, I put it in a similar category to matrix >> multiplication: if you don't need

Re: [Python-ideas] PEP 447: Adding type.__getdescriptor__

rs a way to override the "base.__dict__[name]" part with a call to "base.__dict__['__getdescriptor__'](cls, base, name)" instead. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas maili

Re: [Python-ideas] Provide a way to import module without exec body

er actually use the module, you avoid any transitive imports, as well as any other costs of initialising it). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://

Re: [Python-ideas] PEP 447: Adding type.__getdescriptor__

n None In that version, the __getdescriptor__ signature would be: def __getdescriptor__(dynamic_cls, base_cls, attr): ... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list P

Re: [Python-ideas] Provide a way to import module without exec body

On 1 December 2017 at 18:37, Nick Coghlan <ncogh...@gmail.com> wrote: > On 1 December 2017 at 18:13, Neil Schemenauer > <nas-python-id...@arctrix.com> wrote: >> I have been working on reducing Python statup time. It would be >> nice if there was some way to load a m

Re: [Python-ideas] Provide a way to import module without exec body

needs to be confident that a subsequent actual execution attempt will be able to start. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/lis

Re: [Python-ideas] Add a dict with the attribute access capability

sys >>> type(sys.implementation) So the only thing we don't currently offer is a type that provides both attribute access and mapping access on the *same* object - for SimpleNamespace we require that you request the mapping API with "vars(ns)". Cheers, Nick. --

Re: [Python-ideas] PEP 447: Adding type.__getdescriptor__

ase.__dict__[name] except KeyError: pass return None If you did go this way, then we'd want to add a "types.getdescriptor(cls, name)" API to expose _PyType_Lookup at the Python layer, since "getattr(type(obj), name)" wouldn't be an accurate emul

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

On 29 November 2017 at 22:38, Stephan Houben <stephan...@gmail.com> wrote: > What about more English-like syntax: > > X or else Y The problem with constructs like this is that they look like they should mean the same thing as "X or Y". Cheers, Nick. -- Nick Coghlan

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

rand to be eagerly evaluated, placed in a hidden temporary variable and then referenced multiple times as a subexpression. A similar construct could then also be used in filter expressions in comprehensions to refer back to the loop's result clause: "[f(x) for x in iterable if ?? is not None]&

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

On 29 November 2017 at 18:49, Kirill Balunov <kirillbalu...@gmail.com> wrote: > 2017-11-29 11:14 GMT+03:00 Nick Coghlan <ncogh...@gmail.com>: >> >> It's OK to say "the use case exists, but I still >> don't want that particular syntax for it in Python" (I

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

y "the use case exists, but I still don't want that particular syntax for it in Python" (I'm personally inclined to agree with you on that front). It's not OK to try to claim there are no use cases where the status quo is awkward enough to become irritating (since it's an empirically fal

<    1   2   3   4   5   6   >