On Mar 02, 2011, at 03:29 PM, Piotr Ożarowski wrote:
>[Allan McRae, 2011-03-02]
>> But is that not the whole point of adding the /usr/bin/python2 symlink.
>> That way a developer can explicitly use a /usr/bin/python2 or
>> /usr/bin/python3 shebang and have it portable everywhere. At the momen
On Mar 02, 2011, at 02:49 PM, James Y Knight wrote:
>On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
>> I don't have a problem with adding such a symlink, and I think it should be
>> done by Informational PEP, not Standards Track PEP. Since there will be no
>> Python
On Mar 03, 2011, at 09:55 AM, Piotr Ożarowski wrote:
>I don't really mind adding /usr/bin/python2 symlink just to clean Arch
>mess, but I do mind changing /usr/bin/python to point to python3 (and I
>can use the same argument - "Explicit is better than implicit" - if you
>need Python 3, say so in t
On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
>On a related note, we have a number of scripts packaged across the
>distributions with a shebang line that reads:
> #!/usr/bin/env python
>which AIUI follows upstream recommendations.
Actually, I think this is *not* a good idea for distro prov
On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
>Thinking outside of the box, I can think of something that would satisfy
>your requirements but I don't know how appropriate it is for upstream python
>to ship with. Stop shipping /usr/bin/python. Ship "python" in an alternate
>location like
Folks, please stop CC'ing p...@python.org for non-PEP submissions. They all
get held for moderator approval. I've approved a few of them, but I'm going
to start rejecting them (so you get a bounce :) unless the message actually
contains a PEP.
cheerfully-co-editing-peps-ly y'rs,
-Barry
signatu
On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:
>Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
>> Is Rietveld or Review Board being used within the Python core development
>> community? I looked at the dev guide but didn't see anything obvious about
>> code reviews. I don'
On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:
>On Fri, Mar 4, 2011 at 10:59 AM, wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:
>That (below) is not distutils it is setuptools. distutils just uses
>`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Sure, but that'll all be moot when distutils2 is integrated into Python
3.3, right? :)
-Barry
signature.as
On Mar 03, 2011, at 08:09 PM, Toshio Kuratomi wrote:
>Note to dmalcolm: IIRC, that also means that the Feature page you point to
>isn't going to happen either. Barry -- if other distros adopted stronger
>policies, then that might justify me taking this back to the Packaging
>Committee.
I know Sc
On Mar 05, 2011, at 01:33 AM, Nick Coghlan wrote:
>On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw wrote:
>> Folks, please stop CC'ing p...@python.org for non-PEP submissions. They all
>> get held for moderator approval. I've approved a few of them, but I'm going
On Mar 03, 2011, at 08:37 PM, Toshio Kuratomi wrote:
>No, alternatives is really only useful for a very small class of problems
>[1]_ and [2]_.
Thanks for the clarification. I was on the fence about making the suggestion
in the first place. ;)
>For this discussion there's an additional problem
On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote:
> Am 04.03.2011 20:14, schrieb Guido van Rossum:
>> Is there any discussion still going on about the details of the PEP
>> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
>> think it should be the same there if possible.
>
On Mar 06, 2011, at 08:17 AM, Benjamin Peterson wrote:
>I wonder if we couldn't kill the "cpython" repo name in the commit
>mails. I find it wastes space for the commit message in the subject
>line, and it's pretty obvious it's the cpython repo from the branch
>name.
I agree that the commit messa
On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:
>Actually, my post was saying that these two can be decoupled. ie: It's
>possible to not have /usr/bin/python while still allowing users to type
>python at a shell prompt and get the interpreter.
>
>This is done by either redefining the PATH to
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>If we can get to a mode where non-committers can push to a "fork" on
>hg.python.org, we can dodge the patch format issue by having folks post
>"pull requests" for that fork instaed.
>
>For the repoze and pylons projects, we have found the quality a
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>On Mon, 7 Mar 2011 12:04:18 -0500
>Barry Warsaw wrote:
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>>
>> >If we can get to a mode where non-committers can push to a "fork" on
>> >hg.pyth
On Mar 07, 2011, at 07:44 PM, Antoine Pitrou wrote:
>I agree with Thomas' answer here: while a branch makes it easier to
>maintain a patch (but you can also use e.g. Mercurial Queues), it
>doesn't make it easier to *review*. You are assuming that I, as a
>reviewer, want to know about the history
On Mar 08, 2011, at 12:01 PM, Stephen J. Turnbull wrote:
>Barry Warsaw writes:
>
> > I hear this complaint [about branches being no help in reviewing] a
> > lot from hg and git users, so maybe it's just the nature of the
> > tools. In which case, I'm f
On Mar 14, 2011, at 09:46 PM, Antoine Pitrou wrote:
>Why does it get yet another name?
>We already have distutils, setuptools, distribute, distutils2... now
>"packaging"?
We need a unique name for Python 3.3, otherwise third party modules can't be
written to conditionally depend on the batteries-
On Mar 16, 2011, at 12:39 PM, Alexander Belopolsky wrote:
>I was editing the turtle module (for issue11571, if you are
>interested) when I noticed that it has the following line:
>
>_ver = "turtle 1.1b- - for Python 3.1 - 4. 5. 2009"
>
>This is obviously out of date and this variable is not use
On Mar 21, 2011, at 06:14 AM, s...@pobox.com wrote:
>It, however requires every developer to become facile, if not expert, with
>the ins and outs of the Python/Mercurial workflow. This discourages casual
>or intermittent contributions. My main contribution to the Python codebase
>over the past c
On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 11:25:31 -0400
>Barry Warsaw wrote:
>>
>> Does Mercurial have a way of acting like a centralized vcs to the end user,
>> the way Bazaar does? IOW, if Skip or others were more comfortable with a
On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>On 20.03.2011 16:21, Guido van Rossum wrote:
>> What is "rebase"? Why does everyone want it and hate it at the same time?
>
>Basically, rebase is a way to avoid having pointless merge commits on the
>same branch.
There's something I don't underst
On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
>So you are worried about the small window between me doing an 'svn up',
>seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate
>concern, but considering the fact that if the same thing happens in hg,
>the only difference is
On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 12:20:15 -0400
>Barry Warsaw wrote:
>> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>>
>> >On 20.03.2011 16:21, Guido van Rossum wrote:
>> >> What is "rebase"? Why d
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>Keeping the repository clean makes it easier to use a bisection search to
>hunt down the introduction of a bug. If every developer's intermediate
>commits make it into the main repository, it's hard to go back to an older
>revision to test s
On Mar 21, 2011, at 08:58 PM, Georg Brandl wrote:
>On 21.03.2011 20:09, s...@pobox.com wrote:
>>
>> Daniel> If every developer's intermediate commits make it into the main
>> Daniel> repository, it's hard to go back to an older revision to test
>> Daniel> something, because many of th
On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:
>Barry Warsaw writes:
>
>> There's something I don't understand about rebase. It seems like most
>> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
>> users do.
>>
>> I'd li
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 14:29:54 -0400
>Barry Warsaw wrote:
>> >
>> >I don't think many hg users advocate rebase, really. AFAICT the
>> >Mercurial developers themselves don't seem to use it (they do use
On Mar 18, 2011, at 07:40 PM, Guido van Rossum wrote:
>On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing
>wrote:
>> Tres Seaver wrote:
>>
>>> I'm not even sure why you would want __version__ in 99% of modules: in
>>> the ordinary cases, a module's version should be either the Python
>>> version (for
On Mar 19, 2011, at 01:51 PM, Antoine Pitrou wrote:
>On Fri, 18 Mar 2011 20:12:19 -0700
>Toshio Kuratomi wrote:
>> There is a section in PEP8 about __version__ but it serves a slightly
>> different purpose there:
>>
>> """
>> Version Bookkeeping
>>
>> If you have to have Subversion, CVS, or
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>I'd rather take a look at the final aggregate patch to see if it looks
>correct, actually. It's easy to have incremental changes which look
>good but lead to a questionable patch in the end. Better to review it
>in aggregate, IMO.
I think it wo
On Mar 21, 2011, at 11:09 PM, Martin v. Löwis wrote:
>However, what some of us requesting is that the "SHOULD collapse"
>in the devguide is changed to a "MAY collapse", making it strictly
>an option of the committer.
+1
-Barry
signature.asc
Description: PGP signature
__
On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:
>FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>branch name is reserved, and it implies that the head with the highest
>revision number from that branch will be checked out on 'hg clone'.
I think that's different tha
On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote:
>Bazaar apparently has a notion of mainline whereas Mercurial believes
>that all changesets are created equal. The tools are different.
I'm curious: what are the benefits of the Mercurial model?
-Barry
signature.asc
Description: PGP signature
_
On Mar 22, 2011, at 07:51 AM, Martin v. Löwis wrote:
>Am 22.03.2011 02:02, schrieb Eugene Toder:
>>> Not if the changes you want to suppress are actually also on the same
>>> branch as the one whose mainline you are trying to see (which they
>>> typically are, with the branch typically being "defa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mar 22, 2011, at 10:45 AM, John Arbash Meinel wrote:
>I'm personally a huge fan of 2(multi)-tier testing. So you have a basic
>(and fast) test suite that runs across all your modules before every
>commit in your mainline. Then a much larger (and
On Mar 18, 2011, at 08:50 PM, Guido van Rossum wrote:
>I do distinctly recall __version__ being standardized for other
>purposes too, but I have no idea how to find that reference... It
>probably was well before 2000.
FWIW, I went spelunking in my email archives and the earliest reference to
__ve
On Mar 22, 2011, at 02:38 PM, Guido van Rossum wrote:
>All trails eventually lead to Ken! :-)
Indeed!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:
>On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw wrote:
>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>> case where you get tripped up on the merge dance floor. When that happens,
&
On Mar 23, 2011, at 02:31 PM, Antoine Pitrou wrote:
>Does anyone use "make quicktest" for something useful?
Not currently. Can it be made useful? Should it be removed?
>There is a reason the regression test suite has many tests...
>"Blacklisting" some of them sounds like a bad thing to do.
If
In IRC Antoine suggested -j5 (note that -j is not compatible with -l so you
have to override TESTOPTS not just EXTRATESTOPTS). Adding --slow here's what
I get:
$ make TESTOPTS="-j5 --slow" quicktest
...
10 slowest tests:
test_mmap: 221.6s
test_shelve: 184.4s
test_posix: 156.3s
test_largefile: 150
On Mar 23, 2011, at 03:08 PM, Antoine Pitrou wrote:
>On Wed, 23 Mar 2011 09:53:37 -0400
>Barry Warsaw wrote:
>> OTOH, running
>> some localized test for the feature or bug you're trying to land might be
>> enough.
>
>Might indeed. Quite often, though, some c
On Mar 24, 2011, at 12:29 AM, Nick Coghlan wrote:
>Entirely independent of the "make quicktest" question, it would be
>nice if the default behaviour of regrtest was updated to check the
>number of cores a machine has and default to using that many processes
>(leaving people to turn it down if they
On Mar 23, 2011, at 02:52 PM, Antoine Pitrou wrote:
>Then many people will start running the "smoke test" rather than the
>whole suite, which will create new kinds of problems. It's IMO a bad
>idea. Let Barry learn about "-j" :)
Well, that's a social problem, not a technical problem.
(See other
On Mar 23, 2011, at 10:02 AM, s...@pobox.com wrote:
>Eliminating tests based on the time it takes to run them suggests that the
>resulting smaller test run may have considerably different overall coverage
>quality than you might desire. Some tests (syntax, basic arithmetic, etc)
>probably run bla
On Mar 23, 2011, at 05:16 PM, Antoine Pitrou wrote:
>If we start promoting a "quicker" way of running tests, then nobody
>will use the normal way. I'm sorry, I'm -1 on that. There are
>regressions often enough on the buildbots.
I'm not sure it's worth continuing this thread. I've explained that
On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
>That's completely bogus. There's no reason to believe that a push race would
>favour certain regressions over certain others. Again, you need the full test
>suite to assert that no regressions occured. (or you might as well run 10
>tests at ran
On Mar 25, 2011, at 09:51 AM, Tres Seaver wrote:
>That was precisely my proposal: when trying to check in changes to a
>stdlib module, we required that developers ensure that the module's
>tests, *and* those of its dependents, pass. We would need to add new
>testing infrastructure to support thi
On Mar 27, 2011, at 01:39 PM, Neil Schemenauer wrote:
>Barry Warsaw wrote:
>> I'm asking because I don't know hg and git well enough to answer the
>> question. In my own use of Bazaar over the last 4+ years, I've almost never
>> rebased or even been asked to.
On Mar 30, 2011, at 09:20 AM, Ben Finney wrote:
>The ‘vc’ package (I'm using Debian's GNU Emacs 23.2.1) now recognises
>DVCS-controlled *files*, and works well with them. It's still unaware
>that modern VCS deals with project *trees*, so works only at an
>individual file level. Still quite useful
On Mar 30, 2011, at 09:43 AM, Ralf Schmitt wrote:
>Barry Warsaw writes:
>>
>> In case you missed it, there are now *three* Python modes. Tim Peters'
>> original and best (in my completely unbiased opinion ) python-mode.el
>> which is still being developed, the o
Ubuntu 11.04 added support for multiarch libraries:
https://wiki.ubuntu.com/MultiarchSpec
http://wiki.debian.org/ReleaseGoals/MultiArch
At the moment, I don't care about issue 1294959 which I think addresses
building multiarch flavors of Python:
http://bugs.python.org/issue1294959
I have a much
On Apr 01, 2011, at 08:37 AM, Nick Coghlan wrote:
>On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo wrote:
>> If I understand the policy correctly, 2.5 and 2.6 are not considered
>> active branches, so any doc, build or bug fixes are not acceptable.
>
>Actual build fixes may be acceptable, if they're
On Apr 01, 2011, at 02:07 PM, Antoine Pitrou wrote:
>(and, no, I don't think building an old Python on a new Debian/Ubuntu
>system is anymore important than other kinds of bug or build fixes;
>let's stop implying that Ubuntu is the dominant OS out there, because
>it's really not)
For the record,
On Apr 01, 2011, at 03:07 PM, Michael Foord wrote:
>That was about whether the release manager should backport doc fixes from 2.7
>to the 2.6 branch and the conclusion was "not to bother", which is very
>different from saying that individual developers *can't* apply doc fixes if
>*they want*.
>
>O
On Apr 01, 2011, at 09:47 PM, Martin v. Löwis wrote:
>> FWIW - I maintain legacy code for python2.4, and 2.5 (mainly 2.5).
>[...]
>> As a result, I'm very much +1 on integrating this patch to previous
>> versions.
>
>Updating 2.4 is clearly out of question; and I veto changing 2.5 in
>that respect
Yeah, I know the $Keyword$ strings here are wrong. I'm not sure what to
do about them though.
PEP: 396
Title: Module Version Numbers
Version: $Revision: 65628 $
Last-Modified: $Date: 2008-08-10 09:59:20 -0400 (Sun, 10 Aug 2008) $
Author: Barry Warsaw
Status: Draft
Type: Informational
Content-
On Apr 02, 2011, at 10:55 AM, Stefan Krah wrote:
>In this case, it's clearly Ubuntu who is going to break things. Still,
>the proposed patch could make life a lot easier for many people.
I'd be more concerned about adding some Debian/Ubuntu special code to setup.py
if it wasn't already a rats nes
On Apr 05, 2011, at 01:22 PM, Glenn Linderman wrote:
>On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>> __version__ = pkgutil.get_distribution('elle').metadata['version']
>
>Th
On Apr 10, 2011, at 08:52 AM, Ben Finney wrote:
>Nitpick: Please call these “version strings”. A version string is hardly
>ever just one number, and not in the general case anyway.
The PEP title does say version *numbers* (plural), and that seems more general
than using 'strings' here.
>Emil
On Apr 07, 2011, at 12:26 AM, Nick Coghlan wrote:
>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>
>> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>>
>> __version__ = pkgutil.get_distribution('elle').metadata['version&#
On Apr 07, 2011, at 12:10 PM, Michael Foord wrote:
>>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>>
>>> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>>>
>>> __version__ = pkgutil.get_distribution('elle').m
On Apr 09, 2011, at 06:23 PM, Éric Araujo wrote:
>> One of the main complaint against setuptools is that having to change
>> your application code because of the packaging tool used was not a > good
>> idea. Having to use require instead of import or resource_whatever
>> instead of open (or get_d
On Apr 07, 2011, at 09:59 PM, Nick Coghlan wrote:
>It sounds like part of the PEP needs another trip through
>distutils-sig. An informational PEP really shouldn't be advocating
>standard library changes, but it would make sense for this point of
>view to inform any updates to PEP 386 (the version
On Apr 07, 2011, at 12:51 PM, Michael Foord wrote:
>So I don't think recommending
>"pkgutil.get_distribution('elle').metadata['version']" as a way for packages
>to provide version information is good advice.
I want to make it clear that this section of the PEP is intended only to
provide some cho
On Apr 07, 2011, at 02:08 PM, Nick Coghlan wrote:
>(Also, tsk, tsk, Barry for including Standards track proposals in an
>Informational PEP!)
Is that really illegal? :)
>P.S. A nice coincidental progression: PEP 376, 386 and 396 are all
>related to versioning and package metadata
time-machine-ly
On Apr 06, 2011, at 09:55 PM, Glenn Linderman wrote:
>The PEP doesn't mention PyPI, and at present none of the modules there use
>"packaging" :) So it wasn't obvious to me that the PEP applies only to PyPI,
>and I have used modules that were not available from PyPI yet were still
>distributed and
On Apr 07, 2011, at 04:53 PM, Nick Coghlan wrote:
>What I would like to see the PEP say is that if you don't *have* a
>setup.cfg file, then go ahead and embed the version directly in your
>Python source file. If you *do* have one, then put the version there
>and retrieve it with "pkgutil" if you w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Apr 06, 2011, at 11:04 AM, John Arbash Meinel wrote:
>> In other words, parse_version will return a tuple for each version string,
>> that is compatible with StrictVersion but also accept arbitrary version and
>> deal with them so they can be com
On Apr 07, 2011, at 09:13 AM, Toshio Kuratomi wrote:
>Barry -- I think we want to talk about NormalizedVersion.from_parts() rather
>than parse_version().
See my previous follow up. It probably makes sense to be explicit in one
PEP or the other, but...
>So you can't escape needing a function to
On Apr 12, 2011, at 10:14 PM, Laura Creighton wrote:
>In a message of Tue, 12 Apr 2011 15:56:32 EDT, Barry Warsaw writes:
>
>>The Deriving section of the PEP is not the most important part of it, and
>> is
>>not making specific recommendations. If it's not cle
With Martin getting ready to release 2.5.6, I think it's time to prepare a
2.6.7 source-only security release.
I'll work my way through the NEWS file and recent commits, but if there is
anything that you know is missing from the 2.6 branch, please let me know. It
would be especially helpful if th
On Apr 19, 2011, at 03:25 PM, anatoly techtonik wrote:
>On Mon, Apr 18, 2011 at 3:53 PM, Barry Warsaw wrote:
>> With Martin getting ready to release 2.5.6, I think it's time to prepare a
>> 2.6.7 source-only security release.
>>
>> I'll work my way through
On Apr 28, 2011, at 04:34 AM, Terry Reedy wrote:
>On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>> Hello
>>
>> I removed some assert calls in distutils some time ago because the
>> package was not behaving correctly when people were using Python with
>> the --optimize flag. In other words, assert becam
On Apr 28, 2011, at 10:22 AM, s...@pobox.com wrote:
>Barry> I would agree. Use asserts for "this can't possibly happen
>Barry> " conditions.
>
>Without looking, I suspect that's probably what the author thought he was
>doing.
BTW, I think it always helps to have a really good assert mess
On Apr 28, 2011, at 11:04 AM, Fred Drake wrote:
>On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
>> I would agree. Use asserts for "this can't possibly happen "
>> conditions.
>
>Maybe we should rename "assert" to "wink", just to
I'd like to make a Python 2.6.7 release candidate this Friday, May 6, with a
final release scheduled for May 20. I've put these dates on the Python
Release Schedule calendar.
This will be a source-only security release. I see no release blockers for
Python 2.6, so if you know of anything that mu
Hello to all you Pythoneers and Pythonistas,
I'm happy to announce the availability of Python 2.6.7 release candidate 2.
Release candidate 1 was not widely announced due to a mismatch between the
Mercurial and Subversion branches. Barring any unforeseen issues, this will
be the last release candi
Okay, this reply is getting off-topic, so I won't belabor the point (please
email me directly if you want to discuss further).
On May 23, 2011, at 08:25 AM, Fred Drake wrote:
>2011/5/23 Łukasz Langa :
>> The new Ubuntu already ships with Python 3.2.
>
>Uptake on Ubuntu 11.04 will take longer than
On May 25, 2011, at 10:24 AM, Sandro Tosi wrote:
>before opening an issue to track the request, I'd like to ask advice
>here about this: extend os.chown() to accept even user/group names
>instead of just uid and gid.
>
>On a Unix system, you can call chown command passing either id or
>names, so i
On May 25, 2011, at 04:15 PM, Dirkjan Ochtman wrote:
>Right. Please add a mention of shutil.chown() to the os.chown() docs, though.
Brilliant!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
On Jun 01, 2011, at 02:33 AM, Terry Reedy wrote:
>On 6/1/2011 1:37 AM, "Martin v. Löwis" wrote:
>>> The requested one character change is
>>> -DEFAULT_REPOSITORY = 'http://pypi.python.org/pypi'
>>> +DEFAULT_REPOSITORY = 'https://pypi.python.org/pypi'
>>>
>>> If Tarek (or perhaps Eric) agre
On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote:
>+Continuation lines should align wrapped elements either vertically using
>+Python's implicit line joining inside parentheses, brackets and braces,
>+or using a hanging indent of double your code indention, in which case
>+th
On Jun 02, 2011, at 03:07 PM, R. David Murray wrote:
>Personally, I use "enough" indentation. Sometimes that is a single
>indentation level, but sometimes it is more. Two spaces is definitely
>right out, though :)
>
>The place where a single indentation level is *not* enough is when the
>line be
On Jun 02, 2011, at 12:57 PM, Glenn Linderman wrote:
>On 6/2/2011 12:01 PM, Guido van Rossum wrote:
>> Bingo. That's why. (Though you are missing some colons in your examples.:-)
>>
>> --Guido
>
>You operate as a good Python compiler :)
Actually, this is a key insight, which I just mentioned in a
Hello Pythoneers and Pythonistas,
I'm happy to announce the final release of Python 2.6.7.
Python 2.6 is in security-fix only mode. This means that general bug
maintenance has ended, and only critical security issues are being fixed.
We will support Python 2.6 in security-fix only mode until Oct
On Jun 05, 2011, at 08:20 AM, Aahz wrote:
>> >From your python download page you need to update the public keys to not
>> use the faulty MD5 digest algorithm. (see the link listed below)
>>
>> $ gpg --import pubkeys.txt
>> gpg: key 6A45C816: public key "Anthony Baxter "
>> imported
>> gpg: WARN
On Jun 09, 2011, at 10:51 AM, Vinay Sajip wrote:
>I just filed an issue which shows a serious breakage in the marshal module:
>
>"file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3"
>
>http://bugs.python.org/issue12291
>
>Perhaps this issue should be marked as a release block
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
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
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
I just fixed Makefile.pre.in to install the packaging directory and all its
subdirs. Without this `python3.3 -c 'import packaging'` fails from the
installation target directory. I'm not sure the Fellowship intends for every
subdir to get installed, so please double check. I just added everything
Hi folks,
Yesterday, 6 Washington DC area Pythonistas met to work on PEP 382. I wrote
up a summary based on my notes and blogged about it here:
http://www.wefearchange.org/2011/06/pep-382-sprint-summary.html
Hopefully, the other participants will correct my mistakes and fill in the
holes. A f
On Jun 26, 2011, at 05:02 AM, nick.coghlan wrote:
>http://hg.python.org/peps/rev/9f7a0b4e38a7
>changeset: 3889:9f7a0b4e38a7
>user:Nick Coghlan
>date:Sun Jun 26 13:02:17 2011 +1000
>summary:
> Record Guido's acceptance of PEP 380
>
>files:
> pep-0380.txt | 10 --
> 1 f
On Jun 29, 2011, at 01:05 AM, Vinay Sajip wrote:
>Ned Deily acm.org> writes:
>
>> Could some text be added to the svn browser pages to at least indicate
>> that the repo is no longer being updated with a link to the
>> hg.python.org browser? I'm not sure what to do about the repos
>> themsel
On Jun 28, 2011, at 09:42 PM, Georg Brandl wrote:
>We need to stop making incompatible changes to Python 3. We had the chance
>and took it to break all kinds of stuff, some of it gratuitous, with 3.0 and
>even 3.1. Now the users need a period of compatibility and stability (just
>like the langua
On Jun 30, 2011, at 04:17 PM, Éric Araujo wrote:
>Adding a THIS_REPOSITORY_HAS_MOVED file to recent branches looks good.
I'm not against adding this to svn, but please be sure these files don't leak
into the tarballs should we need to cut another 2.5 or 2.6 release. I think
that just means tweak
On Jul 07, 2011, at 12:26 PM, Victor Stinner wrote:
>Le 07/07/2011 05:26, Nick Coghlan a écrit :
>> Victor, could you please check this into the PEPs repo? It's easier to
>> reference once it has a real number.
>How do I upload it? Should I contact a PEP editor? How?
Email p...@python.org
Cheers
1601 - 1700 of 2704 matches
Mail list logo
