I've read the Python-committers thread Pulling from contributors
repositories, which is about version control system. It seems there are
two main issues, linear (cleaner) history on pushing, and NEWS merging.
I'm newby of bazaar, but it seems to have a solution for first issue.
$ bzr checkout
Le dimanche 12 juin 2011 à 10:27 -0700, Raymond Hettinger a écrit :
I do suggest that you publish your code as a third-party module
to make the optional available and to validate whether there
is any real interest in this.
See the Hachoir project: it is a lazy parser supporting sub-structures
Back in March this year, Carl Meyer did some work to see if it was feasible
to bring virtualenv functionality into Python [1] (code at [2]).
Carl's changes were to Python code only, which was almost but not quite enough.
I built on his changes with updates to C code in getpath.c/getpathp.c, and
On 13/06/2011 12:47, Vinay Sajip wrote:
Back in March this year, Carl Meyer did some work to see if it was feasible
to bring virtualenv functionality into Python [1] (code at [2]).
Carl's changes were to Python code only, which was almost but not quite enough.
I built on his changes with
On Mon, Jun 13, 2011 at 9:55 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Virtual environments are phenomenally useful, so I would support having the
full tool in the standard library, but it does raise maintenance and
development issues.
Don't forget windows support! ;-)
Given that it
Michael Foord fuzzyman at voidspace.org.uk writes:
It would certainly need a PEP.
Of course.
There are two options:
Bring the full functionality into the standard library so that Python
supports virtual environments out of the box. As is the case with adding
anything to the standard
Nick Coghlan ncoghlan at gmail.com writes:
Given that it is desirable for tools like virtualenv to support *old*
versions of Python on *new* versions of operating systems, it seems to
me that there is an inherent element of their feature set that makes
including the whole tool questionable.
On Mon, 13 Jun 2011 11:47:33 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
$ python3.3 -m virtualize /tmp/venv
$ source /tmp/venv/bin/activate.sh
$ pysetup3 install Mako
and so on. A log of early experiments, which seems reasonably promising, is at
[4].
Do people agree that it
On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
As a side-note, I think calling it virtualization is a recipe for
confusion.
Indeed, OS level virtualisation pretty much has a lock on that term.
virtual environments skates close to it but manages to avoid it well
On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
You're right in terms of the current Python ecosystem and 3.x adoption,
because
of course this approach requires support from Python itself in terms of its
site.py code. However, virtual environments have a utility
On Mon, Jun 13, 2011 at 10:22 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Michael Foord fuzzyman at voidspace.org.uk writes:
Don't forget windows support!
I haven't. Though I haven't tested the most recent changes on Windows yet, I
have tested the basic approach under Windows (the code
Nick Coghlan ncoghlan at gmail.com writes:
You should be able to use symlinks even on Windows these days
(although granted they won't on portable media that uses a non-symlink
friendly filesystem, regardless of OS).
Plus I'm not sure Windows XP supports true symlinks - I think you have to
On Mon, Jun 13, 2011 at 08:42, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
You should be able to use symlinks even on Windows these days
(although granted they won't on portable media that uses a non-symlink
friendly filesystem, regardless of OS).
Nick Coghlan ncoghlan at gmail.com writes:
On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou solipsis at pitrou.net
wrote:
As a side-note, I think calling it virtualization is a recipe for
confusion.
Indeed, OS level virtualisation pretty much has a lock on that term.
virtual
On Jun 13, 2011, at 11:47 AM, Vinay Sajip wrote:
Do people agree that it may be fitting, proper and timely to bring
virtualisation into Python, and are there any fundamental flaws anyone can see
with the approach used?
Yes, absolutely. We'll hash out the details when the PEP is published, and
Barry Warsaw barry at python.org writes:
Question: how hard would it be to backport the work you've done to Python 3.2?
Obviously I'm not saying it should be ported to the official 3.2 branch, but
if *someone* were interested in doing so, would it be possible? Sounds like
you can almost get
On Sun, 2011-06-12 at 15:37 -0500, Benjamin Peterson wrote:
If no one is using it, I'd like to delete it. I also don't think we
should be in business of distributing distribution specific files.
FWIW, Fedora and RHEL don't use this particular .spec file; we roll our
own.
I can't speak for all
Jiawei Li jiawei.h.li at gmail.com writes:
For example, the logging module is not very useful right now, as it requires
sprinkling small one-liners all over my code - not exactly ideal.
Why not take a page from aspect-oriented programming and allow for injection
of code with point cuts?
If
On Jun 13, 2011, at 04:00 PM, Vinay Sajip wrote:
My Debian-packaging-fu is not that good, I'm afraid, so there's no branch for
the .deb, as such. I made the package by running make and then
sudo checkinstall -D --fstrans=no
which takes forever (God knows why - it's many many minutes at 100%
Hi,
Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu
Bosu, University of Alabama, and Dr. Lorin Hochstein, University of
Southern California, are conducting a survey of open-source software
developers. This survey seeks to understand how developers on distributed,
virtual
Barry Warsaw barry at python.org writes:
Ah, no I don't think that'll be helpful. I can probably reuse the python3.3
packaging stuff to do a PPA.
Okay, go for it! Is there a specific tutorial somewhere about making a PPA for
Python? (As opposed to more generalised tutorials - or would they be
I disagree. We certainly include PCbuild/*.vcproj, and Tools/msi,
which are also distribution-specific. Likewise, we have plenty
of OSX-specific files (including special-casing for specific releases
thereof).
I should qualify: We shouldn't distribute distribution-specific files
for which
Am 13.06.2011 18:21, schrieb David Malcolm:
On Sun, 2011-06-12 at 15:37 -0500, Benjamin Peterson wrote:
If no one is using it, I'd like to delete it. I also don't think we
should be in business of distributing distribution specific files.
FWIW, Fedora and RHEL don't use this particular .spec
On Sat, Jun 11, 2011 at 4:29 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Ben Wolfson wrote:
You can't have an internal replacement
field in this part of the replacement field, so '{' can always safely
be assumed to be Just a Brace and not the start of a replacement
field, regardless of
On Mon, 13 Jun 2011 21:03:18 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I disagree. We certainly include PCbuild/*.vcproj, and Tools/msi,
which are also distribution-specific. Likewise, we have plenty
of OSX-specific files (including special-casing for specific releases
thereof).
Raymond Hettinger wrote:
How would you describe the creation of a lazy result
that keeps a reference to the underlying buffer?
I'd call it a view. There is plenty of precedence for this
kind of object in Python -- I gave a few examples before.
The distinguishing feature of ropes, as I
Thank you all for the responses. Rather than reply to each, I just made
one big summary. :)
Martin v. Löwis wrote:
Ethan Furman wrote:
# constants
EOH = b'\r'[0]
CHAR = b'C'[0]
DATE = b'D'[0]
FLOAT = b'F'[0]
INT =
On 06/13/2011 06:55 AM, Michael Foord wrote:
There are two options:
Bring the full functionality into the standard library so that Python
supports virtual environments out of the box. As is the case with adding
anything to the standard library it will then be impossible to add
features to
On 06/13/2011 08:07 AM, Nick Coghlan wrote:
On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
You're right in terms of the current Python ecosystem and 3.x adoption,
because
of course this approach requires support from Python itself in terms of its
site.py code.
At 03:11 PM 6/13/2011 -0700, Ethan Furman wrote:
Nick Coghlan wrote:
Agreed, but:
EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\rCDFILMN'
is a shorter way to write the same thing.
Going two per line makes it easier to mentally map the characters:
EOH, CHAR = b'\rC'
DATE,
On 06/13/2011 06:46 PM, Carl Meyer wrote:
FWIW, historically pretty much every new Python version has broken
virtualenv
I should clarify that this is because of the delicate stdlib
bootstrapping virtualenv currently has to do; the built-in virtualenv
eliminates this entirely and will require
On 14/06/2011 00:46, Carl Meyer wrote:
[snip...]
So I don't think a virtualenv stdlib module would be at all likely to
break on a new OS release, if Python itself is not broken by that OS
release. (It certainly wouldn't be the stdlib module most likely to be
broken by OS changes, in comparison
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby p...@telecommunity.com wrote:
You can still do it one at a time:
CHAR, = b'C'
INT, = b'I'
...
etc. I just tried it with Python 3.1 and it works there.
I almost mentioned that, although it does violate one of the
unwritten rules of the Zen (in
Ben Wolfson wrote:
If by item selector you mean (using the names from the grammar in
the docs) the element_index, I don't see why this should be the case;
dictionaries can contain non-identified keys, after all.
Of course they can, but that's not the point. The point is
that putting arbitrary
On 13Jun2011 13:47, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
| Nick Coghlan ncoghlan at gmail.com writes:
|
| On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou solipsis at pitrou.net
| wrote:
| As a side-note, I think calling it virtualization is a recipe for
| confusion.
|
| Indeed, OS
On 13Jun2011 17:31, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
| Barry Warsaw barry at python.org writes:
| Ah, no I don't think that'll be helpful. I can probably reuse the python3.3
| packaging stuff to do a PPA.
|
| Okay, go for it! Is there a specific tutorial somewhere about making a PPA
On Mon, Jun 13, 2011 at 5:36 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Ben Wolfson wrote:
If by item selector you mean (using the names from the grammar in
the docs) the element_index, I don't see why this should be the case;
dictionaries can contain non-identified keys, after all.
On Jun 14, 2011, at 01:00 AM, Michael Foord wrote:
On 14/06/2011 00:46, Carl Meyer wrote:
[snip...]
So I don't think a virtualenv stdlib module would be at all likely to
break on a new OS release, if Python itself is not broken by that OS
release. (It certainly wouldn't be the stdlib module
On 12:35 am, ncogh...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby p...@telecommunity.com
wrote:
You can still do it one at a time:
CHAR, = b'C'
INT, �= b'I'
...
etc. �I just tried it with Python 3.1 and it works there.
I almost mentioned that, although it does violate one of
Howdy howdy. Michael Foord can't make it to EuroPython this year--and
congratulations to him on his new baby!--so he's asked me to chair the
Python Language Summit in his stead. Although I have some suggested
topics from Michael, I don't have any burning issues of my own to add to
the
40 matches
Mail list logo
