Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon br...@python.org wrote:
My notes from the session I led:
+ argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
I think they were all related to deprecation of optparse, not anything
On Sun, Feb 21, 2010 at 4:30 AM, Eric Smith e...@trueblade.com wrote:
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon br...@python.org wrote:
My notes from the session I led:
+ argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
On 21/02/2010 08:45, Guido van Rossum wrote:
On Sun, Feb 21, 2010 at 4:30 AM, Eric Smithe...@trueblade.com wrote:
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannonbr...@python.org wrote:
My notes from the session I led:
+ argparse
- Same issues
Guido Maybe the best thing is to make optparse *silently* deprecated,
Guido with a big hint at the top of its documentation telling new users
Guido to use argparse instead, but otherwise leaving it in indefinitely
Guido for the benefit of the many existing users.
Would a 2to3
2010/2/21 s...@pobox.com:
Guido Maybe the best thing is to make optparse *silently* deprecated,
Guido with a big hint at the top of its documentation telling new users
Guido to use argparse instead, but otherwise leaving it in indefinitely
Guido for the benefit of the many
Ian Bicking wrote:
This is a proto-proposal for including some functionality from
virtualenv in Python itself. I'm not entirely confident about what
I'm proposing, so it's not really PEP-ready, but I wanted to get
feedback...
First, a bit about how virtualenv works (this will use Linux
Hey folks,
I'm going to write a PEP for inclusion of lib3to2 in the standard library
for 3.2 and above. Before do, though, do people have any quick thoughts
about it?
My inclination is to get it stabilized beforehand (perhaps during another
GSoC) by fleshing out the fixer that warns about
What would be the advantage of having it in the stdlib? It would put a
stop on further development once it's been released as such, which
strike me as a bad idea for a heuristic tool like 3to2. I would expect
that you will continue to add more rules (and more exceptions) to it
for the foreseeable
Thanks all for the updates. Sorry I can't make it to PyCon this year!
On Sun, Feb 21, 2010 at 1:30 AM, Eric Smith e...@trueblade.com wrote:
There was also a quick discussion on maybe implementing optparse using
argparse, then getting rid of the existing optparse.
I think the PEP pretty much
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
steven.beth...@gmail.com wrote:
On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum gu...@python.org wrote:
Maybe the best thing is to make optparse *silently* deprecated, with a
big hint at the top of its documentation telling new users to use
Joe Amenta wrote:
Hey folks,
I'm going to write a PEP for inclusion of lib3to2 in the standard
library for 3.2 and above. Before do, though, do people have any quick
thoughts about it?
I do: it seems too early to me. Before it is added, I'd like a see a
significant success story of its
On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings la...@hastings.org wrote:
* I'd rather ~/env/bin/python be a symlink instead of copying it.
The thread discussing Windows suggests that we shouldn't use symlinks
there. I'd say either copying or symlinking pythonv should be supported,
and
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.beth...@gmail.com
wrote:
So basically do what the PEP does now, except don't remove optparse in
Python 3.5? For reference, the current proposal is:
* Python
On Sun, Feb 21, 2010 at 13:31, Guido van Rossum gu...@python.org wrote:
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
steven.beth...@gmail.com wrote:
On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum gu...@python.org
wrote:
Maybe the best thing is to make optparse *silently* deprecated,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory P. Smith wrote:
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby p...@telecommunity.com wrote:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks, and
where things generally work
Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a
DeprecationWarning would only pop up if developers exposed
DeprecationWarning. But if the module is not about to be removed in 3.x
then I think regardless of the silence of both warnings it should stay
On Sun, Feb 21, 2010 at 14:46, Eric Smith e...@trueblade.com wrote:
Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a
DeprecationWarning would only pop up if developers exposed
DeprecationWarning. But if the module is not about to be removed in 3.x then
Hey Dirkjan,
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej and I would like
to move the benchmark suite out of Unladen Swallow and into
python.org, where all implementations can share it and contribute to
it. PyPy has been
Hi Collin (and others),
On Sun, Feb 21, 2010 at 15:28, Collin Winter collinwin...@google.com wrote:
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej and I would like
to move the benchmark suite out of Unladen Swallow and into
On Sun, Feb 21, 2010 at 3:31 PM, Dirkjan Ochtman djc.ocht...@gmail.com wrote:
Hi Collin (and others),
On Sun, Feb 21, 2010 at 15:28, Collin Winter collinwin...@google.com wrote:
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej
Ian Bicking wrote:
On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings la...@hastings.org
mailto:la...@hastings.org wrote:
* Override sys.prefix: allow you to put the binary in someplace other
than, say, ~/env/bin/python and still support an environment in
~/env/. Also the use case of looking
On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote:
+1 for having the conf file in the same directory as the pythonv
esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind
of antithetical to the spirit of FHS anyway).
Which is okay, right? because virtualenv is really about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote:
+1 for having the conf file in the same directory as the pythonv
esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind
of antithetical to the spirit of FHS
On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter collinwin...@google.comwrote:
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej and I would like
to move the benchmark suite out of Unladen Swallow and into
python.org, where all
Hello.
We probably also need some people, besides CPython devs having some
access to it (like me).
Cheers,
fijal
On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter collinwin...@google.com
wrote:
Would it be
On Sun, Feb 21, 2010 at 21:31, Maciej Fijalkowski fij...@gmail.com wrote:
We probably also need some people, besides CPython devs having some
access to it (like me).
Right. I've setup a public repository on hg.python.org:
http://hg.python.org/benchmarks/
Right now, I still need to have Martin
Hey Daniel,
On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter collinwin...@google.com
wrote:
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks?
Hello Dirkjan,
We are going to start working on a few things in Distutils at Pycon
outside the trunk.
I was about to start this work in the svn sandbox, but if possible I'd
rather have a repo at hg.python.org as well
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé ziade.ta...@gmail.com wrote:
We are going to start working on a few things in Distutils at Pycon
outside the trunk.
This would be full branch of Python? In that case, we probably don't
want to go there yet, because the hashes of the python repository
On Sun, Feb 21, 2010 at 9:47 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé ziade.ta...@gmail.com wrote:
We are going to start working on a few things in Distutils at Pycon
outside the trunk.
This would be full branch of Python? In that case, we
2010/2/21 Dirkjan Ochtman djc.ocht...@gmail.com:
Right. I've setup a public repository on hg.python.org:
I think we should probably develop a policy about hg.python.org repos
before we start handing them out. Who will be able to have a repo on
hg.python.org? What kinds of projects?
--
On Sun, Feb 21, 2010 at 22:21, Benjamin Peterson benja...@python.org wrote:
I think we should probably develop a policy about hg.python.org repos
before we start handing them out. Who will be able to have a repo on
hg.python.org? What kinds of projects?
I'd be happy to host stuff for people
2010/2/21 Dirkjan Ochtman dirk...@ochtman.nl:
On Sun, Feb 21, 2010 at 22:21, Benjamin Peterson benja...@python.org wrote:
I think we should probably develop a policy about hg.python.org repos
before we start handing them out. Who will be able to have a repo on
hg.python.org? What kinds of
On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé ziade.ta...@gmail.com wrote:
No that would be just a new fresh empty repository for distutils 2
that will be developed outside the Python stdlib for a while, and will
enventually get back into it when it's ready I guess.
I figured it would be easier
On Sun, Feb 21, 2010 at 10:54 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé ziade.ta...@gmail.com wrote:
No that would be just a new fresh empty repository for distutils 2
that will be developed outside the Python stdlib for a while, and will
I believe Brett mentioned the 'languishing' status for the tracker in
passing in his notes from the language summit.
To expand on this: the desire for this arises from the observation
that we have a lot of bugs in the tracker that we don't want to close,
because they are real bugs or non-crazy
Larry Hastings:
But IIUC telling the compiler how to
do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to
support any environment variable containing an include /path/.
The INCLUDE environment variable is a list of ';' separated paths
37 matches
Mail list logo
