Re: [Python-ideas] Move optional data out of pyc files

2018-04-10 Thread Zachary Ware
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

2018-03-02 Thread Zachary Ware
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

2017-11-15 Thread Zachary Ware
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()"

2017-02-14 Thread Zachary Ware
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

2016-12-16 Thread Zachary Ware
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

2016-09-19 Thread Zachary Ware
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

2016-09-09 Thread Zachary Ware
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/