nother module in
>the same package) is a code stench far worse than anything else PEP8
>proscribes.
Maybe we should disable it for anything that isn't at the interactive prompt
<0.5 wink>.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v
On Jul 17, 2013, at 09:35 AM, Brett Cannon wrote:
>Or how about dropping the whole ``from ... import ...`` format entirely?
><0.5 wink; seriously, it's implementation is a pain and it has wonky
>semantics>
Yes, let's break *everything* :)
-Barry
signature.asc
D
we as a distro cope with that
>on the technical side (and when we should actually do the switch).
I'm glad Arch is out there hacking at the vines. For whatever part I can play
and for whatever my opinion matters, I would like to keep the
binary specifically so that shifting the default name is more of a
>> convenience than something which might break existing code not ready for
>> the switch.
>
> yeah, this is something that I think should be in the distribution
n3 on at
>least Arch Linux (that change is
>what prompted the creation of this PEP), so "python" should be
>used in the shebang line only for
>scripts that are source compatible with both Python 2 and 3
+1
-Barry
___
Python-D
in the library documents, but especially
there, paragraphs should be wrapped to 79 characters, and can easily be done
without losing expressability.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On Aug 01, 2013, at 11:52 AM, R. David Murray wrote:
>So as we edit the docs, we re-wrap. Just like we do with the legacy
>code :)
+1!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
;useful to see them used in the wild for a while first. We can enhance them
>in 3.5, but premature enhancement is IMHO much more likely to do harm than
>good.
As you can probably guess, I fully agree.
I also agree with Nick's suggestion to remove the advanced ex
rid of that particular albatross! FWIW, I'm still
merging relevant 2.6 changes into 2.7 (or null merging them if not relevant).
Oh, and welcome back Uncle Timmy! (If that's you're real name.)
-Barry
___
Python-Dev mailing list
Python
iewing, testing, developing, or
commenting, that would be greatly appreciated. I will be spending some time
triaging these and any other issues that get identified as possible 2.6.9
candidates.
If you have any questions regarding 2.6.9, please contact me via mailing list
or IRC.
Cheers,
-Barry
support :).
We at the Mailman project like Persona a lot. It'll be the primary way people
can log into Postorius (the new web ui).
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBCAAGBQJSKM3TAAoJEBJutWOnSwa/jP8QAJ4BkV8285TexZq+9GuTwzFf
qx2OlUwtiv6lhDZq9uY0
lly go anywhere that
accepts OpenID, type my OpenID and generally not have to log in again (things
like two-factor auth and such may change that interaction pattern).
Or to summarize to a rough approximation: OpenID is for logins, OAuth is for
scripts.
Persona seems to fit the OpenID use case. You&#x
On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote:
>Which sites exactly? I can login to BitBucket and *.python.org using
>OpenID, not Persona.
I think Persona is just too new to see it around much yet. Or maybe Mozilla
needs better PR.
at you *can* (not *must*) use
free and open services to access our resources.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hey want to own that space themselves, so probably have
no business incentive to support 3rd party systems.
We're open source, and I think it benefits our mission to support open,
decentralized, and free systems like OpenID and Persona.
-Barry
___
Py
. They're lists with some
dict-like syntax.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sep 10, 2013, at 03:57 PM, Antoine Pitrou wrote:
>Le Tue, 10 Sep 2013 09:49:28 -0400,
>Barry Warsaw a écrit :
>> On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>>
>> >The http.client and email.message modules convert headers to lower
>> >case, but k
unsub personalization), those unsub stanzas cannot currently be disabled on a
per-user basis.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
udio recording capabilities and would be happy to generate
some copyright-donated clips for Python. Please contact me off-list if
needed.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
e binary releases, I just build them from MacPorts, so as
long as that still works, I'm happy. (I have a 8mo Air running the latest
Lion and will likely update that when Mavericks is out.)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
h
On Sep 18, 2013, at 03:00 PM, r.david.murray wrote:
>http://hg.python.org/cpython/rev/fb3ad8a749c8
>changeset: 85749:fb3ad8a749c8
>branch: 2.6
>parent: 85735:1b673e0fd8f3
>user:R David Murray
>date:Wed Sep 18 08:49:25 2013 -0400
>summary:
> #14984: only import pwd on
on, etc. -- all
>go in the .rst docs.
That's exactly my own rule of thumb too, so +1.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ed to the source tree for stable releases?
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
decisions
based on all the facts. I understand that Python 2.7 will be around for a
long time, and that it would be very convenient to do this. Why is this not
opening up the door to more new features being added in future Python 2.7
point releases (or any other stable release)?
At least I thin
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
>On 26 Sep 2013 06:53, "Barry Warsaw" wrote:
>>
>> Why does it have to be added to the source tree for stable releases?
>
>If it can get into the installers another way, it doesn't, really. It only
>needs t
ning why *no* other option will accomplish the goal.
>
>This is totally fair and we can expand on it more for sure.
Cool. Maybe in the course of that discussion, a better alternative that
doesn't add a new feature to Python 2.7 will present itself. I really hope
so.
-Barry
signature.
RM, but I'm not (thankfully. :).
I still think it's optimistic to pin any hopes on its widespread availability
in future 2.7 point releases on people's actual systems.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
>On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
>> So, why shouldn't we add enum to the Python 2.7 stdlib?
>Because with PEP453 you can just ``pip install enum34`` it :)
Of course, pip messing with global Python state
removing it will break pyvenv)
I'm sorry that I probably won't be able to engage more on this thread, but I
think my points should be fairly well understood by the PEP czar and RM.
Should the PEP be accepted, I think both of these are good changes
Please add a Discussions-To
header to PEP 3156. See PEP 1 for details.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/
;
>These exceptions were explicitly discussed, and approved in
>consultation with the affected release managers, separately from
>the rest of the PEP. They do not represent a change in policy,
>and must not be considered a precedent for other such exceptions.
Call this the
will be the last official 2.6 release of the series. After this,
we are retiring the 2.6 branch. Speak now or forever hold your peace.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https:
ersions. The backporting PEP will be deferred, for reconsideration
>some time in the future after the initial PEP has been implemented.
+1, since I think there's little disagreement about adding this to 3.4.
-Barry
signature.asc
Description: PGP signature
__
g/download/releases/2.6.9/NEWS.txt
Many thanks go out to the entire Python community for their contributions and
help in making Python 2.6.9 available, especially Jyrki Pulliainen for his
patch contributions.
Enjoy,
-Barry
(on behalf of the Python development community)
signature.asc
Descri
On Oct 03, 2013, at 02:08 PM, Eric Snow wrote:
>On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling wrote:
>> On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
>>> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
>>> +- Issue #19151: Fix docstring and use of _get_sup
ved processes on these
platforms.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 11, 2013, at 07:24 AM, Ned Batchelder wrote:
>I'd like to suggest that we not consider PEPs to be documentation.
Absolutely +1. That was never the intention behind PEPs.
-Barry
___
Python-Dev mailing list
Python-Dev@python.o
7;s a nice little addition that could be useful, but I don't
care enough to wait for 3.4 to delete similar code in a my own programs.
To bikeshed though: why was `ignored` changed to `ignore`? The former reads
better to me, and I don't think *
or):
To me anyway, the latter sounds better.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote:
>But, to continue to paint the shed, shouldn't it be "ignoring", to match
>"closing"?
Maybe so.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
On Oct 11, 2013, at 08:32 PM, Serhiy Storchaka wrote:
>I am -1 too. But I want to hear more about interact with ExitStack (note that
>ExitStack itself is not widely used in the stdlib).
Yet. :)
-Barry
___
Python-Dev mailing list
Python-Dev@pyth
he relevant issue. Mysterious decisions like this are easy to
miss in the deluge of checkin messages, and don't help promote a transparent
development process.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
On Oct 12, 2013, at 11:19 AM, Brett Cannon wrote:
>Actually thanks should go to Barry who rewrote the language ref docs for
>import.
I can actually say it was fun due to all the great work on importlib. :)
-Barry
___
Python-Dev mailing list
Pyth
ransparent, puts legitimacy at risk, and alienates users and developers who
may not be privileged to those out-of-band discussions.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
ay there wouldn't often be a better way to write
>it...but I can think that it might have utility.
>
>With that change, I'd be +1. With just suppress, I'm -0.
Yeah, I would also be +1 with that.
-Barry
___
Python-Dev mailing li
ange, even if they
disagree with it. Trust is extended upwards when this transparency is
extended downloads. "'Cause I said so" only works at the top of the chain. ;)
I posted my original question because the change seemed so random and
arbitrary, and the commit message didn'
erence is easily explained, understood, and internalized
and that will go a long way to figuring out whether this is a good idea to be
expanded on in the future.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python
) For me, it's
closer to the original intent though because the bare-except combined with the
re-raising of the exception feels kind of like a finally. In both exit paths,
the resource is being released, it's just that you have to know which
"release" operation to perform.
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 1:52 PM
> To: Python-Dev
> Subject: [Python-Dev] PEP: Ordered Class Definition Namespace
>
>
> Currently the namespace used during execution of a class body defaults
> to dict. If the metaclass defines ``__prepare__()`` then the result of
> callin
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 2:52 PM
> To: Émanuel Barry
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP: Ordered Class Definition Namespace
>
> "dunder" names (not just methods) will not be present in
> __definition_order__. I'll a
single byte objects? I think it's still a bit of a pain to extract single
bytes even with .iterbytes().
Maybe .iterbytes can take a single index argument (blech) or add a method like
.byte_at(i). I'll let you bikeshed on the name.
Cheers,
-Barry
_
the desired type.
-Barry
pgpKzXeYAKnPj.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-d
On Jun 08, 2016, at 02:01 AM, Martin Panter wrote:
>Bytes.byte() is a great idea. But what’s the point or use case of
>bytearray.byte(), a mutable array of one pre-defined byte?
I like Bytes.byte() too. I would guess you'd want the same method on
bytearray for duck typing AP
> From: zr...@fastmail.com
> Subject: [Python-Dev] PEP 468
>
> Is there any further thoughts on including this in 3.6? Similar to the
> recent discussion on OrderedDict namespaces for metaclasses, this would
> simplify / enable a number of type factory use cases where proper
> metaclasses are ove
gree with you and Guido. I'm also not opposed to adding a more
direct exposure of getrandom(), but in Python 3.6 only. Like it or not,
that's the right approach for our backward compatibility policies.
Cheers,
-Barry
___
Python-
ay. But let's also not scare people away from Python 3,
because it *can* be very easy to port, and I think there's fairly widespread
agreement that once you're in the Python 3 world, you don't want to look back.
Cheers,
-Barry
ed also
adding an optional count argument? E.g. `bytes.byte(3, count=7)` would yield
b'\x03\x03\x03\x03\x03\x03\x03'. That seems like it could be useful.
Cheers,
-Barry
pgpqmt4qkxOOD.pgp
Description: OpenPGP digital signature
___
Python-De
ts.getrandom() or something related to that.
ISTM that secrets is a somewhat higher level API while it makes sense that a
fairly simple plumbing of the underlying C call should go in os. But I
wouldn't argue much if folks had strong opinions to the contrary
> From: Eric Snow
> Sent: Saturday, June 11, 2016 10:37 PM
> To: Python-Dev; Guido van Rossum
> Subject: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round
> 3)
> The only change to the original proposal
> has been that a manually set __definition_order__ must be a tuple of
> identif
> From: Eric Snow
> Sent: Saturday, June 11, 2016 11:02 PM
> To: Émanuel Barry
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace
> (round 3)
>
> On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote:
> >> From: Eric Snow
&g
for stronger
guaranteed sources of randomness.
For an easy-to-use interface to the random number generator provided by
your platform, please see random.SystemRandom.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
andom() will never block or raise an exception
when only poor entropy is available, then it may be indeed indistinguishably
backward compatible for most if not all cases.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
is
behavior can be changed via the flags argument.
and we don't pass the GRND_RANDOM flag to getrandom().
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail
. This is also
the case in 3.6 but there you can do much better by porting your code to the
new secrets module. Go do that!
>...Anyway, since there's clearly going to be at least one PEP about this,
>maybe we should stop rehashing bits and
provide a
clear, better upgrade path for our users. We've done this beautifully and
effectively via the secrets module in Python 3.6.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
kwards-compatible enough to suit you, please speak up now!
It does seem like a narrow corner case, which of course means *someone* will
be affected by it .
I'll leave it up to you, though it should at least be clearly documented.
Let's hope the googles will also help our hypothetical fu
trust our Larrys, Neds, and Guidos to make the right --or at least *a*--
decision on a case-by-case basis, and if not agree then accept.
Cheers,
-Barry
pgpi_GQ9iz6Hl.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
P
eople's code in ways and places that we can't
predict, and which are very often very difficult to discover.
I guess it all comes down to who's yelling at you. ;)
Cheers,
-Barry
P.S. These discussions do not always end in despair. Witness PEP 493.
pg
On Jun 16, 2016, at 09:51 AM, Random832 wrote:
>On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote:
>> *If* we can guarantee that os.urandom() will never block or raise an
>> exception when only poor entropy is available, then it may be indeed
>> indistinguishably backward c
s of stdlib modules backported
and released as third party packages. Why not secrets too? If such were on
PyPI, I'd happily package it up for the Debian ecosystem. Problem solved
.
But I'm *really* going to try to disengage from this discussion until Nick
g is the
place to report confidential security issues. Thesaurusly suggesting
danger-sig and not just because that sounds so much cooler.
not-a-serious-suggestion-ly y'rs,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
tact security at python dot org.
Cheers,
-Barry
pgp4uD9o3OigK.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
nstable, which will also soon make
its way to Ubuntu 16.10:
https://launchpad.net/ubuntu/+source/python3.5/3.5.2-2
Ubuntu 16.04 LTS currently still has 3.5.1.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
a way to map a requirements.txt into
distro package versions and do the install from the distro package manager,
but that might be useful.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
let's not lose sight of that if this path is taken.
(Personally, I'm +0 on splitting out the stdlib and -1 on micro-splitting it.)
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyt
S release, so we'll only do one major transition before the next LTS.
>From my perspective, that feels about right.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
leaf nodes in there too. Creating a complex dependency graph would
>be a disaster.
Yeah.
Cheers,
-Barry
pgpMeHsirBIoe.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
On Jul 06, 2016, at 10:02 AM, Nick Coghlan wrote:
>On 6 July 2016 at 03:44, Barry Warsaw wrote:
>
>> Projecting ahead, it probably means 3.7 in mid-2018, which is after the
>> Ubuntu 18.04 LTS release, so we'll only do one major transition before the
>> next LTS. Fr
(stable release upgrade approval) to move to the final
release *after* the Ubuntu final release. This isn't great though, especially
for non-LTS releases because they have shorter lifecycles and no point
releases.
Cheers,
-Barry
pgpVIR8scDDik.
cosystem using
dist-packages for PyPI installed packages. Without isolation, it's just too
easy for some random PyPI thing to break your system, and yes, that has really
happened in the past.
So if we go down the path of moving more of the stdlib to site-packages, we
Hello all, and thanks Nick for starting the discussion!
Long wall of text ahead, whoops! TL;DR - everyone seems to agree, let's do
it.
I think the main issue that we're hitting is that we (whatever you want "we"
to mean) prefer to make Python code in the standard library as easily
understandable
Hello,
> From: Steven D'Aprano
> Sent: Monday, July 11, 2016 9:11 AM
>
> This isn't an actual problem that occurred in real code, it's a
> theoretical issue that Emanuel discovered, and by his own admission
> feels that he was doing something dubious ("It may not be the best idea
> to subclass so
27;s all very twisty, and I'm not sure Python is doing anything wrong, but I'm
also not sure it's *not* doing anything wrong. ;)
In any case, the contextlib documentation quoted above should probably be more
liberally sprinkled with salty cave
Why do you need SysArchitecture? Surely the 32bit pythons are registered in the
32bit registry and the 64 bit pythons in the 64 bit registry.
you can side by side install python 3.4 but only if you install 64 bit first
then 32 bit second.
Barry
> On 15 Jul 2016, at 23:20, Steve Dower wr
default for older versions. We did however include the mechanisms from PEP 493
so that end-users and system administrators could make different choices based
on their own assessments and needs.
Cheers,
-Barry
___
Python-Dev mailing list
Python-De
Hello Python-dev,
some time ago I went ahead and implemented a patch to deprecate the invalid
escape sequences (e.g. \c, \g, \h, etc.) in str and bytes literals. The
change itself is pretty straightforward, and shouldn't be hard to review.
The change was split in two patches; one which does the act
code, we should do it. If we can't, we
can't.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
The repos which used to send to Python-checkins no longer do so since their
respective migrations (devguide, peps). I don't know who's responsible for
that, so I figured I'd post here.
-Emanuel
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
free :)
-Emanuel
From: Brett Cannon [mailto:br...@python.org]
Sent: Wednesday, September 07, 2016 5:40 PM
To: Emanuel Barry; python-dev@python.org
Subject: Re: [Python-Dev] Commits to migrated repos no longer sent to
Python-checkins
On Wed, 7 Sep 2016 at 14:24 Emanuel Barry
mailto:vgr
hink it's important to emphasize this to developers.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 13, 2016, at 01:32 PM, Guido van Rossum wrote:
>Confirming, +1 from me. Barry, Nick? You two are the most active
>authors of PEP 1.
+1 for text/x-rst being the preferred. We'd need some time to make it the
default, but I'm generally in favor of that happening. Is
markup plain text?
I don't understand the question: isn't the whole point of reST that it's a
easily readable markup language? Just post the reST!
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
Just one reply seems pretty weak of a push. However, you lose nothing by
submitting it on the issue tracker: https://bugs.python.org
I don’t have a use case for this myself, but we’ll see :)
-Emanuel
From: Python-Dev [mailto:python-dev-bounces+vgr255=live...@python.org] On
Behalf Of Tim Mitchel
ay area.
I'd personally have no problem with adding it to 3.6 and possibly earlier
stable releases, but I'm not an RM of any active releases any more. I'd say,
open a bug, post the patch against the versions you want to see it applied to,
go through the review process, and let the RMs
I am over due providing a patch for a doc issue that was discussed on
the ideas list.
What is the preferred way to provide cpython with a patch these days?
bug report + patch?
pull request on github?
something else?
Barry
___
Python-Dev mailing list
>2 fork, they should not call it Python 2.8 as that could mislead people into
>thinking it was officially supported.
>
>I think the project should be renamed to make it clear that its a fork,
>like Stackless.
Yes, exactly right. It's not sanctioned by the PSF and should not be
eful and it's used in lots of places. Getting rid of cruft like this
is one of the more satisfying edits when dropping Python 2 support. :)
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
suppressing duplicate messages from cross-posted mailing lists is also
>done... likely achieved due to matching Message-Id values.
https://wiki.list.org/x/4030680
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
a from-import-* since
those ignore underscored names by default.
(But then if you use __all__'s it won't happen anyway because you'll never put
'os' in __all__.)
(Aside from the fact that from-import-* is usually bad form, and the problem
with __all__ [1].)
Cheers,
-Bar
On Jan 09, 2017, at 06:23 PM, André Malo wrote:
>- __all__ again: it's tedious and error-prone to maintain.
Only if you use the wrong tools
http://public.readthedocs.io/en/latest/
http://bugs.python.org/issue26632
Cheers,
-Barry
___
Py
701 - 800 of 2826 matches
Mail list logo
