On 10 February 2015 at 14:13, Steve Dower wrote:
> The installer will also need some changes to add it to PATH, which should be
> fairly straightforward, but ping me if you need/want pointers. (It's checked
> in now, so I consider it fair game for anyone who wants to change it.)
I was sort of hop
On 10 February 2015 at 14:13, Steve Dower wrote:
> I was also surprised as I was working on the installer, so +1 on changing
> it.
On a procedural note, does this require a change to the PEP (assuming
it's generally acceptable)? Or is a patch to the code and docs
sufficient?
Paul
On 10 February 2015 at 12:38, Paul Moore wrote:
> tl;dr - Having a shared per-user scripts directory on Windows
> (%APPDATA%/Python/Scripts) causes a number of potential issues when
> users install the same package in multiple Python versions. I'd like
> to suggest that thi
On 10 February 2015 at 12:38, Paul Moore wrote:
> Comments? If this is acceptable, I would be willing to prepare a patch
> for Python 3.5 implementing this.
See http://bugs.python.org/issue23437
As yet untested, as I just realised I need to get Visual Studio 2015
installed to be able to
On 10 February 2015 at 17:45, Steve Dower wrote:
> This is yet another attempt to try and change user behaviour, which I'm not
> thrilled
> about, but I'm really starting to feel that this is the best way out of a bad
> situation.
> It differs from the solutions used on Linux, though there may b
On 10 February 2015 at 20:50, Paul Moore wrote:
> On 10 February 2015 at 17:45, Steve Dower wrote:
>> This is yet another attempt to try and change user behaviour, which I'm not
>> thrilled
>> about, but I'm really starting to feel that this is the best way ou
On 12 February 2015 at 08:05, Thomas Heller wrote:
> Maybe I'm more or less alone with the way I work, but I don't like
> python.exe on my PATH (and py.exe alloes me to do this).
> I start python scripts from the command line either with 'script.py'
> or 'py -3.4 script.py' or 'py -2.7 script.py'.
On 12 February 2015 at 15:37, Steve Dower wrote:
> If venv's activate script sets it, I say go ahead and write it up. If it's
> just virtualenv, I'd rather not explicitly depend on it, especially since
> PEP 397's stated aim is file associations and not command line.
Yep, venv uses it too (see
ht
On 12 February 2015 at 17:13, Thomas Heller wrote:
>> This is how I worked for a long time after py.exe became available.
>> But then I discovered virtualenv, and started using that, and needing
>> to use 2 completely different command sets for "when I'm in a
>> virtualenv" vs "when I'm not" becam
On 12 February 2015 at 17:39, Ethan Furman wrote:
> I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or
> .anything-else.
Agreed.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
On 12 February 2015 at 14:46, Paul Moore wrote:
> If py.exe detected when the environment variable VIRTUAL_ENV was set,
> and used that virtualenv as the default Python rather than the
> "system" python it normally used, this would be perfect.
>
> I think I'll w
On 12 February 2015 at 16:42, Steve Dower wrote:
> None of my installer changes so far have had a PEP, and only a few people
> have complained about that :) (it does have more documentation than I've ever
> written for an installer before though)
:-) You shouldn't bet on my judgement of what ne
On 12 February 2015 at 20:11, Ethan Furman wrote:
> I believe you are correct; however, as the PEP for the launcher stated [1]
> "use as a general-purpose (aka non-python)
> launcher is explicitly not supported".
Yes, I once used it to start Perl scripts, just because it appealed to
the perverse
On 12 February 2015 at 21:44, Vinay Sajip wrote:
> Off to read the whole thread on python-dev now
I'd also appreciate your views on the spin-off thread and PEP 486
("Make the Python Launcher aware of virtual environments").
Paul
___
Python-Dev mailing
On 13 February 2015 at 00:15, Vinay Sajip wrote:
> I remembered that I added a feature (with the help of Pawel Jasinski) to
> allow e.g. py -ipy to pick
> a command 'ipy' configured in the .ini file (this is used to launch
> IronPython, but it could be used
> for other things too).
At the time
On 13 February 2015 at 06:59, Thomas Heller wrote:
> To make it clear: My suggestion is (or was, maybe it isn't a good idea)
> to have some way to start 'something' that is in the Scripts
> directory of a Python installation (which is usually a python script
> or an exe-wrapper for it), without ty
On 13 February 2015 at 07:25, Nick Coghlan wrote:
> PEP 441 was aimed at giving the feature more visibility, in addition
> to making appropriately designed archives easier to create (IIRC, my
> main request for that PEP was to change the proposed module name to
> the more prosaic, but also more se
On 13 February 2015 at 09:47, Vinay Sajip wrote:
> I just thought of something ... as far as I know, we've enabled searching for
> a command on the path - since when a venv is active in the sense of
> VIRTUAL_ENV being defined, PATH is also set up so that the venv's Scripts
> folder is on it -
On 13 February 2015 at 10:07, Victor Stinner wrote:
> => IMO the best option is to take the C implementation. What do you think?
FWIW (as I'm not a core dev) I agree. The Windows speedup is huge, and
well worth adding the code. I'm assuming that the majority of the C
code is cross-platform, so we
On 13 February 2015 at 10:15, Glenn Linderman wrote:
> Maybe restricting it to running ".py" files or ".exe" files would be
> reasonable. That covers entry points (which should be the norm for
> newer projects) and Python scripts (which are the most likely things
> to be portable).
>
> The WINDOWS
On 13 February 2015 at 14:27, Steve Dower wrote:
> If py.exe starts defaulting to whatever is on PATH then I don't see the
> point of it. Knowing that you'll get the latest 2.x version by default is
> quite handy (I'd be quite okay changing that to 3.x, though it is specified
> in the original PEP
On 12 February 2015 at 19:44, Paul Moore wrote:
> Impact on Script Launching
> ==
Now that I'm looking into the details of the code for the launcher,
I've noticed that a shebang line of "#!/usr/bin/env python" will first
of all search PATH for a
I'm working on a patch for the Python launcher. I built Python
(current tip, on MS Windows, with VS 2015), and I've just noticed that
hg status shows:
>>hg status -mard
M Doc\using\windows.rst
M PC\launcher.c
M Python\importlib.h
I didn't change importlib.h, and I don't see that the changes I did
On 13 February 2015 at 22:49, Zachary Ware wrote:
> It's strange that
> you're getting modifications, though; I can't reproduce on Linux (and
> don't have quick access to Windows right now). Make sure you're
> definitely at tip, and if it's still changing please open an issue.
Definitely at tip.
I'm looking at putting together a patch for CPython to implement PEP
441. In doing so, there are a few issues that I'd like to raise with
the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
Nick proposed renaming this to "pyzapp", which I like, but it's not a
big deal either way).
On 15 February 2015 at 05:33, Nick Coghlan wrote:
> I'd definitely prefer a simple procedural API like that over offering
> a public stateful object-oriented API, as the latter significantly
> increases testing complexity without offering a sufficiently
> compelling gain in expressiveness to justi
On 15 February 2015 at 08:14, Paul Moore wrote:
> Maybe it would be better to
> put something on PyPI and let it develop outside the stdlib first?
The only place where a ".pyz" file can't easily be manipulated with
the stdlib zipfile module is in writing a shebang lin
On 15 February 2015 at 08:59, Nick Coghlan wrote:
> The other option would to cut PEP 441 way back to *just* be about
> standardising and registering the file associations, and recommending
> the use of pip to obtain the build machinery with (whether pyzaa,
> pyzzer or Twitter's more comprehensive
On 13 February 2015 at 07:02, Nick Coghlan wrote:
> Procedurally, since it's a Windows specific change, and assuming Guido
> doesn't want to pronounce on this one himself, perhaps Steve Dower
> would be an appropriate BDFL-Delegate?
The PEP is now up to date and the patch is on the tracker at
htt
On 15 February 2015 at 13:47, Nick Coghlan wrote:
> Or we just skip the wrapper and make "python -m zipapp" the
> recommended invocation style. Adding a wrapper later is fairly easy,
> but removing it would be difficult.
Fine with me - the wrappers are basically useless on Windows where
Tools/Scr
On 15 February 2015 at 16:00, Serhiy Storchaka wrote:
>> Would it be reasonable to add methods to the
>> ZipFile class to read and write the prefix data?
>
>
> But the stdlib zipfile module supports this.
>
> with open(filename, 'wb') as f:
> f.write(shebang)
> with zipfile.PyZipFile(f, 'a
On 15 February 2015 at 16:15, Petr Viktorin wrote:
> On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote:
>> So the usage would be something like
>>
>> python -m zipapp [options] dir_to_zip
>>
>> Options:
>> -p The interpreter to use on the sheb
On 15 February 2015 at 16:21, Thomas Wouters wrote:
> It might be nice to consider those use-cases in pyzapp as well, especially
> once the glibc feature is released. It requires some fairly big changes to
> zipimport (I ended up rewriting the whole thing) but we can easily
> opensource the code,
On 15 February 2015 at 19:23, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> 2. It would be a nice, although extremely obscure, feature to be able
>> to allow people who want to keep Python off their path to set
>> VIRTUAL_ENV but *not* set PATH, so that
On 15 February 2015 at 21:00, Vinay Sajip wrote:
>> The original PEP said nothing about a PATH search for #!/usr/bin/env
>> python, so I mistakenly assumed there was no way currently to write a
>> script that worked with an activated virtualenv.
>
>
> Actually the path search was added later, by y
On 15 February 2015 at 18:25, Petr Viktorin wrote:
> On POSIXy systems the "python3" symlink is created in all venvs. I
> thought (perhaps naïvely) that Windows doesn't do shebangs natively,
> so there's some Python-specific mechanism around them, which should
> handle "python3".
Windows doesn't
On 16 February 2015 at 16:34, Steve Dower wrote:
>> As far as I know, this is *identical* behaviour to Unix - even to the
>> incredibly
>> annoying (to me) choice of Python 2 as a default. So I reconfigure the
>> default
>> in my personal settings to Python 3. Unix users can do this too (althoug
On 16 February 2015 at 16:42, Paul Moore wrote:
> My point is that on Windows, users typically don't change the
> executable name they use[1], but rather configure the "python" (or
> "py") command to do what they want. So I think that on Windows we
> shou
On 16 February 2015 at 17:00, Mark Young wrote:
> I don't know what anyone else does, but in cases where I have both on my
> windows box, I do use python2(.x) and python3(.y) . If I only have one
> version on the box, I use the generic name of course. (I don't often have
> only one version on my b
sing it. But I thought it would be worth
having a full spec available for people.
PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth ,
Paul Moore
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 M
On 17 February 2015 at 18:44, Barry Warsaw wrote:
> The broader question of pex, pyzaa, etc. is an important one for Python,
> IMHO. Having a standard single-executable distribution story will help Python
> continue to compete on platforms that work beyond the distribution models
> we've come to
On 17 February 2015 at 18:52, Barry Warsaw wrote:
>>So, the options I see:
>>
>>1. Stick with /usr/bin/env python
>>2. No shebang unless -p is specified
>>3. Unix users come up with a solution which is the same as the above
>>for Windows users, but which suits them better.
>
> #2 seems to me to be
On 17 February 2015 at 18:56, Barry Warsaw wrote:
>>The initial draft of this PEP proposed using ``/usr/bin/env python``
>>as the default interpreter.
>
> The other reasonable alternative for a default shebang is sys.executable.
That's instantly non-portable. On my PC, it'd give
C:\Apps\Python34\
On 17 February 2015 at 19:00, Barry Warsaw wrote:
>>It might be nice to consider those use-cases in pyzapp as well, especially
>>once the glibc feature is released. It requires some fairly big changes to
>>zipimport (I ended up rewriting the whole thing) but we can easily
>>opensource the code, if
On 17 February 2015 at 18:44, Barry Warsaw wrote:
> I don't know exactly what the procedure would be to claim .pyz for *nix,
> e.g. updating /etc/mime.types, but I think the PEP should at least mention
> this. I think we want to get as official support for .pyz files on *nix as
> possible.
I'll
On 17 February 2015 at 21:10, Barry Warsaw wrote:
> The actual "import an extension module" support in zipimport does need to be
> cross-platform, but it can work differently depending on the platform. For
> example, if extended-dlopen is available on your Linux machine, zipimport
> could just us
On 17 February 2015 at 21:13, Barry Warsaw wrote:
> Don't discount sys.executable to quickly. :)
I used pyzzer when it defaulted to sys.executable, and the experience
was painful. That's on Windows, and Unix may be different, but let's
just say I don't want to go there :-)
Paul
_
On 17 February 2015 at 21:40, Barry Warsaw wrote:
> OTOH, I think it *would* be useful to have this built into Python. We almost
> have too many choices, and may people I've talked to lately (including
> experienced Pythonistas) have trouble choosing the right tool. But that can
> come later; le
as official support for .pyz files on *nix as
>>> possible.
>
> Paul Moore wrote:
>> I'll add a note to the PEP, but I have no idea how we would even go
>> about that, so that's all I can do, unfortunately.
>
> Are you just looking for
>
>
On 19 February 2015 at 18:11, Jim J. Jewett wrote:
>> Also, I don't think reserving anything is something I, as an
>> individual (and specifically a non-Unix user) should do. It probably
>> should be handled by the PSF, as the process seems to need a contact
>> email address...
>
> Ideally, it wou
The discussion on PEP 486 (started at
https://mail.python.org/pipermail/python-dev/2015-February/138171.html,
following from the thread at
https://mail.python.org/pipermail/python-dev/2015-February/138160.html)
seems to have died down. There's an implementation at
http://bugs.python.org/issue23465.
On 23 February 2015 at 19:47, Guido van Rossum wrote:
> So is the PEP ready for pronouncement or should there be more discussion?
I think Brett's idea is worth incorporating, so let's thrash that out first.
> Also, do you have a BDFL-delegate or do you want me to review it?
No-one has stepped u
On 23 February 2015 at 21:02, Brett Cannon wrote:
>> The real problem with overwriting is if there's a failure during the
>> overwrite you lose the original file. My original API had overwrite as
>> the default, but I think the risk makes that a bad idea.
>
>
> Couldn't you catch the exception, wr
On 23 February 2015 at 21:18, Serhiy Storchaka wrote:
> On 23.02.15 22:51, Paul Moore wrote:
>>
>> BTW, while I was looking at the API, I realised I don't like the order
>> of arguments in pack(). I'm tempted to make it pack(directory,
>> target=None, interp
On 24 February 2015 at 16:30, Brett Cannon wrote:
> Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as
> official as anything will be as the recommended tool to install projects.
> Otherwise easy_install has nothing to do directly with python-dev so I don't
> think we can c
On 24 February 2015 at 17:46, Guido van Rossum wrote:
> I can do it but I don't want to be reviewing and accepting a PEP that's
> still under discussion, and I don't have the bandwidth to follow the
> discussion here -- I can only read the PEP. I will start that now.
I'm just about to push an upd
On 24 February 2015 at 21:09, Ethan Furman wrote:
> Another way to support this is with subcommands. Have the default [implicit]
> command be to create the zip app, and then
> add any subcommands we need:
>
> python -m zipapp [create] foo #creates a foo.pyz from the foo directory
>
> pytho
On 24 February 2015 at 18:58, Guido van Rossum wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?
One possible source of confusion with copy_archive (and i
rchive(archive, new_archive)?
>
>
> Paul Moore wrote:
>> One possible source of confusion with copy_archive (and its command
>> line equivalent "python -m zipapp old.pyz -o new.pyz") is that it
>> isn't technically a copy, as it changes the shebang line (if
On 25 February 2015 at 17:06, Paul Moore wrote:
>> Is the difference between create and copy important? e.g., is there
>> anything wrong with
>>
>> create_archive(old_archive, output=new_archive) working as well as
>> create_archive(directory, archive)?
>
> P
On 25 February 2015 at 20:12, Jim J. Jewett wrote:
> On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote:
>> On 25 February 2015 at 17:06, Paul Moore wrote:
>
>> I've included the resulting API
>> documentation below. It looks pretty good to me.
>
>
.
Paul
PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth ,
Paul Moore
Discussions-To:
https://mail.python.org/pipermail/python-dev/2015-February/138277.html
Status: Draft
Type: Standards Track
Content-Type: text/x-rs
On 26 February 2015 at 17:28, Glenn Linderman wrote:
> * The name of a directory, in which case a new application archive
> will be created from the content of that directory.
> * The name of an existing application archive file, in which case the
> file is copied to the target. The file name
On 26 February 2015 at 18:23, Ethan Furman wrote:
> On 02/26/2015 09:28 AM, Glenn Linderman wrote:
>> On 2/26/2015 9:05 AM, Paul Moore wrote:
>
>>> ``create_archive(source, target=None, interp
On 26 February 2015 at 21:34, Guido van Rossum wrote:
> Accepted!
>
> Thanks for your patience, Paul, and thanks everyone for their feedback.
>
> I know there are still a few small edits to the PEP, but those don't affect
> my acceptance. Congrats!
Excellent, thanks to everyone for the helpful co
On 8 March 2015 at 02:13, Victor Stinner wrote:
> FYI I commited the implementation of os.scandir() written by Ben Hoyt.
> I hope that it will be part of Python 3.5 alpha 2 (Ben just sent the
> final patch today).
Yay! Great news.
Paul
___
Python-Dev ma
On 26 February 2015 at 21:48, Paul Moore wrote:
> On 26 February 2015 at 21:34, Guido van Rossum wrote:
>> Accepted!
>>
>> Thanks for your patience, Paul, and thanks everyone for their feedback.
>>
>> I know there are still a few small edits to the PEP, but th
On 9 March 2015 at 09:34, Larry Hastings wrote:
> On behalf of the Python development community and the Python 3.5 release
> team, I'm thrilled to announce the availability of Python 3.5.0a2. Python
> 3.5.0a2 is the second alpha release of Python 3.5, which will be the next
> major release of Py
Submitted as http://bugs.python.org/issue23619
On 9 March 2015 at 10:20, Paul Moore wrote:
> On 9 March 2015 at 09:34, Larry Hastings wrote:
>> On behalf of the Python development community and the Python 3.5 release
>> team, I'm thrilled to announce the availability of Pyth
I just thought I'd give installing Python 3.5 a go on my PC, now that
3.5a2 has come out. I didn't get very far (see earlier message) but it
prompted me to think about how I'd use it, and what habits I'd need to
change.
I'd suggest that the "what's new in 3.5" document probably needs a
section on
On 9 March 2015 at 13:45, Nick Coghlan wrote:
> I'm happy to let the folks that use Windows for development regularly
> decide on the best answer from a user experience perspective, but I
> think a release blocker docs issue would be a good way to go for
> ensuring it gets resolved be the release
On 9 March 2015 at 16:35, Donald Stufft wrote:
>> I'm okay with this. Installing for all users is really something that could
>> be considered an advanced option rather than the default, especially since
>> the aim (AIUI) of the all-users install is to pretend that Python was
>> shipped with th
On 9 March 2015 at 23:11, Nick Coghlan wrote:
> While I like the idea of offering something more "built in" in this space,
> my initial inclination is to prefer extending "-m" to accept the
> "module.name:function.name" format to let you invoke entry points by the
> name of the target function (Po
On 9 March 2015 at 15:37, Steve Dower wrote:
>> Maybe the answer is that we simply start recommending that everyone on
>> Windows
>> uses per-user installs. It makes little difference to me (beyond the fact
>> that
>> when I want to look at the source of something in the stdlib, the location of
On 11 March 2015 at 17:27, Brett Cannon wrote:
> I'm going to propose a somewhat controversial idea: let's deprecate the
> ctypes module. We now have things like cffi and Cython for people who need
> to interface with C code. Both of those projects are maintained. And they
> are not overly difficu
On 11 March 2015 at 21:45, Maciej Fijalkowski wrote:
>> Is it possible to use cffi without a C compiler/headers as easily than
>> ctypes?
>
> yes, it has two modes, one that does that and the other that does
> extra safety at the cost of a C compiler
So if someone were to propose a practical appr
On 11 March 2015 at 22:33, Maciej Fijalkowski wrote:
> You're missing my point. Ripping off the libffi from CPython is a good
> idea to start with. Maybe deprecating ctypes is *also* a good idea,
> but it's a separate discussion point. It certainly does not solve the
> libffi problem.
OK, so let'
On 12 March 2015 at 17:26, Brett Cannon wrote:
>> I'm all for ditching our 'libffi_msvc' in favor of adding libffi as
>> another 'external' for the Windows build. I have managed to get
>> _ctypes to build on Windows using vanilla libffi sources, prepared
>> using their configure script from withi
On 12 March 2015 at 18:54, Zachary Ware wrote:
> On Thu, Mar 12, 2015 at 12:44 PM, Paul Moore wrote:
>> I'd be willing to contemplate helping out on the Windows side of
>> things, if nobody else steps up (with the proviso that I have little
>> free time, and I'm s
Something that hit me today, which might become a more common issue
when the Windows installers move towards installing to the user
directory, is that there appear to be some bugs in handling of
non-ASCII paths.
Two that I spotted are a failure of the "script wrappers" installed by
pip to work wit
On 22 March 2015 at 19:34, Victor Stinner wrote:
> Please open an issue, I can take a look. Please describe a scenario to
> reproduce the issue.
The "issue" with the launcher seems to have bee a red herring. When I
set up a test case properly, it worked. I suspect I messed up writing
the shebang
On 23 March 2015 at 22:29, Serhiy Storchaka wrote:
>> As a result, explicitly support pathlib.Path objects as arguments.
>> Also added tests for the CLI interface.
>
> Congratulate with your first commit Paul!
Thanks :-)
Paul
___
Python-Dev mailing list
On 12 March 2015 at 17:44, Paul Moore wrote:
> On 12 March 2015 at 17:26, Brett Cannon wrote:
>>> I'm all for ditching our 'libffi_msvc' in favor of adding libffi as
>>> another 'external' for the Windows build. I have managed to get
>>> _
On 25 March 2015 at 08:05, Maciej Fijalkowski wrote:
> Linux crashes. The mechanism for detecting the number of arguments is
> only available on windows (note that this is a band-aid anyway, since
> if your arguments are of the wrong kind you segfault anyway). We do
> have two copies of libffi one
On 25 March 2015 at 09:09, Antoine Pitrou wrote:
> I'm not sure we guarantee anything. In any case, it's only a small
> proportion of the kind of crashes you can get by messing the signature.
Fair point. I guess what I'm asking is, would it be OK to remove the
code that checks for a stack size di
On 3 April 2015 at 10:56, Larry Hastings wrote:
> My Windows development days are firmly behind me. So I don't really have an
> opinion here. So I put it to you, Windows Python developers: do you care
> about GnuPG signatures on Windows-specific files? Or do you not care?
I don't have a very s
On 20 April 2015 at 19:41, Barry Warsaw wrote:
>>tldr; type hints in python source are scary. Would reserving them for stub
>>files be better?
>
> I think so. I think PEP 8 should require stub files for stdlib modules and
> strongly encourage them for 3rd party code.
Agreed. I have many of the s
On 20 April 2015 at 20:35, Łukasz Langa wrote:
> Since it was mentioned in a different e-mail in this thread: yes, the
> standard library is not getting any type annotations. When we decide to
> ship type hints with Python 3.6, they will be added as stubs.
Why is this? Surely this is something
On 21 April 2015 at 13:47, Steven D'Aprano wrote:
> On Tue, Apr 21, 2015 at 11:56:15AM +0100, Rob Cliffe wrote:
>
>> (Adding a type hint that restricted the argument to say a
>> sequence of numbers turns out to be a mistake.
>
> Let's find out how big a mistake it is with an test run.
>
>
On 21 April 2015 at 17:55, Gregory P. Smith wrote:
> I view most of this thread as FUD. The fear is understandable, I'm trying to
> tell people to stop panicing.
I think (hope!) everyone is clear that what's being expressed in this
thread is honest (emotional) reactions. There's a negative connot
(Gmail messed up the attributions - apologies if I didn't fix them up
correctly).
21 April 2015 at 19:55, Łukasz Langa wrote:
>>
>> On Apr 21, 2015, at 11:23 AM, Guido van Rossum wrote:
>>
>>> 2. Clearly, great thought has been put into this PEP. If anyone has a good
>>> analysis of the potenti
On 20 April 2015 at 09:16, Larry Hastings wrote:
> There is now a third type of Windows installer for Python 3.5. In addition
> to the conventional installer and the web-based installer, Python 3.5 now
> has an embeddable installer designed to be run as part of a larger
> application's installer
On 21 April 2015 at 23:05, Steve Dower wrote:
> It is indeed just a run-and-dump extractor. I haven't had a chance to write
> up any docs for it yet, but there are some open bugs I want to fix first
> (specifically http://bugs.python.org/issue23955) before this becomes too
> formalized.
Thanks
On 21 April 2015 at 23:05, Steve Dower wrote:
> I made it a self-extracting RAR file so it could be signed, but I've already
> had multiple people query it so the next release will probably just be a
> plain ZIP file. I just need to figure out some reliable way of validating the
> download othe
On 22 April 2015 at 13:45, Paul Moore wrote:
> On 21 April 2015 at 23:05, Steve Dower wrote:
>> I made it a self-extracting RAR file so it could be signed, but I've already
>> had multiple people query it so the next release will probably just be a
>> plain ZIP file.
On 24 April 2015 at 09:34, Greg Ewing wrote:
> and after the refactoring it becomes
>
>cocall await(cocall f(x))
>
> That doesn't look so bad to me.
I've not been following this discussion (and coroutines make my head
hurt) but this idiom looks like it's bound to result in people getting
the
On 29 April 2015 at 18:43, Jim J. Jewett wrote:
>> Rationale and Goals
>> ===
>>
>> Current Python supports implementing coroutines via generators (PEP
>> 342), further enhanced by the ``yield from`` syntax introduced in PEP
>> 380. This approach has a number of shortcomings:
>>
>>
On 29 April 2015 at 19:32, Ethan Furman wrote:
> On 04/29, Yury Selivanov wrote:
>> On 2015-04-29 1:25 PM, Ethan Furman wrote:
>>> cannot also just work and be the same as the parenthesized
>>> version.
>>
>> Because it does not make any sense.
>
> I obviously don't understand your position that "
On 29 April 2015 at 19:42, Yury Selivanov wrote:
> Here's how it might look like (this is the same pseudo-code
> but tailored for PEP 492, not a real something)
>
> q = asyncio.Queue(maxsize=100)
>
> async def produce():
> # you might want to wrap it all in 'while True'
I think the "loo
On 29 April 2015 at 20:42, Yury Selivanov wrote:
> Everybody is pulling me in a different direction :)
Sorry :-)
> Guido proposed to call them "native coroutines". Some people
> think that "async functions" is a better name. Greg loves
> his "cofunction" term.
If it helps, ignore my opinion -
101 - 200 of 1862 matches
Mail list logo
