Sounds good to me. Thanks for weighing in.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
On Aug 16, 2010, at 11:54 AM, Barry Warsaw wrote:
>Either way, I think we need a 2.6.6rc2 (a thought that's been invading
>my dreams all weekend :). This would push back 2.6.6 final to
>September 12 or 13.
Make that 2.6.6 final on August 24.
-Barry
signature.asc
Description:
On Aug 17, 2010, at 09:45 AM, Nick Coghlan wrote:
>A bit late (since you already cut rc2), but the key point for me is
>that code that is fixed to work correctly on 2.6.6 (where this bug has
>been fixed) will still work on any 2.6.x release.
Yep, thanks.
-Barry
signature.asc
Descrip
. We plan on continuing to support
source-only security fixes in Python 2.6 for the next five years.
My thanks go out to everyone who has contributed with code, testing and bug
tracker gardening for Python 2.6.6. The excellent folks on #python-dev are
true Pythonic heros.
Enjoy,
-Barry
(on behalf o
ep3149.txt
and the Launchpad branch:
https://code.edge.launchpad.net/~barry/python/sovers
I'd like to know if anybody has additional feedback, suggestions, or
objections that you think still need to be addressed. You can follow up here
or in the tracker.
Now that 2.6.6 is almost off my
On Aug 23, 2010, at 03:45 PM, Benjamin Peterson wrote:
>It's generally more convenient that getattr(obj, "blah", None) is not
>None.
Clearly, the solution is a new builtin called 'Missing'.
-Barry
signature.asc
Description: PGP signature
___
y
releases of Python 2.6 will be made available. After that date, Python 2.6
will no longer be supported, even for security bugs.
My deepest appreciation go out to everyone who has helped contribute fixes
great and small, and much testing and bug tracker gardening for Python 2.6.6.
Enjoy,
-Barry
On Aug 24, 2010, at 03:31 PM, Barry Warsaw wrote:
>Python 2.6.6 marks the end of regular maintenance releases for the
>Python 2.6 series. From now until October 2013, only security
>related, source-only releases of Python 2.6 will be made available.
>After that date, Python 2.6 will
purposes, it's a moot point on *nix.
-Barry
signature.asc
Description: PGP signature
___
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
3.2 or later Python version as a goal of the PEP, I would
>say that allowing mixing of C runtimes is definitely one of the PEP's
>goals.
It should be explicit about that then, and provide detail about why the
runtime is relevant to Windows programmers (and probably not relevant
ssing a security concern, but we'll handle that the same way we handle
all security related fixes to retired branches.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
ering that
Martin is off-line for a while)? If acceptable, I'd like to get this into the
tree before 3.2 alpha 2, currently scheduled for September 5.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python
brary file name for wide unicodes. It's an issue for PEP 384.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
accepted, its use can fade out again
>* it is a strictly optional feature
>
>Barry promised the code will go in before this weekend's alpha2, so
>that distributors can subject the new code to proper testing, should
>they choose to use PEP 3149 features.
Thanks very much Georg an
your responsibility to shepherd
your PEP through the process. Don't be a pest, but do keep an eye on the
release calendar so that you're not scrambling for a snap decision at the last
minute. 18 months can go by quickly. :)
-Barry
signature.asc
Description: PGP signature
___
accepted, its use can fade out again
>* it is a strictly optional feature
>
>Barry promised the code will go in before this weekend's alpha2, so
>that distributors can subject the new code to proper testing, should
>they choose to use PEP 3149 features.
Once again, thanks. C
end = i
> break
> with open('Misc/NEWS', 'w', encoding="utf-8") as fp:
>- fp.writelines(lines[:start+1])
>+ fp.writelines(lines[:start+2])
> fp.write(NEWS_TEMPLATE)
> fp.writelines(lines[end-
tinues installing files into lib-dynload?
See above. It is not the intent of this PEP to change the installation
directories. Distributions have all the other tools they need to get the
files into the right place for their layouts.
-Barry
signature.asc
Description: PGP signature
___
stributions install third party package modules
(``.pyc`` and ``.so`` files) into `/usr/share/pyshared`[...]
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
ows.
>> That section is talking about files installed by distributions,
>> which need to take special steps to get everything
>> into /usr/{lib,share}/pyshared; a standard out-of-the-tarball
>> install will not change the way it is installed.
>>
>> It may well
the point is *I* don't know! I'm not a Windows developer, and I'm
still unable to even build Python on Windows 7 with VS2010. In the absence of
a Windows developer explicitly saying that it's useful, and offering to help
implement it, then we'll just leave it for c
ib. This keeps confusing me, despite not being
>part of the specification.
I don't, as you should now see.
-Barry
signature.asc
Description: PGP signature
___
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
doesn't say how a distribution
>is supposed to choose its PEP 3149 filesystem layout (instead of
>/usr/lib/python3.2/site-packages).
Why should it? Distributions are going to make their own decisions
independent of the PEP. That's why s/would/might/ in the above change. I'm
On Sep 13, 2010, at 05:04 PM, Antoine Pitrou wrote:
>On Mon, 13 Sep 2010 10:55:16 -0400
>Barry Warsaw wrote:
>> On Sep 13, 2010, at 04:36 PM, Antoine Pitrou wrote:
>> >> -/usr/share/pyshared/foo.cpython-32m.so
>> >> -/usr/share/pyshared/foo.cpyth
a bit; no heavy
>re-architecting, but simply a bunch of changes to make it higher-level.
>Is it acceptable?
>
>(and, yes, I would add a test suite)
Heartily +1.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@p
ing to do) from the stdlib when it comes time to port Mailman
to py3k.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
er, useful, and more
generally applicable techniques for dealing with byte/strings in these
contexts. That would be time well spent, and may transfer to work on the
email package too for example.
-Barry
signature.asc
Description: PGP signature
is beyond me ...
I'll note one other thing. Mailman 3 intends[*] to provide NNTP access
directly to its archives, exactly because IMO it's so much better to read old
mail that way.
>PPS: What makes you think the email package transition is complete?
Heh.
-Barry
[0] 'round
ncludes
improvements to the stdlib. In fact, with the moratorium in place, I'm hoping
*most* of the incredible Pythonic brain power will be devoted to Python 3
stdlib improvements.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailin
On Sep 14, 2010, at 10:34 PM, Chris Withers wrote:
>http://www.python.org/download/releases/2.6.6/
>
>..includes the text:
>
>"This is a release candidate; we currently support these formats:"
>
>Is that text meant to be there?
Nope, and fixed.
Thanks
. I of course did not find the time :/ so it hasn't happened yet.
Of course, the set of platforms, Python versions, and packages we care about
is much narrower than the full Python community, but it would still be an
interesting exercise.
-Barry
signature.asc
Description: PGP signature
unds unlikely but may not be any more incompatible
>than making it work properly :-).
I would much prefer holding up the release to fix wsgiref rather than remove
it. I think it's an important module worthy of being in the stdlib.
-Barry
signature.asc
D
ies like tox (http://pypi.python.org/pypi/tox)
>for doing all of this now.
>
>Manpower and time prohibit it
This might make for a fun sprint at Pycon 2011. It's closer than you
think. (Well, maybe not closer than Jesse thinks :).
-Barry
signature.asc
On Sep 15, 2010, at 09:21 PM, Georg Brandl wrote:
>Am 15.09.2010 20:32, schrieb Barry Warsaw:
>> I would much prefer holding up the release to fix wsgiref rather
>> than remove it. I think it's an important module worthy of being in
>> the stdlib.
>
>Really? I
hich really wants to be working with raw bytes (e.g.
>URLs coming off the wire).
Note that email has exactly the same problem. A general solution -- even if
embodied in *well documented* best-practices and convention -- would really
help make the stdlib work consistently, and I bet third party li
s.
When you say "installed python 2.7" do you mean the one you installed to
/usr/local from a from-source build, or something else (e.g. a Python 2.7
package perhaps)?
>And I will file a bug report soon unless that is inappropriate.
Sure. Please +nosy me. But I think something e
On Sep 16, 2010, at 02:56 PM, Tom Browder wrote:
>On Thu, Sep 16, 2010 at 14:36, Barry Warsaw wrote:
>> When you say "installed python 2.7" do you mean the one you
>> installed to /usr/local from a from-source build, or something else
>> (e.g. a Python 2.7
for example, if you had a valid RFC 2047 encoded Subject but
a broken X-Foo header, you'd at least still end up with a Message object. The
value of the good headers would be things from which you can get the unicode
value, the raw bytes value, parse its parameters, munge it, etc. whil
e what we implement in email.
Just as a point of order, to the extent that we're discussing generic
approaches to similar problems across multiple modules, it's okay that we're
having this discussion on python-dev. But the email-sig has put in a lot of
work on specific API and
ader("From", "Accented Bàrry ")
>m.add_body("Hello Barry")
Very often you'll start with a template of a message your application wants to
send. Then you'll interpolate a few values into it, and you'd like to easily
convert the result into an RFC valid
should have the option to leave
the bytes of that payload in a disk cache and transparently load it when
necessary.
I think we should keep that in mind, but it's way down on the list of "gotta
haves" for email6.
-Barry
signature.asc
Description: PGP signature
___
one else see Stephen's mail via the list (as opposed to
>being a direct recipient)?
I remember seeing a message from Stephen on this topic, but I didn't read it
though and it's deleted now ;). I don't use gmail regularly.
See also: http://wiki.list.org/x/2IA9
le.
These docs are better off in the wiki than in the source tree.
-Barry
signature.asc
Description: PGP signature
___
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
agree that the wiki feels less official, or perhaps that it *should*
feel any less official. It's an important source of Pythonic information, and
to me it feels much more inclusive and open.
-Barry
signature.asc
Description: PGP signature
___
Pyt
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
>-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant and current.
I'm sure you don't think the Python wiki is useless, right? ;)
-Barry
signature.asc
Des
an be handled by the rare footnotes or whatever.
IMHO of course,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
On Sep 23, 2010, at 10:43 AM, Jesse Noller wrote:
>On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw
>wrote:
>> On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
>>
>>>-1 on wiki; wikis are where good information goes off to die.
>>
>> Well, *all* documentatio
to help garden or reorganize the wiki?
-Barry
signature.asc
Description: PGP signature
___
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
get good
contributors and the rest of the community starts linking to wiki urls, it
will feel (more) official.
Anyway, it's all kind of secondary to actually writing stuff down.
If Brett's going to do the work, then he gets to decide. :)
-Barry
signatur
it PEP 3333, then? ;-)
That works for me.
-Barry
___
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
ld keep a mapping from new to old though. If that's not
possible within the hg repository, can we at least generate a text file or
some such and commit that?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-
improve the world of open source mail archivers by getting
involved in the Mailman project and helping us build the next generation
archiver. :)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
dule.)
I don't think it should be in the gc module, but I would prefer it be enabled
and controlled through a separate module, rather than something Python does
automatically for your convenience.
-Barry
signature.asc
Description: PGP signature
___
Py
fable change so I see
no reason to keep the old tags (we can decide later if we'll want new tags in
the main Python repo).
>- get rid of all other tags
+1. We'll always have the Subversion repository for the historical record.
It'll make future mining a bit more difficult
or about the same amount of
babysitting as the current Subversion repository? I would think no more and
Subversion hasn't been much of a problem.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://
, let's not let it wait
until Pycon 2011 (*2 years* after pronouncement) [1].
-Barry
[1] Apologies for sounding critical of any individual - that's not my intent.
Dirkjan and folks have done a lot of great work to this point and ISTM that
we're *really* close. Le
hange should be
accepted or not. A reviewer often wants to do a build with the changes, test
them on various tasks and application, run the test suite, etc. For this,
"merge" is much better than patch(1).
-Barry
signature.asc
Description
problem halting a review right there and asking the
developer to ensure a conflict-free merge.
It's of course at the reviewer's discretion to assist them with this (e.g. by
branching their branch, resolving the conflicts, committing and publishing
this clean branch, for the original deve
On Sep 30, 2010, at 12:04 AM, Antoine Pitrou wrote:
>On Wed, 29 Sep 2010 17:30:10 -0400
>Barry Warsaw wrote:
>> One other thought: IME patches in general are suboptimal to
>> branches, so I think we should be encouraging people to publish
>> their branches publicly
The torrential rains are causing havoc with my internet, so apologies for
replying out of sequence.
On Sep 30, 2010, at 07:17 PM, Stephen J. Turnbull wrote:
>Sorry for following up to myself, but this typo might be very
>confusing:
>
>Stephen J. Turnbull writes:
> > B
iewed for the good of the project.
* Have a dispute resolution process. If a reviewer and coder can't agree,
appeal to a higher authority. As review team leader, I did occasionally
have to break ties.
* Record the reviewer in the commit messages. We had highly structured commit
message
On Oct 01, 2010, at 01:09 PM, Stephen J. Turnbull wrote:
>Barry Warsaw writes:
>
> > I should note that I don't particularly like colocated/named
> > branches. I personally much prefer separate directories for each
> > feature or bug I'm working on. It helps m
he system
>running, and the PostgreSQL database has really validated it's
>own claim of being the world's most advanced open source
>database.
Agreed! Roundup has been a joy to use. Martin is to be profusely thanked too
for all of his ongoing work on our python.org reso
e the fix really is trivial,
or a change is large but mechanical, or when no reviewer can be found for a
time-sensitive fix (very rare). You at least need to record the rubber stamp
in the commit message, and be prepared to defend it if it trips up someone's
post-commi
match on bare .so. not good for non-distutils based build
processes.
Do you have any other ideas? If not, what would your preference from the
above be? Right now I think I'd go with changing the PEP 3149 naming scheme
to not end in .so (i.e. option #1).
Cheers,
-Barry
signatur
On Oct 02, 2010, at 02:24 AM, Antoine Pitrou wrote:
>On Fri, 1 Oct 2010 20:06:57 -0400
>Barry Warsaw wrote:
>>
>> With my branch, you'll end up with this in /tmp/python:
>>
>> bin/python3.2m - the normal build binary
>> bin/python3.2dmu -
no automatically generated link to the review, but I did add some
comments to the Rietveld issue you linked to in one of your comments.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On Oct 02, 2010, at 10:36 AM, Georg Brandl wrote:
>Am 02.10.2010 00:06, schrieb Barry Warsaw:
>
>> The reason is that the import.c logic that uses the struct filedescr
>> tables built from _PyImport_DynLoadFiletab are just not smart enough
>> to handle this case. All i
On Oct 02, 2010, at 04:50 PM, Nick Coghlan wrote:
>On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou
>wrote:
>> On Fri, 1 Oct 2010 20:06:57 -0400
>> Barry Warsaw wrote:
>>>
>>> With my branch, you'll end up with this in /tmp/python:
>>>
ecessary low-level stuff to allow the distro installation
scripts to move things around and create the symlinks after the fact. This
would mean that other distros (or from-source installers) wouldn't benefit
from the isolation feature without some extra work on their part though. It
w
On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>Besides, mingling different installations together makes uninstalling
>much more difficult.
Not for a distro I think.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailin
On Oct 01, 2010, at 07:36 PM, Benjamin Peterson wrote:
>2010/10/1 Barry Warsaw :
>> I can think of a couple of ways out, none of which are totally
>> satisfying. Probably the easiest out is to change the PEP 3149
>> naming so that the files don't end in &qu
On Oct 04, 2010, at 09:10 PM, Antoine Pitrou wrote:
>On Mon, 4 Oct 2010 14:41:11 -0400
>Barry Warsaw wrote:
>>
>> For a distro, all those Python binaries have to go in /usr/bin. We
>> already symlink /usr/bin/python to pythonX.Y so I don't see the harm
>> in
esn't seem to be.
>(this also means that tools such as file managers etc. may not display
>the file type properly)
Okay. I'll try to modify the patch to put the build-flags before the .so when
--enable-shared is given.
-Barry
signature.asc
Description: PGP signature
___
On Oct 05, 2010, at 10:45 AM, Jeroen Ruigrok van der Werven wrote:
>-On [20101004 20:48], Barry Warsaw (ba...@python.org) wrote:
>>On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>>
>>>Besides, mingling different installations together makes uninstalling
>>>mu
ll cause problems on
>FreeBSD and probably the other BSDs (DragonFly, NetBSD, OpenBSD) and
>most likely Mac OS X as well.
Fair enough. I will change the patch to move the build flags when
--enable-shared is used.
-Barry
signature.asc
Description: PGP signature
___
really get involved with, and indeed Mailman has built up a raft of
defense for failures of this kind.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
for
addressing this problem.
-Barry
signature.asc
Description: PGP signature
___
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
faict, distutils2 could easily use it.
In any case, these could be a simple shell script wrapping 'python -m setup'.
It could even take a --use-python-version option to select the pythonX.Y it
used, without having to encode the Python version number in the script name.
-Barry
sign
On Oct 08, 2010, at 11:04 AM, Toshio Kuratomi wrote:
>python-setup is a lot like python setup.py
>pysetup is shorter
>pyegg is even shorter :-)
wfm!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@p
in consideration when changes are discussed. But ultimately, Python
must evolve to stay relevant or it will die. This is where competing design
trade-offs must be discussed. If not here, by us, then where and by whom?
-Barry
[*] Mostly instituted to allow alternative implementations to catch
On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>Right. That's where I was going with my comment to Barry about the
>Received headers. Even if email isn't going to serve clients working
>with wire format, it needs to deal with those headers. But where I
>think
setup.sh' (or whatever) take a --python-version
option to select the python executable to use.
Whatever solution is implemented definitely needs to take the
multiple-installed pythons into account.
-Barry
signature.asc
Description: PGP signature
___
)
>+TESTFN, self.tag, __debug__ and 'c' or 'o'
You might want to use imp.cache_from_source() instead for consistency.
>
> @unittest.skipUnless(os.name == 'posix',
> "test meaningful only on p
the bug.
This only happens on Ubuntu 10.10 machines (afaict so far), both i386 and
x86_64. It does not happen on Ubuntu 10.04 64bit VMs, nor does it happen on
Debian squeeze.
I'll continue to investigate, but since it's damn perplexing I just wanted to
see if anybody had any thoughts o
On Oct 14, 2010, at 10:29 AM, Guido van Rossum wrote:
>Could it be IPv6?
I don't think so. I have IPv6 disabled on at least one of the machines.
Also, I'm sure this failure did not occur before Ubuntu 10.10 final.
It also fails on Python 3.1.
-Barry
signature.asc
Description:
bet those Ubuntu buildbots are
not running Maverick.
Oh well, mystery solved at least. I'll work on a patch.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
nge too, and since it's a generated file, I think svn blame on configure is
kind of useless.
Should we appoint an autoconf BDFL who can commit changes after configure.in
is changed? Is it possible to pin the autoconf version (not just floor it)?
-Barry
signature.as
On Oct 14, 2010, at 09:11 PM, Martin v. Löwis wrote:
>> I don't see it as any more of a problem than upgrading against other
>> dependencies (like gcc?).
>
>Ok, so let's drop the requirement then.
Good for me. Is there a place where this requirement is documen
bout freezing the
>ABI in 3.2.
Yes, but there's less than a month left before 3.2 beta 1, and then it *will*
be too late, at least for this release.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.o
p:`3149`.
>> +
>
>Needs a versionadded. Also, I think we at least tried to maintain a rough
>alphabetical order of sys members...
Thanks, good catch.
r85571
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
Raymond; I've always used 'accepted' to mean an approved patch.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
ulate_path) and the import machinery (import.c, zipimport.c), because
>gdb does sometimes crash (for various reasons) and because the import
>machinery is fragile and difficult to understand.
You are also a master of the understatement! :)
-Barry
signatur
contains guides to porting Python code and C code, but I think it
should also contain pages that coordinate porting efforts for packages on
Cheeseshop and in distros.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
t;follow the function calls to get the encoding.
That's exactly what I was looking for! Thanks. I think you've learned a huge
amount of good information that's difficult to find, so writing it up in a
more permanent and easy to find location will really help future Python
develope
this year, not next :). +1 from
me!
-Barry
signature.asc
Description: PGP signature
___
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
ication
> does not get harmed.
>
> As a side note - I don't think two release candidates are really
> necessary. So if it helps, it may be reasonable to drop one of them.
> OTOH, I don't mind having two RCs, either.
>
> Regards,
> Marti
source ones (svn, hg,
>bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
t;within the standard library, but I don't think it is a price worth paying in
>this particular case.
+1 (or more). :)
or-maybe-you'd-prefer-more-^L-y y'rs,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing l
ile would cause.
-Barry
signature.asc
Description: PGP signature
___
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
1401 - 1500 of 2826 matches
Mail list logo
