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

[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

[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

[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()"

[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

[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/