Re: [Python-ideas] Move optional data out of pyc files
On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico wrote: > A deployed Python distribution generally has .pyc files for all of the > standard library. I don't think people want to lose the ability to > call help(), and unless I'm misunderstanding, that requires > docstrings. So this will mean twice as many files and twice as many > file-open calls to import from the standard library. What will be the > impact on startup time? What about instead of separate files turning the single file into a pseudo-zip file containing all of the proposed files, and provide a simple tool for removing whatever parts you don't want? -- Zach ___ 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] breakpoint(): print(*args, **kwargs) before entering pdb
On Fri, Mar 2, 2018 at 12:00 PM, Carl Bordum Hansen wrote: > I played around with a newer Python build, but when using the new > `breakpoint` builtin, I missed my weapon of choice: dirty print-debugging. > > I suggest we combine forces and make the default `sys.breakpointhook` > forward *args and **kwargs to print before entering pdb. You can do this for yourself by adding the following to sitecustomize.py or similar: import sys def printingbreakpointhook(*args, **kwargs): print(args, kwargs) return sys.__breakpointhook__() sys.breakpointhook = printingbreakpointhook -- Zach ___ 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] Looking for input to help with the pip situation
On Wed, Nov 15, 2017 at 1:07 PM, Steve Dower wrote: > My preferred solution for this is to rename "py.exe" to "python.exe" (or > rather, make a copy of it with the new name), and extend (or more likely, > rewrite) the launcher such that: > > * if argv[0] == "py.exe", use PEP 514 company/tag resolution to find and > launch Python based on first command line argument > * if argv[0] == "python.exe", find the matching > PythonCore/ install (where tag may be a partial match - e.g. > "python3.exe" finds the latest PythonCore/3.x) > * else, if argv[0] == ".exe, find the matching > PythonCore/ install and launch "-m " > > With the launcher behaving like this, we can make as many hard links as we > want in its install directory (it only gets installed once, so only needs > one PATH entry, and this is C:\Windows for admin installs): > * python.exe > * python2.exe > * python3.exe > * python3.6.exe > * pip.exe > * pip2.exe > * pip3.exe I haven't been following this thread closely, but this sounds lovely. I'm not terribly keen on cluttering up C:\Windows with this, but that's a minor issue. -- Zach ___ 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] Contraction for "for x in range()"
On Tue, Feb 14, 2017 at 3:06 PM, Mikhail V wrote: > I have a small syntax idea. > In short, contraction of > > for x in range(a,b,c) : > > to > > for x in a,b,c : > > I really think there is something cute in it. > So like a shortcut for range() which works only in for-in statement. > So from syntactical POV, do you find it nice syntax? > Visually it seems to me less bulky than range(). > > Example: > > for x in 0,5 : > print (x) > for y in 0,10,2 : > print (y) > for z in 0, y+8 : > print (z) This is already valid and useful syntax, and thus a non-starter. >>> for x in 0,5 : ... print (x) ... for y in 0,10,2 : ... print (y) ... for z in 0, y+8 : ... print (z) ... 0 0 0 8 10 0 18 2 0 10 5 0 0 8 10 0 18 2 0 10 -- Zach ___ 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] New PyThread_tss_ C-API for CPython
On Fri, Dec 16, 2016 at 6:07 AM, Erik Bray wrote: > Greetings all, > > I wanted to bring attention to an issue that's been languishing on the > bug tracker since last year, which I think would best be addressed by > changes to CPython's C-API. The original issue is at > http://bugs.python.org/issue25658, but I have made an effort below in > a sort of proto-PEP to summarize the problem and the proposed > solution. I am not familiar enough with the threading implementation to be anything more than moral support, but I am in favor of making some change here. This is a significant blocker to Cygwin support, which is actually fairly close to being supportable. -- Zach ___ 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] Suggestion: Clear screen command for the REPL
On Mon, Sep 19, 2016 at 9:45 AM, eryk sun wrote: > On Mon, Sep 19, 2016 at 1:12 PM, Paul Moore wrote: >> By the way - if you're on a system with readline support included with >> Python, GNU readline apparently has a binding for clear-screen >> (CTRL-L) so you may well have this functionality already (I don;'t use >> Unix or readline, so I can't comment for sure). > > Hooking Ctrl+L to clear the screen can be implemented for Windows > Vista and later via the ReadConsole pInputControl parameter, as called > by PyOS_StdioReadline. It should be possible to match how GNU readline > works -- i.e. clear the screen, reprint the prompt, flush the input > buffer, and write the current line's input back to the input buffer. > > The pInputControl parameter can also be used to implement Unix-style > Ctrl+D to end a read anywhere on a line, whereas the classic > [Ctrl+Z][Enter] has to be entered at the start of a line. That sounds lovely, any chance you could work up a patch? :) -- Zach ___ 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] Null coalescing operator
On Fri, Sep 9, 2016 at 3:01 PM, Arek Bulski wrote: > Sometimes I find myself in need of this nice operator that I used back in > the days when I was programming in .NET, essentially an expression > expr ?? instead > > should return expr when it `is not None` and `instead` otherwise. > > A piece of code that I just wrote, you can see a use case: > > def _sizeof(self, context): > if self.totalsizeof is not None: > return self.totalsizeof > else: > raise SizeofError("cannot calculate size") > > With the oprator it would just be > > def _sizeof(self, context): > return self.totalsizeof ?? raise SizeofError("cannot calculate > size") This was proposed almost exactly a year ago, start reading here: https://mail.python.org/pipermail/python-ideas/2015-September/036289.html -- Zach ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/