Fair enough. Pull request created:
https://github.com/python/cpython/pull/16347
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3
OK - but that's just one I picked at random. There are others like it - what
would be the process for deciding which ones need to be made private and moved?
Should an issue be raised to track this?
Regards,
Vinay Sajip
___
Python-Dev mailing
Ah - I checked, and it's there OK ... (head scratch)
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.pytho
ef. I will
check when I get a chance.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archiv
s it's still
work in progress - which is why I'm asking these questions.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailm
esumably, a PEP would be required, even
though it's an implementation detail from the point of view of the language
itself?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
> Moving some of the especially common identifier references into the
> interpreter state struct may make sense.
> Adding more process globals wouldn't be desirable though, as they're one of
> the more common ways of breaking encapsulation between subinterpreters
> (hence Eric's efforts to eliminat
es this discipline/approach not apply to CPython?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
rget is very important for keeping public API as small as possible.
I'm not suggesting that _Py_IDENTIFIERs become part of the public API. Surely
it's not the case that any and every extern identifier becomes part of the
public API? (I know people can misuse things and use unsuppo
ule? After all, they seem for the most part to be well-known
constant strings that don't need to be encapsulated in any particular C
compilation unit.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
r, by you! See [1] and [2].
Regards,
Vinay Sajip
[1] http://bugs.python.org/issue17903
[2]
https://bitbucket.org/pmoore/pylauncher/commits/87d41c5a8f0fef5ef22f09570903e7aa4c850e96
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
won't be hit (though if you rely on the
PATH being correctly set, then it will work as expected because the handling
for e.g. /usr/bin/env python searches the PATH).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
https:/
- Original Message -
From: Paul Moore
> I'd also appreciate your views on the spin-off thread and PEP 486
> ("Make the Python Launcher aware of virtual environments").
I just thought of something ... as far as I know, we've enabled searching for a
command on the path - since when a v
nd I haven't looked into it yet; I just skimmed the differences, and
didn't see anything major in launcher.c (I compared with the version in the
default branch of cpython).
Regards,
Vinay Sajip
[1] https://bitbucket.org/vinay.sajip/pylauncher
__
remember - he made some
helpful suggestions to improve it) which does a similar job to PEP 441's pyzaa
and provides improved Windows support (some of which might be supplanted by
py.exe support for .pyz/.pyzw, but I have cases where I can't rely on py.e
- Original Message -
From: Steve Dower
> I believe are the purpose of those extensions. If "py.exe spam.pyz"
> already works, I don't see any need for a PEP to add the association in
> the installer.
That would be my view, too
lled, the user
gets a chance to associate file extensions with one of the installed Pythons
found on the system).
Off to read the whole thread on python-dev now ...
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
Sorry, my mistake - I should have checked more carefully. Thank you for
pointing me to the commit where they were removed - I'll install a venv with
Sphinx, revert the change and remove those files from my repo.
Regards,
Vinay Sajip
From: Benjamin Pet
Oleg Broytman phdru.name> writes:
>
> On Mon, Jun 17, 2013 at 06:37:49PM +0000, Vinay Sajip
yahoo.co.uk> wrote:
> > echo off
> > __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())"
>
>I think you want to pass command line arguments:
>
.cli())"
should do it.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
both 3.3 and 3.4, as it's
not a change in core Python APIs.
In the absence of adverse feedback here, I propose to implement approach #2
on both 3.3 and 3.4.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
how to do it... I've created a pull request
> against the pypa version in case that's of use...
Hi Paul,
Sorry I haven't had a chance yet - real life is very busy at the moment. A pull
request against the pypa version is fine, and I will get to it soo
Paul Moore gmail.com> writes:
> PS Vinay - from this post, I assume you're already looking at this
> code? I was considering trying to put together a patch, but I don't want to
> duplicate effort if you're working on it.
I've taken a quick look at it, but I probably won't be able to make any
cha
itched on only in the presence of e.g. an environment variable
such as PYLAUNCH_SEARCHPATH, or should we just change the default behaviour
now and risk breaking user scripts which may rely on the current behaviour?
Regards,
Vinay Sajip
___
Python-Dev ma
use pdb can now read the source code from the
> zip.
Well, it's just an experiment, and I was soliciting comments because I'm not as
familiar with the issues as some others are. Distlib is still only at version
0.1.1, and the mount()/unmount() functionality is not set in
but I don't
> see a compelling reason for adding complexity here. It's not really an
> important use case.
Well, my post was to elicit some comment about the usefulness of the feature,
so fair enough. It doesn't seem especially complex though,
aise an ImportError? Or ignore
the wheel - seems wrong? Or do something else?)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
27;, '__loader__', '__name__', '__package__',
'encode_basestring_ascii', 'make_encoder', 'make_scanner', 'scanstring']
>>> simplejson._speedups.__file__
'/home/vinay/.distlib/dylib-cache/simplejson/_speedups.so'
&g
you add a Misc/NEWS entry for the change / bugfix?
Ok, will do.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
voids this issue somehow.
One example of a non-system-wide installation is a source build of Python.
PEP 405 venvs created from a source build should work in the same way as venvs
created using an installed Python.
Regards,
Vinay Sajip
___
Python-D
-
breaker, but it does mean that you can't e.g. use the ast module in the
implementation. This might be a factor if the mini-language ever grows (as it
recently did, adding parentheses).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@p
ly, distlib runs on Python 2.6, 2.7 and 3.2+, so there shouldn't be any
concerns about support on those older Python versions.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
n't think that the distlib docs suffer
inordinately from being on readthedocs.org - for one thing, I've enabled Disqus
comments, allowing feedback on the docs - not that I've had any ;-)
Closer integration should perhaps happen, but not until the projec
(0.7.3) [for pyramid]
download zope.deprecation (4.0.2) [for pyramid]
download pyramid (1.4)
In the above, nothing was actually downloaded except the metadata. It's just
indicating an intuitive ordering for download based on a topological sort of
the dependency graph - for pyramid,
David Cournapeau gmail.com> writes:
> You are putting the words out of the context in which those were
> written: it is stated that the focus is on the general architecture
OK, no offence was meant. Thanks for the clarification.
Regards,
Vi
David
is just being self-deprecating, but what if he isn't? Or perhaps that part of
the page is out of date, and needs updating? I can certainly agree with the
"Weak documentation" part of the assessment, but this makes it hard to assess
the package as a whole. Note that I'm not s
27;t have
the ability to build pure-Python distributions and distributions including C
libs and extensions, with the ability to extend easily by third-party tools. It
just needs to be done in a way which is easy to build on, so the included
battery stays small and simple. Easier said than done, I k
ed that distutils2/packaging also failed to make
sufficient progress for the same reason.
Certainly, with distlib I've tried to incorporate a lot of the setuptools
functionality which developers find useful - in-package data, package exports
(entry points), wrapping callables with scripts and
t supported by PEPs, hence the interest in getting the 3
> wheel PEPs (of which the metadata PEP is the first) accepted.
Likewise, I will look at the possibility of providing wheel support in distlib,
once it has been accepted as a standard and the open issues (such as signature
scheme) have been
xample where fds other than
0, 1 and 2 might be used by design in not-uncommonly-used programs. From a
discussion I had with Barry Warsaw a while ago, I seem to remember that there
was other software which relied on these features. See [1] for details.
Regards,
Vinay
s additional
parameters to GnuPG, and they might use these esoteric GnuPG options.
Regards,
Vinay Sajip
[1]
http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Christian Tismer stackless.com> writes:
> Anything I'm missing here?
The use case was missed during PEP and patch review, so the feature didn't make
it into 3.3. Issue #15776 raised the problem; it has been resolved and the
feature should appear in Python 3.4.
Regar
:O
Actually the BitBucket repo is more active and readthedocs has the latest docs,
but I do periodically update the above repo on hg.python.org.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
t is
intended to be possible to build packaging systems on top of it. Compared to
distutils2, distlib aims to make it easier to transition from existing
packaging infrastructure and tools (distutils, setuptools/distribute).
Some of the PEPs are still in flux
16K, due to the possible presence of a pathologically
large comment in the end record.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
read the file contents.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
, this data is not considered reliable - for example, pip runs
egg_info on downloaded packages to get updated information when determining
dependencies to be downloaded. If the Requires-Dist info in PKG-INFO can't be
relied on, surely less critical information such as Obso
what,
whereas with Python distributions, there's no central authority that has this
function?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
n X.Y? I take it we're entirely comfortable with installing
setuptools X.Y in that case? How would you ensure the right setuptools is
always loaded, since presumably both are on sys.path?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-D
missing from the package
> index based purely on the distribution names.
In which case, it seems sensible to put these constraints into the PEP,
so that both PEP implementers and users of those implementations have these
guidelines clarified.
Regards,
Vinay Sajip
___
lues in Provides-Dist? If they are
e.g. a bundled SQLAlchemy, why would that be preferable to an entry in
Requires-Dist?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
support for the multi-valued "Provides", but I'm
not confident that will work as expected given pathological cases like the
example I suggested, without getting "complicated" in the Zen of Python sense.
I'm not convinced that the maintenance burden of a complicated solu
Eli Bendersky gmail.com> writes:
> Use pss [http://pypi.python.org/pypi/pss]
How does it compare with grin? [http://pypi.python.org/pypi/grin]
On the face of it, they both do the same job.
Regards,
Vinay Sajip
___
Python-Dev mailing list
uilt Python 3.4. Ned's post showed me why.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
bin/python2.7
Aha! Thanks for pointing that out.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
f I clean the default repo and re-run make, it fails at the
ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
able to invoke $HOME/projects/python/default/python.
Is this a bug in configure, or is my configuration regarded as too perverse to
s
nd
what shouldn't be.
ISTM there is a space for a limited evaluator that's less limiting than
literal_eval(). I do realise that this type of sandboxing is not easy to
achieve,
and I'm not aiming to advance the state of the art here - I just want to close
the iss
r callback to be specified
- is sufficient to allay the concerns that led to the issue being raised in the
first place. In which case, I can close the issue without committing this patch.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python
larly as there may be security
implications (the issue is titled "Improve the security model for logging
listener").
Barring objections, I plan to commit it in a week or so.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@
de is already in the distutils2.install_distinfo.install_distinfo.run()
method. I'll pull it out into such a method.
Anyone else, do chip in if you think this is insufficient or sub-optimal.
Perhaps these discussions (on the detail) should continue on distutils-sig. I'll
post there when I&#x
Antoine Pitrou pitrou.net> writes:
> On the other hand, if you are not using hg.python.org features such as
> commits e-mails or buildbots, it's also fine living on bitbucket until
> the project matures a bit.
>
I'm fine with tha
iles in there - a Makefile, configure script and some
.bat files.
I tried cloning it but I'm not allowed to create a repo at the top level - it
says
Please use a secondary level path such as "sandbox/distlib"
Seems a shame not to make it a top-le
Tarek Ziadé ziade.org> writes:
> > Regards,
> oh, cool !
>
> maybe we could copy it at hg.python.org ?
>
Sure, but I don't know if I can do it. IIUC it needs someone with an account on
the server to create new repositori
n dependency graph logic
glob.py - globbing functionality
The code was taken at around the time packaging was removed, and may not have
more recent changes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
work on the venv code was done
using a clone from this mirror, and I pulled and merged from it lots of times
without any issues.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
eme position in order to suggest that
there might be problems with its basic design.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
and fall into oblivion.
Quite possibly, but that'll be the chicken-and-egg thing I mentioned. Some
projects can be worked on in comparative isolation; other things, like
packaging, need inputs from a wider range of people to gain the necessary
credibility.
Regards,
Vinay Sajip
stutils' way of
fulfilling those needs is too fragile - else, why do you need things like Bento?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
ment work to date, but it
seems the net needs to be spread even wider to ensure that all constituencies
are represented (for example, features needed only on Windows, such as binary
distributions and executable scripts, have lagged a little bit behind).
Regards,
Vinay Sajip
racks. The basic low-level
building blocks like versioning, metadata and markers should be fine, but I'm
not convinced that the command-class paradigm is appropriate in this case. The
whole intricate "initialize_options"/"finalize_options"/"set_undefined
v.loewis.de> writes:
>
> See above. Also notice that such signing is already implemented, as part
> of PEP 381.
>
BTW, I notice that the certificate for https://pypi.python.org/ expired a week
ago ...
Regards,
Vinay Sajip
___
Pyt
mething like that in an earlier message).
> I do have concerns about making signed code mandatory. (Not least over
> whether it'd let me install my own unsigned code!)
Any workable mechanism would need to be optional (the user doing the installing
would be the decider as to whethe
have allowed backdoors, etc. I don't see that it mandates use of
SSL, or even signing, by anyone. At least some people will require that an
installer be invokable with an option that causes it to bail if any part of
what's being installed can't be verifie
enough on Posix platforms, perhaps, but what about Windows? One can't
expect a C compiler to be installed everywhere. Perhaps security against
backdoors could also be provided through other mechanisms, such as signing of
binary installers.
Regards,
Vinay Sajip
___
unication between hooks
and code reuse between hooks. I don't see any drawback to using only one file ?
I was assuming that the dist.yaml file would just have callable references here;
I suppose having (sizable) Python fragments in dist.yaml might become unwieldy.
Nick Coghlan gmail.com> writes:
> ini-style is often good enough, and failing that there's json. Or, you
> just depend on PyYAML :)
Except when PyYAML is packaged and distributed using dist.yaml :-)
Regards,
Vinay Sajip
___
Python-De
format for review/edit,
though.
+1 to the overall approach suggested, it makes a lot of sense. Simple is better
than complex, and all that :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tuptools doesn't seem to
be something to bet the future on. As an infrastructure concern, this area of
functionality definitely needs to be supported in the stdlib, even if it's a
painful process getting there. The barriers seem more social than technical, but
hopefully the divide-and-co
Antoine Pitrou pitrou.net> writes:
>
> Deciding to remove packaging from 3.3 is another instance of the same
> mistake, IMO.
>
What's the rationale for leaving it in, when it's known to be
incomplete/unfinished?
Regards,
Vinay Sajip
_
he stock
launcher; any script installed by packaging (or setuptools/Distribute) in a venv
should have the correct shebang line, and the PEP 397 launcher should do the
right thing.
I'm sorry for all the confusion I've caused here :-(
Regards,
Vinay Sajip
__
separately.
There's nothing in there related to #12394 - just a pysetup3.exe file, which I
had originally overlooked and have now removed.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
n 01381723bc50 - the
.exe is gone.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ackaging. If people
generally feel strongly about this, I can delete the .exe and re-introduce it
later if/when appropriate. It might have had a few rough edges, but I wouldn't
have characterised the patch as "half-finished" - that seems a littl
ight now? It will need
integrating with the existing VS2010 solution file, and at the moment I cannot
do that integration because I haven't yet got a full VS2010 build environment,
just a VS2008 one.
Regards,
Vinay Sajip
___
Python-Dev mailin
Python 3.3.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
week since I'm on vacation for one week
> from June 2nd.
It's now implemented in the default branch :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
week since I'm on vacation for one week
> from June 2nd.
I believe it is ready to integrate now. I aim to do it tomorrow (26 May) a.m.
UTC, so that it can make the next alpha.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Pyt
e.g. for issue
http://bugs.python.org/issue1521950
Is it something I'm doing wrong, or is there a problem with the issue
tracker/Rietveld integration?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
nt.
Agreed it's not essential, but it also provides some useful information about
the version (for a user, rather than the update script) without actually having
to invoke the interpreter to check.
Regards,
Vinay Sajip
___
Python-Dev mail
ironment variable,
__PYTHONV_LAUNCHER__, which points to itself, before it execs the real Python.
On OS X, Python code checks for this, rather than sys.executable, to determine
the location of the pyvenv.cfg file. This seems to work for me (Ned Deily is
looking into it more closely, I believe).
Rega
you to have an isolated set of library
dependencies for a project.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/
tool will need to only update environments which were
set up with the particular version of Python which was updated. ISTM pyvenv.cfg
will need to have a version=X.Y.Z line in it, which is added during venv
creation. That information will be used by the tool to only update specific
environments.
or now, and see where the other failures lead me
to.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
table's path, and try with that.
I would prefer to use option 2 and change getpath.c / getpathp.c accordingly.
Does anyone here see problems with that approach?
Regards,
Vinay Sajip
[1] http://stackoverflow.com/a/933996
___
Python-Dev m
ndows utilities) has trouble.
>
> Not sure if that makes a difference or not.
It's only really an issue for new / inexperienced users, I agree. Since these
files are installed only on Windows systems, there's no reason for them not to
have the native
hem. Can anyone please let me know if they object? Otherwise I'll
go ahead and add them to .hgeol in the next hour or so.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
#x27;
The trailing space later causes a mismatch with the end tag, and leads to the
errors. Django's use of the tagfind pattern is in a subclass of HTMLParser, in
an overridden parse_startag method.
Do we need to indicate more strongly that data like tagfind are private? Or has
the change
omments would be appreciated.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
meant to be overridden and so not private).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ed as objectionable.
Regards,
Vinay Sajip
[1] http://bugs.python.org/issue14452
[2] http://bugs.python.org/issue7077
[3] http://bugs.python.org/issue8795
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
1 - 100 of 437 matches
Mail list logo
