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 dock
On 12:35 am, ncogh...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby
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
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
On Mon, Jun 13, 2011 at 5:36 PM, Greg Ewing 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.
>
> Of course they c
On 13Jun2011 17:31, Vinay Sajip wrote:
| Barry Warsaw 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
On 13Jun2011 13:47, Vinay Sajip wrote:
| Nick Coghlan gmail.com> writes:
|
| > On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou pitrou.net>
| > wrote:
| > > As a side-note, I think calling it "virtualization" is a recipe for
| > > confusion.
| >
| > Indeed, OS level virtualisation pretty much
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 arbitrar
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby 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 this case, "synta
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 to
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 m
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'
> D
On 06/13/2011 08:07 AM, Nick Coghlan wrote:
> On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip 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
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
> feature
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]
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 underst
On Mon, 13 Jun 2011 21:03:18 +0200
"Martin v. Löwis" 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).
> >
>
On Sat, Jun 11, 2011 at 4:29 PM, Greg Ewing 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 whether it's dou
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
>> 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
>
Barry Warsaw 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
suff
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
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
Jiawei Li 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 you're only int
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
Barry Warsaw 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 ther
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
Nick Coghlan gmail.com> writes:
> On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou 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
On Mon, Jun 13, 2011 at 08:42, Vinay Sajip wrote:
> Nick Coghlan 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 Win
Nick Coghlan 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 make
do wit
On Mon, Jun 13, 2011 at 10:22 PM, Vinay Sajip wrote:
> Michael Foord 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 doesn't rely on
> symlinks, but
On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip 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 beyond supporting
> o
On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou 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
enough to avoid co
On Mon, 13 Jun 2011 11:47:33 + (UTC)
Vinay Sajip 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 may be fitting
Nick Coghlan 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.
You're
Michael Foord 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 library
On Mon, Jun 13, 2011 at 9:55 PM, Michael Foord
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 is desirable for too
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 updates
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 my
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-structure
39 matches
Mail list logo
