l want users to be able to type 'python' at a shell prompt and
get the interpreter.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
hink it's necessary to change Python 2's build. Distros
can easily do it, pointing to the PEP for justification. But I'm also not
strongly opposed, so -0 from me.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://m
e could also shorten the Subject prefix that
Mailman adds, or remove it entirely. I'm not so much in favor of total
removal, but [PyCommit] or [PyHG] or some other suggestion might work.
-Barry
signature.asc
Description: PGP signature
_
There is a break with convention for the include folder name:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
What does the "m" mean?
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
?
Because I have a contribution to PyCXX to use a new API that
replaces PyCObject_AsVoidPtr I'm not stuck. But I'm sure I'm not
the only python user that uses PyCObject_AsVoidPtr and will
need a point to the replacement.
Barry
___
Python-D
redefining the PATH to include the directory that the
>interpreter named "python" is in or by creating an alias for python to the
>proper interpreter.
I personally would prefer aliasing rather than $PATH manipulation.
-Barry
sign
projects, we have found the quality and
>quantity of patches went up *significantly* when we made it easy for
>somebody who doesn't work on the code all the time to use this workflow
>(fork to a public repo, clone, hack, commit, push, request a pull).
+1. 'Branches' are be
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
hg and git users, so maybe it's just the
nature of the tools. In which case, I'm fine with whatever works better for
Python.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On 7 Mar 2011, at 01:46, Ned Deily wrote:
> In article <5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org>,
> Barry Scott wrote:
>> There is a break with convention for the include folder name:
>>
>> /Library/Frameworks/Python.framework/Versions/3.2/include/py
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
;s new";
> there is an item about it in the "porting to 3.2" section.
O.k. I see that now. I searched for the API call that vanished and came up
empty. I did not think to search for cobject or read the porting section.
BTW the link
s when used:
>
> http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12
I changed my testing code for PyCXX to run python -W default and did
indeed get a nice message:
Demo/Python3/test_simple.py:1: PendingDeprecationWarning: The CObject API is
depreca
depend on the batteries-included version in 3.3, or a
standalone backport for older Pythons.
Guido's already pronounced that it will be 'packaging' in 3.3.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev
#x27;t be mandatory (thus the informational PEP), but it should be
formalized as the preferred way to introspect a module for its version
number. I think there should be ways to spell this easily if the information
is provided to packaging/distut
hat mode of operation?
If so, the devguide could describe that as a transitional step from the old
svn way of doing things.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
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
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. Not that some Bazaar users don't use rebase,
but I just don't think it's that common (John can correct me if I&#
to maintain, and because landings are
serialized, long test suites can sometimes cause significant backlogs. Other
than during the Pycon sprints, the backlog probably wouldn't be that big.
Another complication we'd have is running the test suite cross-platform, but I
suspect that a
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
bisect plugin too much, but I think by default it only
follows commits on the main line, unless a bisect point is identified within a
merge (i.e. side) line. So again, those merged intermediate changes are
mostly ignored until they're needed.
-Barry
> mailing list. Is there not some way to automatically collapse a series of
>> local commits into one large commit when you do the push?
>
>There is, but this is again "changing history", with all the possible
>benefits and caveats that have been shown in this threa
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
; +1 on having a standard place to look for version info.
>
>I believe __version__ *is* the standard (like __author__). IIRC it was
>proposed by Ping. I think this convention is so old that there isn't a
>PEP for it. So yes, we might as well write it down. But it's really
>
ping
>>
>> If you have to have Subversion, CVS, or RCS crud in your source file, do
>> it as follows.
>>
>> __version__ = "$Revision: 88433 $"
>> # $Source$
>
>This should be updated (or rather, removed) now that we use Merc
gate, IMO.
I think it would be good to have the option to do either.
-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
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.a
hs are created equal, so it's not possible to
e.g. have log or bisect suppress one path containing feature sub-commits from
the point of departure to the point of recombination (merge).
-Barry
signature.asc
Description: PGP signature
___
Python-Dev
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: PG
> collapsing.
>
>Ah. We don't support this kind of development - no new named branches
>are allowed in the central repository.
It does sound like that restriction is a source of friction for us.
-Barry
signature.asc
Description: PGP signature
___
30m
'make testall' : 35m
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,
you could run your localized tests, and then a set of tests that run in just a
minute or two
erence to
__version__ I found was in a file called subproc.py posted to comp.lang.python
by Ken Manheimer. It contained a CVS expanded $Revision$ keyword.
The message is dated January 12, 1995.
-Barry
signature.asc
Description: PGP signature
___
Python-De
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/pyt
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,
&
make quicktest' isn't really being honest with us . We
should fix it or remove it.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
;bout! And the run time is
totally reasonable without halving the test run. I don't think those 5
slowest tests would be missed in a smoke test.
Any objections to adding those slowest 5 tests to the blacklist, and -j5 to
quicktest for Python 3.3?
-Barry
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
either).
It can't without some refactoring, and you can't set EXTRATESTOPTS=-j4 either
because TESTOPTS includes -l and regrtest complains that -l and -j are
incompatible.
But I agree it would be nice if the test suite automatically took advantage of
more cores where availab
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 proble
basic arithmetic
>functionality (or even changes those parts of the system) are pretty low, so
>repeatedly running those tests simply because they run fast gives a false
>sense of security.
Not if you keep in mind the appropriate use case for each of the separate make
test targets.
-Bar
nuing this thread. I've explained that I'm not
promoting a quicker way of running the tests in lieu of the more thorough test
suite. I'm looking to fill a very specific use case.
Anyway, there's issue 11651 now too.
-Barry
signature.asc
Description: PGP signature
___
a quick test you could run in that case which didn't
increase that race window. I think the practical effect of not having a
simple, fast smoke test will be to do *less* testing when you hit the merge
race, and just let the buildbots sort it all out. You'll probably win most of
the time
be not working quite right with regrtest's cd'ing to
/tmp. When I build and run the tests out of /tmp (i.e. a non-ecryptfs) with
-j100 it completes in under 3 minutes. Hopefully I can investigate more later
today.
-Barry
signature.asc
Description: PGP signature
__
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.
itical
tale full of intrigue, subterfuge, fast cars, Matt Damon, sharks with frickin'
laser beams attached to their heads, and downright redonkulousness. If you
want the full gory details (or just want to help make the most awesome Python
editing mode even awesomer), come join us on python-m...@p
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
should be okay
to back port.
Please comment here or in the tracker for issue 11715.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
ity patched version of old Python" seems unlikely.
I'll just plead as RM for 2.6 that it's not as unlikely as it seems :).
I'm happy to defer to MvL on its (non) applicability to 2.5.
Cheers,
-Barry
signature.asc
Description: PGP signature
__
nce is that even the simplest bug fix
can change behavior, but a build system fix or doc fix will not.
I agree with the position that back porting such fixes should not be required
but also aren't prohibited.
-Barry
signature.asc
Description: PGP signature
hon.org/issue11715
(Hey, tracker voting would be a cool GSoC project perhaps)
-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
k port the patch to 2.6 later should it be
necessary, I leave it alone. I think we're still due one last bug fix release
of Python 3.1, right? So that leaves applying this patch to 2.7, and 3.1
through 3.3.
-Barry
signature.asc
Description: PGP signature
_
I just checked in PEP 396, Module Version Numbers. This is an informational
PEP describing how to specify version numbers using the __version__
attribute. This has already made one round through distutils-sig so it's time
to post it here. Comments welcome of course!
Cheers,
-Barry
P.S.
s to run it once.
I'm going to apply the patch to Python 2.7, 3.1, 3.2, and 3.3 tomorrow.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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
act that the version is kept
in an external file doesn't change any of the recommendations the PEP is
already making.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
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
source file or
> in the setup.cfg file, and the PEP describes how to get that info from
> the other place. My personal opinion is that the approach using
> pkgutil.get_distribution should be much less prominent than the one
> putting the version in the Python code.
It is al
ed PEPs to define the details of
how that would work. I'd be happy to update the Deriving section of PEP 396
with any such recommendations. That section isn't meant to be definitive or
even all-encompassing. It's just meant to give some ex
plete, or all-encompassing. Other
approaches are possible, and some included below may have limitations
that prevent their use in some situations.
Does that help?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
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
ield from PEP 345, but
I think those cross-references are fine, because it's just referring to the
information contained there.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
"pkgutil" if you want to provide a __version__
>attribute.
I'm not convinced there's consensus on that, i.e. that the version string
should go in setup.cfg if it exists. It doesn't help that the pkgutil API for
doing that is pretty ugly.
>Barry is welcome to make a
pecifying the __version_info__ tuple in more detail in
either PEP 386 or 396. I think more detail should go *somewhere*, and it
feels like it could go in either PEP. Maybe Tarek can chime in on that.
>The *really* nice bit is that you can do:
>
>if sys.version_info >= (2, 6)
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
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
helpful if there were bugs for any such issues.
Cheers,
-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/opti
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
ess the code
>has a bug.
I would agree. Use asserts for "this can't possibly happen "
conditions.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
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
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
thing that must go into 2.6.7, please be sure
there is a tracker issue for it, that 2.6 is marked as being affected, and
with a release blocker priority.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@pytho
n.org/download/releases/2.6.7/NEWS.txt
Many thanks go out to the entire Python community for their contributions
great and small.
Enjoy,
-Barry
(on behalf of the Python development community)
signature.asc
Description: PGP signature
___
Python-Dev mailing
of supported derivatives of Ubuntu offering
additional desktops, such as KDE (Kubuntu) and Xfce (Xubuntu).
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
hoices,
I still think I'd come down on adding a new function and shutil.chown() seems
an appropriate place for it.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
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
h
pypi.python.org/pypi'
>>>
>>> If Tarek (or perhaps Eric) agree that it is appropriate and otherwise
>>> innocuous, then Martin and Barry can decide whether to include in 2.5/2.
>6.
>>
>> I don't plan any further 2.5 releases, so unless a critical
config.webservice.hostname,
config.webservice.port,
config.webservice.api_version,
(resource[1:] if resource.startswith('/') else resource),
)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing
nt x
>
>That's a case where I'd be likely to use even more than two indentation
>levels. Usually, though, I try to refactor the statement so it fits
>on one line.
That's a recommendation I can definitely get on board with! I do exactly the
same thing, although some
these cases where a single indent is fine:
x = some_really_long_function_name(
an_argument,
another_argument,
and_a_third_argument)
foo(x)
---
d = dict(
a=1,
b=2,
c=3,
d=4)
return d
Does that cover it?
-Barry
2.6.7/NEWS.txt
Many thanks go out to the entire Python community for their contributions and
help in making Python 2.6.7 available.
Enjoy,
-Barry
(on behalf of the Python development community)
signature.asc
Description: PGP signature
___
Python-Dev ma
t;Anthony Baxter "
>> imported
>> gpg: WARNING: digest algorithm MD5 is deprecated
>> gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more
>> information
>> gpg: key ED9D77D5: public key "Barry A. Warsaw " imported
>> gpg: To
e should be marked as a release blocker for 3.2.1 - what do
>others (particularly Georg, of course) think? While it does appear to have
>been broken for some time, it seems a bit too serious to leave until a 3.2.2
>release.
Sounds bad ;). I marked it a release blocker, but of cours
pythonv_3.3-1_i386.deb
>
>and removed using
>
>sudo dpkg -r pythonv
>
>I can make this Debian package available for download, if anyone wants it.
Is the Debian packaging branch available too? I'd be happy to throw that in
my PPA for Ubuntu
- it's many many minutes at 100% CPU) but
>eventually comes up with the .deb.
Ah, no I don't think that'll be helpful. I can probably reuse the python3.3
packaging stuff to do a PPA. (It takes that long because it basically does a
`make install`.)
-Ba
certainly wouldn't be the stdlib module most likely to be
>> broken by OS changes, in comparison to e.g. shutil, threading...)
>>
>
>And if we gain Carl as a Python committer to help maintain it, then I'd say
>it is worth doing for that reason
. I just added everything that
came from `find Lib/packaging -type d`.
Cheers,
-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.pyt
rs to
meet and work on improving Python!
Cheers,
-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/p
: Draft
>+Status: Accepted
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 13-Feb-2009
>-Python-Version: 3.x
>+Python-Version: 3.3
> Post-History:
Please add a Resolution header as per PEP 1.
Thanks!
-Barry
signature.asc
Description: PGP signature
understand (from the
>buildbot instructions) that the best source of some of the external
>dependencies
>(bz2, Tcl/Tk, openssl etc.) is still the SVN repo.
In fact, it's also not entirely true that svn isn't being updated. We're
still cutting any 2.5 and 2.6 releases fro
n be painful for folks. It may be difficult to achieve in all cases,
but compatibility should be carefully and thoroughly considered for all
changes, especially in the stdlib, and clearly documented where deliberate
decisions to break that are adopted.
-Barry
signature.asc
Description: P
at just means tweaking sandbox/release/release.py.
Cheers,
-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/optio
Email p...@python.org
Cheers,
-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
brary/__future__).
I think that's right. The change was not made for 2.7.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
# Install the interpreter (by creating a hard link to python$(VERSION))
>+bininstall:altbininstall
>+ -if test -f $(BINDIR)/$(PYTHON); \
>+ then rm -f $(BINDIR)/$(PYTHON); \
>+ else true; \
>+ fi
>+ (cd $(BINDIR); $(LN) python$(VERSION)$(
Ps (the only kind of new
Standards Track PEPs) in the 0XXX numbers, but now that we're all moving to
Python 3 , it seems like segregating new PEPs to the 3XXX range is a bit
contrived.
I think filling up 0XXX is probably fine.
-Barry
signature.asc
Description: PGP signature
_
pecially interested in anyone with a working program that uses
>email in 3.2: it should be completely backward compatible, and if it
>isn't I want to know ASAP.[*]
It'll take some time to digest, but congratulations RDM! You've accomplished
an impressive milestone.
-Barry
good, and that should be preserved. The presence or not of some
test.support.unlink documentation isn't going to make the search results that
much better or worse (there's already 14 hits).
Cheers,
-Barry
signature.asc
Description: PGP signature
__
ion, I think the
>test.support dilemma will solve itself.
Let's see!
I think the devguide should document things like "how to submit bugs", "how to
use Mercurial", "how to propose changes to Python", "how to ensure code works
across all existing interpre
1701 - 1800 of 2826 matches
Mail list logo
