I know I'm bike-shedding here, but my preference for extension would be
'.pye' as it indicates something to execute, but without indicating
exactly how (i.e. that it's via a separate launcher executable).
.pyx
that said, both .pye and .pyx are superior to .pyl (is that last
character an
.pyx
that said, both .pye and .pyx are superior to .pyl (is that last
character an ell, an eye or a one?)
I agree that .pyl is less readable/more confusable.
We can't use .pyx, though, as that is already used in the Python ecosystem for
Pyrex files (a forerunner of Cython).
Regards,
On 13 August 2013 23:30, Chris Barker - NOAA Federal
chris.bar...@noaa.govwrote:
On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
3) I'd rather not have to mess with PATHEXT, and I particularly don't
want to have to tell my students to do it -- environment variables
Jason R. Coombs jaraco at jaraco.com writes:
This means that instead of installing, for example:
Scripts\my-command.exe
Scripts\my-command-script.py
Scripts\my-command.exe.manifest
Just to muddy the waters a little, I'd like to suggest an alternative
approach which doesn't appear
On 13 August 2013 20:58, Paul Moore p.f.mo...@gmail.com wrote:
On 13 August 2013 18:08, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote:
On another point you mention, Cygwin Python should be using Unix-style
shell
script
On Wed, Aug 14, 2013 at 7:34 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Jason R. Coombs jaraco at jaraco.com writes:
This means that instead of installing, for example:
Scripts\my-command.exe
Scripts\my-command-script.py
Scripts\my-command.exe.manifest
Just to muddy the waters
On 14 August 2013 12:42, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I do think, as I said before, that this needs some sort of policy-type
PEP on the standard approach for wrapping scripts, with all the pros and
cons of the various approaches documented and reviewed.
There have been
On 14 August 2013 13:57, PJ Eby p...@telecommunity.com wrote:
Thoughts?
Writing the script.py file means the current user needs write access
to a program installation directory, which is probably not a good
idea. Also, what if two instances are running, or you overwrite an
existing script
Better suggestion: just append a PEP 441 .pyz to the .exe, and no
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
For bonus points, you can actually stick a compatibly-built wheel on
the end of the .exe instead, and
On 14 August 2013 09:58, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Better suggestion: just append a PEP 441 .pyz to the .exe, and no
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
For bonus points, you can
I spent last weekend at Flock to Fedora, mostly due to my day job
working on the Beaker integration testing system
(http://beaker-project.org) for Red Hat, but also to talk to folks
about Fedora and Python interactions.
A completely unexpected discovery over the weekend, was that some of
the RPM
On 14 August 2013 14:48, Paul Moore p.f.mo...@gmail.com wrote:
But I do see your point regarding things like subprocess. It's a shame, but
anything other than exes do seem to be second class citizens on Windows.
BTW, you mention bat files - it bugs me endlessly that bat files seem to
have a
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
I spent last weekend at Flock to Fedora, mostly due to my day job
working on the Beaker integration testing system
(http://beaker-project.org) for Red Hat, but also to talk to folks
about Fedora and Python interactions.
On Wed, Aug 14, 2013 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
I meant that it has a #! line before the zip part, so that the
launcher knows what Python to
I'm wondering if PEP440 should recommend how to version forks? It's fairly
common to fork dependencies temporarily until the change can be released
upstream.
Ideally, you want to version a fork (and keep the same name) so that it
fulfills the requirement, but be obvious that it's a fork.
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
* group - name of the export group to hook
* preupdate - export to call prior to installing/updating/removing a
distribution that exports this export group
* postupdate - export to call after installing/updating/removing
I'm noticing the mention of forks in PEP426 for provides.
so theoretically, `pkg_resources.WorkingSet.resolve` would be updated at
some point to account for provides in PEP426, and this feature would be
surfaced as a setup keyword for users to use in their fork projects.
On Wed, Aug 14, 2013 at
On 14 August 2013 16:49, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
To give an example of where these subprocess issues might matter.
sphinx auto-generates Makefiles that call 'sphinx-build' with no
extension. The sphinx-build command has a setuptools .exe wrapper so
that it will be
On 14 August 2013 18:46, PJ Eby p...@telecommunity.com wrote:
Shouldn't naming the file .pyw already work today for that case?
Certainly, the .pyw extension is already suitable for manually
creating GUI scripts in a text editor. Unless there's something
special about how the 'pythonw'
Distros actually need to do this fairly regularly for security patches
and packaging tweaks, so it may be a good idea. I think local updates
were one of the intended uses for post-releases, but that doesn't work
if upstream is also using that suffix (and we know some projects do).
*If* this was
*If* this was added to the PEP, I would add it as a new optional
.localN suffix, with a recommendation that public index servers MUST
disallow use of local numbering, since it is intended for downstream
integrators to indicate the inclusion of additional changes relative
to the upstream
On 14 August 2013 14:00, PJ Eby p...@telecommunity.com wrote:
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
* group - name of the export group to hook
* preupdate - export to call prior to installing/updating/removing a
distribution that exports this export group
*
On 14 August 2013 15:07, Marcus Smith qwc...@gmail.com wrote:
*If* this was added to the PEP, I would add it as a new optional
.localN suffix, with a recommendation that public index servers MUST
disallow use of local numbering, since it is intended for downstream
integrators to indicate the
On Wed, Aug 14, 2013 at 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 August 2013 14:00, PJ Eby p...@telecommunity.com wrote:
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
* group - name of the export group to hook
* preupdate - export to call prior to
On Wed, Aug 14, 2013 at 2:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
.pyw files can be imported as modules, just like .py,
Darn. Okay, so another extension *is* needed if you want to be able
to make non-console apps runnable-but-not-importable. IIUC it should
by '.pywa' rather than '.pya',
On Fri, Aug 9, 2013 at 12:46 PM, PJ Eby p...@telecommunity.com wrote:
update the download links whenever a new version is released. Note,
too, that unless there is a specific download for the Python binding
that uses setup.py to invoke its build process, a PyPI listing won't
make the binding
Hello everyone,
We now have a demonstration of pip that securely and efficiently
downloads with TUF any package from a PyPI mirror:
https://github.com/theupdateframework/pip/wiki/pip-over-TUF
We hope that you will try our demonstration with your favourite packages
and tell us about any
PJ Eby pje at telecommunity.com writes:
The build system *should* reserve at least one (subdivisible)
namespace for itself, and use that mechanism for its own extension,
+1 - dog-food :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist -
28 matches
Mail list logo
