[Python-Dev] Release of a responsive python-docs-theme 2021.5
It’s with great pleasure that I announce that python-docs-theme has been released to PyPI. Thanks to the hard work and patience of Olga Bulat, @obulat, Python’s doc theme is now responsive. Many thanks to everyone who has contributed to this release by filing issues, writing PRs, reviewing PRs, and testing the theme. It was a great team effort. Here are the highlights from the CHANGELOG.rst: - Make the theme responsive (#46) Contributed by Olga Bulat. - Use Python 3.8 for the Github Actions (#71) Contributed by Stéphane Wirtel. - Use default pygments theme (#68) Contributed by Aaron Carlisle. - Test Github action to validate the theme against docsbuild scripts. (#69) Contributed by Julien Palard. - Add the copy button to pycon3 highlighted code blocks. (#64) Contributed by Julien Palard. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/75SE5KPBFEWXOGOAFEKM6FBHJQ3AORXK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?
Thanks Tim. On Tue, May 4, 2021, 11:13 AM Tim Peters wrote: > FYI, I just force-unsubscribed this member (Hoi Lam Poon) from > python-dev. Normally I don't do things like that, since, e.g, we have > no way to know whether the sender address was spoofed in emails we > get. But in this case Hoi's name has come up several times as the > sender of individual spam, and if Hoi is actually a legit member they > should have noticed and spoken up. > > Of course this can't stop them from spamming. Just intended to > increase the effort for them, if they're determined to continue. > > [nothing new below[ > > On Tue, May 4, 2021 at 11:34 AM Jonathan Goble wrote: > > > > I just got one now from the same person on the dependabot thread. > Entirely in Chinese except for "GNU license" in the middle, along with an > attached jpeg of a random SciPy-related tweet (according to Gmail's preview > thumbnail; I didn't actually open the attachment for obvious reasons). > > > > On Sun, May 2, 2021, 5:08 AM Jeff Allen wrote: > >> > >> Yes, I got one from the same address today. Thanks for pointing out > these are individual peformances: it was annoying when I thought it was > spam to the list. > >> > >> Although Hoi Lam Poon is a real (female) name, it may signify a > generated lampoon. > >> > >> Jeff Allen > >> > >> On 23/04/2021 16:38, Nathaniel Smith wrote: > >> > >> I just got the reply below sent directly to my personal account, and > I'm confused about what's going on. If it's just a one off I'll chalk it up > to random internet weirdness, but if other folks are getting these too it > might be something the list admins should look into? Or... something? > >> > >> -- Forwarded message - > >> From: Hoi lam Poon > >> > >> ___ > >> Python-Dev mailing list -- python-dev@python.org > >> To unsubscribe send an email to python-dev-le...@python.org > >> https://mail.python.org/mailman3/lists/python-dev.python.org/ > >> Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/3EA53I3Y72ACEPDVG467NMNTXHRL3NXL/ > >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/JNYRFZ4FTIFUJFS7FPNMKI2HXW7SLL52/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/LFULZM6GLDUAS5SFQ4F454QMRGEH3EGH/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WK4PZC2K72JZERT36QD56FJWJ6FAW4NV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Announcing the CPython Docs Workgroup
Raymond, Anyone can contribute to the documentation and comment, and core devs can accept patches. Nothing changes here. The Steering Council did approve the initial members and charter. The intent has always been to be transparent and open. As discussed at last year's Language Summit, the goal is to build a wider community of documentarians, what I will refer to as the Documentation Team, and to build a Working Group focused on one year to five year priorities. The Working Group will also act as an Editorial Board made up of members who are core developers as well as others who are passionate about documentation and education. On a personal note as I mentioned in the PyCascades Core Dev Panel, I have had a very challenging last year including burnout and depression. I imagine this past year has been hard for many. Any delay in the Docs Workgroup falls squarely on my shoulders. Please assume that there is good intent and transparency behind this workgroup. For the record, the four individuals listed are those that were instrumental in last year's Language Summit presentation as well as Julian Palard who has had a formal role in CPython Documentation. There were many folks that worked on the charter during the last Core Dev sprint who are not in this initial group, but it is my sincere hope that they will apply, as I hope you will, along with any others who are interested. Thanks! Carol On Mon, May 3, 2021 at 1:15 AM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > That seems exclusionary. Right now, anyone can contribute to > documentation, anyone can comment on proposals, and any core dev can accept > their patches. > > In the interest of transparency, can you explain why the other initial > members did not need to go through an application process? ISTM the > initial group excludes our most active documentation contributors and > includes people who have only minimal contributions to existing > documentation and mostly have not participated in any documentation reviews > on the issue tracker. Did the SC approve all the initial members? > > Raymond > > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/MTZNPTQBUURQABJWNLZA26CKA357SWFP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U3YQOU5RVJS3G24UTVGKWPZCAM5FDKU5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Announcing the CPython Docs Workgroup
Hi Raymond, In about a month after the Language Summit, we'll have an open call for applications for the Docs Workgroup similar to how the PSF gets and reviews applications for the Code of Conduct workgroup. Please keep an eye out for an announcement on Discourse, Python-Dev, and the docs-community repo for more information. I already have you on an interest list from last year. Thanks, Carol On Sat, May 1, 2021 at 4:36 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Please add me to the list of members for the initial workgroup. > > Thank you, > > > Raymond > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/DQXRKNTL2XJFRQXS4W777XB6XUOVSINL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XW76K37AU3CP4XKCRO7YSJAYBMUYHNWB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
Luciano,
Thank you for such a thoughtful and eloquent response. Your wisdom is
definitely appreciated, and I agree this is an opportunity to go forward
with more clarity. I'm so proud of the Python dev community for their
thoughtful and respectful conversation.
All, Without the efforts of Larry, Guido, Mark, Lukasz, Luciano,
the pydantic/FastAPI folks, the Steering Council and their willingness
listen and problem solve, the outcome would have been far less appealing
and useful.
Thank you!
Carol
On Wed, Apr 21, 2021 at 4:26 PM Paul Bryan wrote:
> I agree, that's duck typing with a protocol, and precisely the tedious
> type style I would want to avoid.
>
> I don't know what would be a good suggestion. Something where you
> reference a "fully equipped" type and cherry pick the attributes you want?
> Something like `Protocol[Duck, ("quack", "waddle")]`?
>
> Paul
>
>
> On Wed, 2021-04-21 at 16:13 -0700, Jelle Zijlstra wrote:
>
>
>
> El mié, 21 abr 2021 a las 15:30, Paul Bryan () escribió:
>
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this
> duck to quack; someone else will want it to waddle. I don't see how type
> hints could reasonably support "file like object" in the duck type sense
> (unless the consumer were to specify the exact attributes of the duck it's
> interested in, which I fear would become a tedious type writing style). '
>
>
> This approach (a Protocol that declares exactly what you need the
> file-like object to do) is in fact what we've been doing in typeshed, the
> repository that provides type hints for the standard library. For those
> unfamiliar, it would look something like this:
>
> from typing import Protocol
>
> class SupportsRead(Protocol):
> def read(self) -> bytes: ...
>
> def uses_a_file(f: SupportsRead) -> None:
> f.read()
>
> That's somewhat tedious, to be sure, but it is working duck typing.
>
>
>
> I too have sensed static typing driving the typing development agenda in
> Python recently, causing other typing methods to take a back seat, so to
> speak. I add my voice to those requesting Python handle other typing
> methods.
>
> Barring an innovation to allow a "subset" of a type to be declared in a
> type hint, I would conclude that static typing and duck typing are
> diametrically opposed. If we agree that both are valuable, developers could
> build consensus on that point, and work to ensure that one does not move
> forward at the expense of the other.
>
> What would you suggest? Should the syntax for declaring Protocols be more
> concise?
>
>
>
> Paul
>
> On Wed, 2021-04-21 at 12:36 -0700, Christopher Barker wrote:
>
> Thanks Mark for posting this. I know some of us are uneasy about the pace
> of the typing train
>
> On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith wrote:
>
> > If you guarded your code with `isinstance(foo, Sequence)` then I could
> > not use it with my `Foo` even if my `Foo` quacked like a sequence. I was
> > forced to use nominal typing; inheriting from Sequence, or explicitly
> > registering as a Sequence.
>
> You say this like it's a bad thing, but how is this avoidable, even in
> principle? Structural typing lets you check whether Foo is duck-shaped
> -- has appropriate attribute names, etc. But quacking like a duck is
> harder: you also have to implement the Sequence behavioral contract,
> and realistically the only way to know that is if the author of Foo
> tells you.
>
>
> But that's not what duck typing is (at least to me :-) ) For a given
> function, I need the passed in object to quack (and yes, I need that quack
> to sound like a duck) -- but I usually don't care whether that object
> waddles like a duck.
>
> So yes, isinstance(obj, Sequence) is really the only way to know that obj
> is a Sequence in every important way -- but if you only need it to do one
> or two things like a Sequence, then you don't care.
>
> And this is not uncommon -- I suspect it's very rare for a single function
> to use most of the methods of a given ABC (or protocol, or whatever).
>
> And a lot of the standard library works exactly this way. Two examples
> (chosen arbitrarily, I just happen to have thought about how they work):
>
> json.load() simply calls ``fp.read()``, and passes the result on down to
> json.loads(). That's it -- no checking of anything.
>
> If fp does not have a read() method, you get an AttributeError. If fp has
> a read() method, but it returns something other than a string, then you get
> some other Exception. And if it returns a string, but that string isn't
> valid JSON, you get yet another kind of error.
>
> In short, json.load(fp, ...) requires fp to have a read() method that
> returns a valid JSON string. But it doesn't check, nor does it need to, if
> it's getting an actual io.TextIOBase object. Is that the right one? I'm not
> totally sure, which
[Python-Dev] Re: [Steering-council] Re: Steering Council reply regarding conduct (was Re: Steering Council update for February)
Martin, The decision regarding the action and email was unanimous (5-0). It was discussed in our March 15 and March 22 Steering Council meeting. This post and this other post ( https://mail.python.org/archives/list/python-dev@python.org/message/J5GR6YVIVWQ2VPLISAGBQH3UQN4YWAXS/) provides context on our discussion and actions. Regards, Carol On Tue, Mar 23, 2021 at 1:58 PM Martin Dengler wrote: > On Tue, Mar 23, 2021 at 12:02:38PM -0700, Python Steering Council wrote: > >From Thomas Wouters, on behalf of and with full support of the Python > Steering > >Council: > > [use of SC power; specifically, PEP-0013.Powers.2: 'Enforce ... code of > conduct'] > > From PEP 13[^1] > >>> To use its powers, the council votes. > [...] > >>> Whenever possible, the council's deliberations and votes shall be held > in public. > > Please share the deliberations and votes. > > Martin > > [^1]: https://github.com/python/peps/blob/master/pep-0013.rst > ___ > Steering-council mailing list -- steering-coun...@python.org > To unsubscribe send an email to steering-council-le...@python.org > https://mail.python.org/mailman3/lists/steering-council.python.org/ > Member address: willi...@gmail.com > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RXRQJJG2KOWN7SQQ6DQH6GW4OMH4TDD2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council update for February
GitLab has just posted the following re: default branches. https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ Please take a moment to pause before posting. Please consider whether additional comments are constructive. I'm concerned that rehashing the same arguments will reflect poorly on the Python Core Development community. Thank you. On Wed, Mar 10, 2021 at 4:35 PM Jonathan Cronin wrote: > > > > On Mar 10, 2021, at 4:45 PM, David Mertz wrote: > > > > In contrast, the "master" used in version control directly borrows from > so-called "master/slave network architecture." I saw in this thread one > implausible argument that it was intended in the sense of "magister." I > don't believe it, but even if we stipulate that whoever first used the word > in relation to version control meant that, nearly everyone else who > discusses it means "master/slave." > > I don't think it derives from "master/slave network architecture.”. I > think it derives from the use of “master” > to denote an instance or prototype that is used to create identical copies > or replicas, a usage that predates networking, as in master tape, master > print, and, (perhaps archaically for you :)), mimeograph master. > > Irrelevantly, I also think all (almost all?) uses of "master/slave” to > describe network architectures are lazy; there is a better existing > description, e.g. “active/passive”, “polling” etc. > > Jonathan > > P.S. My preference would be “mainline” over “main”. I like railroad > version diagrams. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/DONBBIFH7LESW3D7JSB4IC5Y7GAFSFGQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YERKDBAA74M75VQC7QPEH5PUC4SVPBHU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council update for February
I echo Barry's earlier response. To directly address individuals who object to renaming the branch: I respect your opinion. As I weigh the benefits of keeping the status quo with the benefits of changing, I see the change as a temporary inconvenience to update the branch once in order to open the door to the benefits of conforming to the new industry norm and the simplification that brings to tooling configuration and user/contributor documentation. Thanks. On Wed, Mar 10, 2021 at 7:49 AM MRAB wrote: > On 2021-03-10 15:17, Antoine Pitrou wrote: > > On Wed, 10 Mar 2021 14:23:33 + > > David Mertz wrote: > >> > >> Renaming main branches as 'main' is currently predominant practice on > >> GitHub (and more broadly in Free Software communities). Python doesn't > >> need to cling to an old name based on a tired argument that political > >> sensitivity is a creeping plot to destroy old "fun" prejudices and > >> injustices. > > > > Uh... Since you're putting "fun" in quotes, I assume this is quoting > > someone else? (who?) > > > It's not a quote, it's Irony punctuation (in this case, used to indicate > sarcasm): > > https://en.wikipedia.org/wiki/Irony_punctuation > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RJUCHSTSFC6IJPILRPYFQYY437NEOQ4G/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BZQPFFBS6LVJQB23AYRBCUUTMNZG2HGF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?
Hi Julien, I think that there are two items to consider: - `needs_sphinx` in `conf.py` - setting for Sphinx in `cpython/Doc/requirements.txt` I believe that the `needs_sphinx` field identifies the minimal version of Sphinx that can be used to build the docs. The actual version that is used to build the docs is in the `requirements.txt` file. On Wed, Jan 13, 2021 at 7:29 AM Serhiy Storchaka wrote: > 12.01.21 22:38, Julien Palard via Python-Dev пише: > > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > > > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that > > we could work around, some are bit harder, so we may need to bump > > `needs_sphinx = '3.2'` (currently it is 1.8). > > Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it > cause problems with builting documentation on Ubuntu? > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/EJWTFPHZUX522RNCTIGAAOHWD23VD7NQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S53K4P272EE73EF2NLZWS5DVNR6VJG3R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC 2020 recommendation for PEP 634
On Tue, Dec 8, 2020 at 7:32 AM Paul Moore wrote: > On Tue, 8 Dec 2020 at 15:19, David Mertz wrote: > > > > As a candidate for the new SC, if elected I would certainly find it more > useful to have more specific thoughts from the outgoing SC than simply "we > recommend." How divided was the vote? Who took the sides? What were the > major points of disagreement? That sort of thing. > > My understanding was that the outgoing SC would fully brief the new > SC. The mail here is simply a summary view for the information of the > wider python-dev community. > Paul, this is a good summary of why the SC posted its recommendation for the incoming SC. > Personally, I'm not sure how I feel about it. It's very much a good > thing in terms of transparency, something the SC seems to still be > trying to find the right balance on, but I feel that having seen this, > I'd be left with a lot of unanswered questions if the incoming SC ends > up rejecting the proposal, and therefore I don't really know how to > view the information with that context. > That's a fair point. We expect to do a hand-off meeting with the new SC to discuss. Although personally I would like to see a pattern matching solution, we didn't have consensus within the existing SC for many of the reasons already discussed in other posts. We felt it was best to give the new SC an opportunity to make the decision. > Paul > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/KA3MJOZIKMJ3P2UCAYOJEGJASNF72GD5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EBS45757GOISQO6S7JY47F35WJUPQDOF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On Tue, Nov 10, 2020 at 8:07 AM Mats Wichmann wrote: > On 11/9/20 12:46 PM, Mike Miller wrote: > > > > On 2020-11-09 10:44, Simon Cross wrote: > >> That's quite subjective. Personally I prefer a more complete tutorial > >> which explains many details so that I don't immediately run into > >> fundamentals I don't understand when I start using what I've learned. > >> K was very popular, so I don't think I'm alone in this. > > > > > > Indeed. A common problem with a lot of platform documentation I've > > experienced is that tutorials are "fluff" for absolute beginners, > > complemented with terse, dense reference material for experts. There is > > too often very little in-between to get you to the intermediate level. > > > > That's why the current tutorial is fantastic, imho. It doesn't skip the > > all-important middle part of the journey, and gets you to > > near-intermediate within a few hours if you've programed before. > > > > Perhaps the first step is too high, however. How about a new Section 0: > > Absolute beginners guide, for those new to programming? > > Just 2 cents' worth, the difficulty this discussion exposes is things In > The Wrong Place (subjective), and maybe not all of the required places > actually complete. I thought the following was a pretty good discussion > of the overall problem of documenting a complex ecosystem: > > https://documentation.divio.com/ > > Daniele Procido who is involved with Divio has shared this with us when we were planning a workgroup. It's excellent content and guidelines. > If people think that model is reasonable, we sort of have most of it - > we have Reference; HowTos and Explanations (mixed together in > https://docs.python.org/3/howto/index.html); and Tutorial. _Some_ > people think the tutorial has too much stuff that belongs in the HowTos > and Explanations buckets, and that's probably where things should be > built up. e.g. @raymondh has been working on the Descriptor Howto, > which is a good example of more detailed material not getting stuffed in > the tutorial :) > > I agree. I wouldn't suggest a major refactor of the existing tutorial right now (next 1-2 years). Instead, new beginner tutorial pages targeted at user groups (primary school students, scientists, web developers, etc.) would make sense to supplement the existing tutorial. I suspect that future documentation will have "How Tos" being more often written to cover more technical topics in detail. These more standalone "How Tos" can then be linked to from contents and search pages. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GBPCAGDXYLZPKK3BH2MGSGTS3IO3CO5H/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SN3AVFNFVNNR3DWB7EE432OAM6P7TTPS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
We'll be making an announcement in a few weeks asking folks to apply for the workgroup. The workgroup will be at most 20 people with the goal of having significant representation (25% to 50%) of individuals who are educators and documentarians. One goal of the workgroup is to set documentation priorities for new documentation and act as an editorial board for existing documentation. In addition to the workgroup, we'll be booting up a Documentation Team which will be open to all. The plan is to hold open monthly meetings (alternating times to accommodate folks globally). We'll be setting up something similar to how we have run JupyterHub and Binder meetings for the past few years: https://github.com/jupyterhub/team-compass The hope is that folks will feel a sense of community around documentation. On Mon, Nov 9, 2020 at 6:34 PM Steven D'Aprano wrote: > On Tue, Nov 10, 2020 at 03:33:06AM +1100, Chris Angelico wrote: > > > If that were to happen, what I'd prefer is to cut lots of info out of > > the *TUTORIAL* and make a new document called, say, *Python Advanced > > Techniques* or something, which could still have the narrative style > > but would be aimed at people who know how to use basic functionality > > and are looking to learn more. > > I think that there is a lot of middle ground between "simple" stuff for > beginners and "advanced techniques" for experts. > > Is it too much to expect beginners to skim over parts of the tutorial > that are marked as "intermediate" or "expert" level? Personally I find > it very helpful to "peek ahead" to get an idea of the material ahead, > and see how the current material fits into the broader picture. > > What do we mean by "beginners"? Who is the tutorial aimed at? Eg: > > - self-taught 12 year olds passionate about learning to program > > - surly 15 year old students being forced to learn Python for school > > - scientists needing to learn to interact with scientific libraries, but > with no interest in programming beyond the barest minimum they need > to make the libraries work > > - sys admins with 20 years experience in other languages looking to get > an introduction to Python so they can be productive > > etc. All of the above? > > > > The name "tutorial" definitely screams "thing you should go through > > first". > > Not to me. > > When I was at uni, the tutorial was the thing you went through *second*, > after the main lectures, to reinforce what you had already learned from > the lecturers and text book. > > When I tutor students professionally, I teach them new material, oh, > maybe one time in twenty. The rest of the time we're covering material > they have already learned. > > > > It shouldn't have to teach you everything. > > Then it's a good thing it doesn't attempt to :-) > > > -- > Steve > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/L4AJ6DGLYYSIYKAJYRXO6SL3KPWPQA2Q/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZGA4MO57GZO6ONDKLXRG3Z3D3GV7ZABZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Who is target reader of tutorial?
Thanks Inada-san for bringing up this issue. I agree with your point and Guido's that the tutorial should target learning Python if new to the language but not coding. It's likely that in the future there will be an even more basic tutorial for those newer to coding. An advanced concept, as Kyle mentions, is fine when it is a sentence or two and refers back to the in-depth documentation. Care should be taken when introducing an advanced topic or use case to have it at the end of a section and not interleaved with the examples that suit the majority of learners (Python beginners and intermediate developers). On Thu, Nov 5, 2020 at 12:35 PM Kyle Stanley wrote: > I can't speak for all of the members of the upcoming documentation WG, but > as someone that will be on it (based on our discussions at the recent core > dev sprint), my personal vote would be for keeping it as a comprehensive > guide for beginners of Python. Detailed enough that it covers the > fundamentals, but skips out on more advanced topics and info that is likely > going to be less applicable to most new users. > > I would consider __cause__ and __context__ to fall under the category of > being "useful to know, but far from essential for beginners". You can have > a decent understanding of most python programs without ever knowing about > those two dunders. So I would definitely be in favor of removing the > mention of __cause__ and not adding __context__, in my opinion it adds > extra unneeded complexity. > > That being said, I'm not opposed to something like having something like a > footnote at the bottom of the section that links to a more advanced topic > (maybe an exception how-to?). It should be at the bottom of the section so > it doesn't add extra cognitive overhead for those trying to grasp the > basics, but allows for those who are interested to get a more in-depth > understanding if they want to. I would suggest redirecting the contributor > who proposed those changes to working on something like an exception > how-to; assuming that's something they're interested in. > > On Thu, Nov 5, 2020 at 2:07 PM Brett Cannon wrote: > >> A documentation WG is going to be formed which will be in a better >> position to answer this, so until that WG is started I think we should keep >> the tutorial aimed towards beginners. >> >> On Thu, Nov 5, 2020 at 1:13 AM Inada Naoki >> wrote: >> >>> Hi, all. >>> >>> Since "How To" guide is not organized well, it is very tempting to >>> write all details in tutorial. >>> I have seen may pull requests which "improve" tutorial by describe >>> more details and make >>> the tutorial more perfect. >>> >>> But adding more and more information into tutorial makes it slower to >>> learn Python by reading tutorial. >>> 10+ years ago, Python is far less popular in Japan and reading >>> tutorial is the best way to learn Python to me. >>> >>> But now Python is popular and there are many free/paid good books and >>> tutorials on the Web. >>> Some of them would be more new user friendly than official tutorial. >>> Then, should official Python tutorial become detailed guide to Python? >>> Or should we keep new user learning Python as targeted reader? >>> >>> There is ongoing issue for example: https://bugs.python.org/issue42179 >>> >>> Chaining exception was added in tutorial. Current tutorial mention to >>> `__cause__` attribute. >>> https://docs.python.org/3/tutorial/errors.html#exception-chaining >>> >>> bpo-42179 proposes to add mention to `__context__` to make the >>> tutorial more accurate about implicit chaining. >>> And https://github.com/python/cpython/pull/23160 is the pull request >>> to mention `__context__`. >>> >>> On the other hand, I want to remove confusion by removing mention to >>> `__cause__`. >>> Because I don't think `__context__` and `__cause__` is important for new >>> users. >>> See https://github.com/python/cpython/pull/23162 for my proposal. >>> >>> Regards, >>> >>> -- >>> Inada Naoki >>> ___ >>> Python-Dev mailing list -- python-dev@python.org >>> To unsubscribe send an email to python-dev-le...@python.org >>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-dev@python.org/message/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org >
[Python-Dev] Re: [python-committers] Resignation from Stefan Krah
On Sat, Oct 10, 2020 at 10:42 AM Jeff Allen wrote: > On 10/10/2020 00:56, Brett Cannon wrote: > > On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi wrote: > >> >> One thing i would suggest, though, is documenting and, in general, >> following a sequence of progressively more strict interventions by the >> steering committee. I think that just as it is harmful to the community to >> let bad behavior slide, it is also harmful to the community to not know >> that the steering committee's enforcement is in measured steps which will >> telegraph the committee's intentions and the member's responsibilities well >> in advance. >> > > Documenting exact steps is really hard when it comes to a Code of Conduct. > Every case is unique and so rigid rules don't typically work well, e.g. > requiring everyone to get a warning first would mean I could [...] way more > and still be here without technical ramifications because we said, "you > always get a warning first". > > This is so painful I'm reluctant to add to the pile, so I'll be succinct > (at risk of sounding brusque). Personally I find it a weak argument that > the SC should not codify a system of warnings because some cases go bad so > quickly that you have to act immediately. This may be necessary for > drive-by trolls with a point to make. It would be rare in anyone with > significant standing in the PSF. Anyway, you can have both. > > I realise that core developer status is not employment, but I think there > is a model worth considering in this: > https://www.gov.uk/dismiss-staff/dismissals-on-capability-or-conduct-grounds#disciplinary-procedures > . This is guidance, not law over here, but an employment tribunal would > take it as a definition of reasonable, so most decent employers adopt it as > a policy. > > I have been asked personally and privately multiple times over the years > to step in and mediate conduct issues with Stefan over the years. Tack on a > Conduct WG warning from just earlier this year and the multiple incidents > subsequently and that's how I at least reached my decision that this was a > reasonable approach to take. > > Sounds like you were doing roughly as Toshio recommends anyway (the decent > thing as I'd expect), but maybe explicit is better? > > Jeff Allen > Thanks for sharing your thoughts and experience. The Python Software Foundation Code of Conduct Working Group Enforcement Procedures, https://www.python.org/psf/conduct/enforcement/ , provides explicit steps that are taken as well as the possibilities for behavior modification and also consequences. This document also outlines the process for proposing changes in the "Changes to Code of Conduct" section. While I am not an expert in UK employee law, the linked document includes the following wording: > You should include examples of what you consider to be misconduct in your disciplinary rules. > Different disciplinary procedures are appropriate for different circumstances. These concepts are reflected in Python's process. Carol ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FIYLQT7QDTXRCSAOSDW7OW3YCSS3TKQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Resignation from Stefan Krah
On Fri, Oct 9, 2020 at 2:50 PM Toshio Kuratomi wrote: > > > On Fri, Oct 9, 2020, 5:30 AM Christian Heimes > wrote: > >> On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote: >> > I don't see the point of requiring to "write an apology", especially >> > *before a 12-month ban*. If they understand that their behavior is >> > wrong, there's no need for a ban, at least not such a long one; if they >> > don't, they clearly aren't going to write it, at least not now (they >> > might later, after a few weeks or months, having cooled down and thought >> > it over). So all it would achieve is public shaming AFAICS. Same issue >> > with the threat of "zero tolerance policy" -- it's completely >> > unnecessary and only serves to humiliate and alienate the recipient. >> >> >> I have been the victim of Stefan's CoC violations on more than one >> occasion. He added me to nosy list of a ticket just to offend and >> humiliate me. For this reason I personally asked the SC to make a >> sincere apology a mandatory requirement for Stefan's reinstatement as a >> core dev. >> >> I would have been fine with a private apology. However Stefan has also >> verbally attacked non-core contributors. In one case another core dev >> and I contacted the contribute in private to apologize and ensure that >> the contributor was not alienated by Stefan's attitude. Therefore it >> makes sense that the SC has requested a public, general apology. >> >> Why are you more concerned with the reputation of a repeated offender >> and not with the feelings of multiple victims of harassment? As a victim >> of Stefan's behavior I feel that an apology is the first step to >> reconcile and rebuild trust. >> > > At the risk of putting my nose in where it doesn't belong... I think that > Ivan has some good general points. And i think that they could be > distilled as this: if you are looking to correct bad behavior but allow a > contributor to learn about proper behavior and then return to the > community, the steps taken here seen counter-productive (1). I would add a > second piece to that: If, on the other hand, the goal is to remove a toxic > person from the community whoneeds to go through major personality shifting > changes before they can be allowed back, then this may be appropriate (2). > > For (1), what I'm getting from Ivan's post is that these measures are at a > level that few (if any) people would be willing to fulfill them and then > come back to be a non-bitter contributor. When the requirements are too > costly for the violator to pay, they won't be able to learn and then pay > those costs until they can disavow their former selves. "i'm sorry i acted > like that; i was a *different person* back then. I'm sorry that *past me* > felt the need to hurt you." > > I would think that in general, not necessarily this specific case, the > steering committee would want to try taking steps to get people to learn > proper behavior first and only resort to something which amounts to a de > facto permanent ban when it becomes apparent that the person has to go > through some major personality changes before their behavior will change. > > For (2), the steering committee is charged with protecting the community > at large. A toxic person can cause great havoc by themselves and set the > tone of a community such that other people feel that engaging in bad > behavior is the proper thing to do in this community. With that in mind, > at some point, this kind of action has to be on the table. It is great > that pep-13 lists banning as a possibility so that people know where their > actions can lead. > > One thing i would suggest, though, is documenting and, in general, > following a sequence of progressively more strict interventions by the > steering committee. I think that just as it is harmful to the community to > let bad behavior slide, it is also harmful to the community to not know > that the steering committee's enforcement is in measured steps which will > telegraph the committee's intentions and the member's responsibilities well > in advance. > > Hi Toshio, Thanks for sharing your thoughts with us in such a constructive manner. I appreciate it. Others on the Steering Council have done a good job of covering this particular situation. All I will add to their comments is that we spent many, many hours during our weekly meetings and via email and have tried to be respectful and thoughtful in our decisions. As for the additional information that you seek about process and progressive actions, these two links, particularly the second, give more details: - https://devguide.python.org/#code-of-conduct - https://www.python.org/psf/conduct/enforcement/ Thanks, Carol > This specific case may already have been out of hand by the time it came > to the committee, the steering committee is relatively new and problems > could have festered before they formed and started governing, but a new > member of the community should know that if they
[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion
Hi folks, Thanks for the interest. I apologize for the delay in getting this workgroup started. I'm happy that there is strong interest in working on documentation and improving it for all users. I will do my best to get the workgroup charter drafted this week and then open an interest list for initial workgroup members. Luciano, I agree that rewriting asyncio docs and typing are helpful improvements and welcome your contributions to accessible and high quality docs. Warmly, Carol On Sun, Aug 9, 2020 at 9:21 AM Luciano Ramalho wrote: > I am also interested in helping with making Python's documentation > more user friendly. > > Yuri Selivanov's rewrite of the asyncio documentation was brilliant. > We need more of that. > > My recent contribution to Python's doc doesn't compare with > Selivanov's awesome rewrite, but it involved reorganizing existing > documentation. > > The typing module chapter in the library reference is comprehensive, > and the top 1/3 of it has good narrative explanations to the core > concepts. But the remaining 2/3 of the content is in a single section > titled "Classes, functions, and decorators" that covers more than 70 > objects, and there's no apparent ordering. > > With the help of Guido, I split that section in subsections, and > arranged the entries within the subsections by relevance to most > users—subjective, yes, but not too harmful if we made bad calls, > because now there are fewer entries per subsection. > > Before: > https://docs.python.org/3.8/library/typing.html > > After: > https://docs.python.org/3.10/library/typing.html > > Cheers, > > Luciano > > On Sun, Aug 9, 2020 at 12:43 PM Mats Wichmann wrote: > > > > On 8/5/20 10:43 AM, Dominic Davis-Foster wrote: > > > Hi Carol, > > > > > > I was wondering if you've been able to set up the workgroup yet? I'd > certainly be interested in participating the there's an opportunity. > > > > > > > > > Stay safe > > > > > > Dom > > > > Indeed, I was wondering if there were any updates - I'm also interested > > in participating. > > > > -- mats > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/MRV5SQCC2GC6MLIUCSPJZL3AQCXVDUEG/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Luciano Ramalho > | Author of Fluent Python (O'Reilly, 2015) > | http://shop.oreilly.com/product/0636920032519.do > | Technical Principal at ThoughtWorks > | Twitter: @ramalhoorg > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/P6S4Q3H6VOXVJTXX4UCRRYDCIDLC2M4C/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZTIK4R7HNPV2HZJ6TJHONGCCYUOSL5CW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Python Documentation, Python language improvement, and productive discussion
Hi folks, Earlier this year at the Python Language Summit, Ned Batchelder and I presented the concept of a Documentation Workgroup and a vision for the next few years: - Slidedeck https://speakerdeck.com/willingc/cpython-documentation-the-next-5-years - Blog post https://pyfound.blogspot.com/2020/04/cpython-documentation-next-5-years.html Due to some health issues that I have had the past few months, I haven't yet set up the workgroup. It's a priority of mine for July. We will have an open call for workgroup participants. There's a lot going on in the world with COVID19 that is impacting our lives directly and indirectly. I encourage the core development community to consider how what they share about their feelings on PEP8 may impact others. Clearly, this is an issue where it's unlikely that there will be universal agreement. As you consider additional posts about PEP8, I encourage you to think about whether your post improves the Python language before hitting Send. Stay safe as we all live together in a world facing unusual constraints due to COVID19. Warmly, Carol ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/I3M4XZ6EL3FQABBDCGD5HWDARVU7RFPC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Nominations for the 2019 Steering Council Election are open until Friday.
Thanks Thomas. If there are any questions, I'm happy to do my best to answer those too. On Wed, Nov 13, 2019 at 3:39 AM Thomas Wouters wrote: > > Perhaps this should've been announced a little more widely: we have > upcoming Steering Council elections, and nominations close soon -- end of > day *this Friday*. Five seats need to be filled. (We have four nominations > so far, but I have no idea how many people are gearing up to nominate in > the next couple of days.) > > Nominees *do not need to be core developers*, although a core developer > has to do the nominating. Brett Cannon and Carol Willing have posted about > what the work entails: > > https://snarky.ca/what-its-like-to-be-on-the-python-steering-council/ > https://www.willingconsulting.com/post/2019-11-02-python-steering-retro/ > > If you think you might be interested but you're not a core developer, or > you're just not comfortable self-nominating, please feel free to talk to me > (or other core developers you might know). If you're not sure if you'd have > a useful contribution -- well, we can talk about that, too :) > > -- Forwarded message - > From: Ewa Jodlowska > Date: Fri, Nov 1, 2019 at 1:40 PM > Subject: [python-committers] Nominations for the 2019 Steering Council > Election are now open. > To: > > > Hello! > > Per PEP 13, members of the Committers group can post to the "Steering > Council Nominations" > category on Discourse to nominate a person ( > https://discuss.python.org/t/2019-steering-council-nominations-are-now-open/2561). > All users are able to reply. > > Nominations should be posted as a Topic with the name "Steering Council > nomination: " and tagged with the election tag. > > All Posts and Replies in this category will be moderated, so there may be > some delay before they appear. > > Thank you, > > Ernest & Ewa > > --- > *As a non-profit organization, the PSF depends on sponsorships and > donations to support the Python community. Check out our Annual Impact > Report for more details: https://www.python.org/psf/annual-report/2019/ > <https://www.python.org/psf/annual-report/2019/>* > *Please contribute to PSF; we can't continue our work without your > support! https://www.python.org/psf/donations/ > <https://www.python.org/psf/donations/>* > ___ > python-committers mailing list -- python-committ...@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committ...@python.org/message/ZJ4V2KPFE6DJO4GONP7YV2QCHBM6UUY7/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/3A3NDLUTA47FXIP3QKTBJF556372MOO6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- *Carol Willing* Willing Consulting <https://willingconsulting.com> *Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner* ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KN3S5TJTPIJQIUGIQJN6OYFB7MXQLIJN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council Update for July 2019
Hi Simon, There are several ways to share constructive feedback. You may email the steering council, file an issue on the public steering council repo, or create a discussion thread on Discourse or python-dev. Thanks! Carol On Mon, Jul 8, 2019, at 12:35 PM, Simon Cross wrote: > Is there a way for people to give input to the challenges facing Python > discussion? I'm picturing something like people writing short statements of > perceived challenges and submitting them so that the SC has more ideas on its > radar. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LM2VJKOQKPBGZ6G2NWL6C7BQ4QFZULEA/
[Python-Dev] Re: Steering Council Update for July 2019
Sorry for the incorrect link. Here is the corrected link: https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council-update.md On Mon, Jul 8, 2019, at 7:16 AM, Carol Willing wrote: > I've posted an update from the Steering Council to our repo: > https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council > > I will also link to this on python-dev and on Discourse (discuss.python.org ). > > For completeness, below is the full text. > > > # Steering Council Update ## Date: 2019-07-08 Steering Council updates will be posted irregularly and as needed. We provide these updates to foster open and transparent communication about Steering Council activity. We strive to post at least once every month. # Message from the Steering Council Sorry we've been silent for a while! With PyCon in Cleveland, the Language Summit, Sprints, PEP activity, and a Python 3.8 beta release, it's been a busy and productive May and June. Thank you all for your contributions. Below are some of the outcomes of our weekly Steering Council conversations. --- ## Mandate This section organizes Steering Council (SC) activity and projects using the mandates listed in PEP 13. ### Language > Maintain the quality and stability of the Python language and CPython > interpreter - Inspired by Russell Keith-Magee's PyCon keynote about Black Swan events, the Steering Council is looking at what may impact Python for the next decade. We have been discussing this within the Steering Council and writing up some thoughts on major challenges facing Python. We'll continue to edit and polish this vision document and share it when we are ready for wider comment. ### Contributors > Make contributing as accessible, inclusive, and sustainable as possible - **Communications channels:** We are very pleased with the move of python-dev, etc. to Mailman 3. We now have a modern UI and easy search across mailing lists. Just a reminder to recap where announcements and conversations are taking place: - To reach core committers specifically, we will use python-committ...@python.org. - To reach the entire Python developer community, we will use python-dev@python.org. - For specific requests to the SC (e.g., PEP reviews), please use our public GitHub tracker at https://github.com/python/steering-council/issues. - To reach just the SC, you can email us at steering-coun...@python.org. - We will also occasionally use Discourse, at https://discuss.python.org (for example, Discourse is useful for polls and votes). ### PEPs > Establish appropriate decision-making processes for PEPs - To request a PEP review, please file an issue on the [SC issue tracker](https://github.com/python/steering-council/issues). PEP highlights include: - PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo Galindo and others. *Appointed Guido van Rossum as BD.* "Completed." - PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou. *Appointed Nick Coghlan as BD.* "Marked Final." - PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of PEP 590). *Appointed Petr Viktorin as BD.* "Accepted 590." - PEP 578, "Python Runtime Audit Hooks", Steve Dower. *Appointed Christian Heimes as BD.* "Landed, about to be marked Final." ### Interaction with PSF > Formalize and maintain the relationship between the core team and the PSF - We began discussions about fundraising ideas for CPython projects and administrative support. - A [donation page]([https://www.python.org/psf/donations/python-dev/](https://www.python.org/psf/donations/python-dev/)) was created by the PSF and was linked from the [CPython repo]([https://github.com/python/cpython](https://github.com/python/cpython)). Any funds that are donated will be used for Core Developers to attend the core development sprints (to start; future possibilities are dependent on the amount of funds gathered). - At the Steering Council's recommendation, the PSF also is looking at hiring a Project Manager to manage communication and some logistics for the 2020 Python 2.7 End of Life. - The PSF Code of Conduct Workgroup is working on a revision of the CoC and its approval by the PSF board. Brett and Carol serve on the Workgroup. ### Governance > Seek consensus among contributors and the core team before acting in a formal > capacity, > Act as a "court of final appeal" for decisions where all other methods have > failed. - The weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time) has been working out well. --- ## Reference This reference section summarizes the Steering Council's mandate and powers. ### Mandate (PEP 1
[Python-Dev] Steering Council Update for July 2019
I've posted an update from the Steering Council to our repo: https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council I will also link to this on python-dev and on Discourse (discuss.python.org ). For completeness, below is the full text. # Steering Council Update ## Date: 2019-07-08 Steering Council updates will be posted irregularly and as needed. We provide these updates to foster open and transparent communication about Steering Council activity. We strive to post at least once every month. # Message from the Steering Council Sorry we've been silent for a while! With PyCon in Cleveland, the Language Summit, Sprints, PEP activity, and a Python 3.8 beta release, it's been a busy and productive May and June. Thank you all for your contributions. Below are some of the outcomes of our weekly Steering Council conversations. --- ## Mandate This section organizes Steering Council (SC) activity and projects using the mandates listed in PEP 13. ### Language > Maintain the quality and stability of the Python language and CPython > interpreter - Inspired by Russell Keith-Magee's PyCon keynote about Black Swan events, the Steering Council is looking at what may impact Python for the next decade. We have been discussing this within the Steering Council and writing up some thoughts on major challenges facing Python. We'll continue to edit and polish this vision document and share it when we are ready for wider comment. ### Contributors > Make contributing as accessible, inclusive, and sustainable as possible - **Communications channels:** We are very pleased with the move of python-dev, etc. to Mailman 3. We now have a modern UI and easy search across mailing lists. Just a reminder to recap where announcements and conversations are taking place: - To reach core committers specifically, we will use python-committ...@python.org. - To reach the entire Python developer community, we will use python-dev@python.org. - For specific requests to the SC (e.g., PEP reviews), please use our public GitHub tracker at https://github.com/python/steering-council/issues. - To reach just the SC, you can email us at steering-coun...@python.org. - We will also occasionally use Discourse, at https://discuss.python.org (for example, Discourse is useful for polls and votes). ### PEPs > Establish appropriate decision-making processes for PEPs - To request a PEP review, please file an issue on the [SC issue tracker](https://github.com/python/steering-council/issues). PEP highlights include: - PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo Galindo and others. *Appointed Guido van Rossum as BD.* "Completed." - PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou. *Appointed Nick Coghlan as BD.* "Marked Final." - PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of PEP 590). *Appointed Petr Viktorin as BD.* "Accepted 590." - PEP 578, "Python Runtime Audit Hooks", Steve Dower. *Appointed Christian Heimes as BD.* "Landed, about to be marked Final." ### Interaction with PSF > Formalize and maintain the relationship between the core team and the PSF - We began discussions about fundraising ideas for CPython projects and administrative support. - A [donation page]([https://www.python.org/psf/donations/python-dev/](https://www.python.org/psf/donations/python-dev/)) was created by the PSF and was linked from the [CPython repo]([https://github.com/python/cpython](https://github.com/python/cpython)). Any funds that are donated will be used for Core Developers to attend the core development sprints (to start; future possibilities are dependent on the amount of funds gathered). - At the Steering Council's recommendation, the PSF also is looking at hiring a Project Manager to manage communication and some logistics for the 2020 Python 2.7 End of Life. - The PSF Code of Conduct Workgroup is working on a revision of the CoC and its approval by the PSF board. Brett and Carol serve on the Workgroup. ### Governance > Seek consensus among contributors and the core team before acting in a formal > capacity, > Act as a "court of final appeal" for decisions where all other methods have > failed. - The weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time) has been working out well. --- ## Reference This reference section summarizes the Steering Council's mandate and powers. ### Mandate (PEP 13) The steering council shall work to: - Maintain the quality and stability of the Python language and CPython interpreter, - Make contributing as accessible, inclusive, and sustainable as possible, - Formalize and maintain the relationship between the core team and the PSF, - Establish appropriate decision-making processes for PEPs, - Seek consensus among
[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section
I agree with you, Ned. Mariatta, I'm happy to work on an initial pass at the devguide in my fork. On Fri, Jun 28, 2019 at 10:52 AM Ned Deily wrote: > > On Jun 28, 2019, at 12:56, Mariatta wrote: > > Some of the items brought up during the language summit: > > [...] > > - we should be updating devguide ahead of the actual migration, so core > developers and release managers have time to review and learn the new > workflow. (suggested by Ned Deily) > > Actually, my suggestion was (and remains :) ) that a modified devguide > branch should be created *first* as part of the migration design process, > not later during implementation. It needs to happen anyway but it would be > much more effective, I think, to have it available up front to help catch > any holes during the design and review. > > P.S. Thanks for doing this, Marietta! > > -- > Ned Deily > n...@python.org -- [] > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/JPWPWUUYDRWNWALTVT4VIT4L6WMBNIRJ/ > -- *Carol Willing* Willing Consulting <https://willingconsulting.com> *Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner* ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YPUM4W7C7SBLJQQVVIM7CKPDBSQN7QOP/
[Python-Dev] Re: v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())
Hi Phil, Thanks for trying the beta. Please file this as an issue at bugs.python.org. Doing so would be helpful for folks who can look into the issue. Thanks, Carol On 6/22/19 2:04 PM, Phil Thompson wrote: The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is that PyQt is built using the stable ABI and a single wheel is supposed to support all versions of Python starting with v3.5. On the assumption (perhaps naive) that using the stable ABI would avoid future compatibility issues, the existing PyPI wheels have long been tagged with cp38. Was this issue considered at the time? What is the official view? Thanks, Phil ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YFNKFRJGNM25VUGDJ5PVCQM4WPLZU6J7/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NOATCX6I2HR3ZR5FQUPWXPVBYRJ6BKMZ/
[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty
Barry Warsaw wrote on 6/5/19 10:56 AM: On Jun 5, 2019, at 02:08, Victor Stinner wrote: Our kind postmasters Mark Sapiro and Abhilash Raj migrated python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3 (running on Python 3 ;-))! Gosh, it warms my heart. :) Thank you Mark, Abhilash! -Barry Bravo! Mark and Abhilash, thank you so much. I'm so happy to be able to use Mailman 3 for all my searches :D Python-Dev mailing list -- python-dev(a)python.org To unsubscribe send an email to python-dev-leave(a)python.org https://mail.python.org/mailman3/lists/python-dev.python.org/
Re: [Python-Dev] PEP 595: Improving bugs.python.org
Nathaniel Smith wrote: On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: On May 31, 2019, at 01:22, Antoine Pitrou wrote: I second this. There are currently ~7000 bugs open on bugs.python.org. The Web UI makes a good job of actually being able to navigate through these bugs, search through them, etc. Did the Steering Council conduct a usability study of Github Issues with those ~7000 bugs open? If not, then I think the acceptance of migrating to Github is a rushed job. Please reconsider. Thanks for your feedback Antoine. This is a tricky issue, with many factors and tradeoffs to consider. I really appreciate Ezio and Berker working on PEP 595, so we can put all these issues on the table. I think one of the most important tradeoffs is balancing the needs of existing developers (those who actively triage bugs today), and future contributors. But this and other UX issues are difficult to compare on our actual data right now. I fully expect that just as with the switch to git, we’ll do lots of sample imports and prototyping to ensure that GitHub issues will actually work for us (given our unique requirements), and to help achieve the proper balance. It does us no good to switch if we just anger all the existing devs. IMHO, if the switch to GH doesn’t improve our workflow, then it definitely warrants a reevaluation. I think things will be better, but let’s prove it. Perhaps we should put an explicit step on the transition plan, after the prototyping, that's "gather feedback from prototypes, re-evaluate, make final go/no-go decision"? I assume we'll want to do that anyway, and having it formally written down might reassure people. It might also encourage more people to actually try out the prototypes if we make it very clear that they're going to be asked for feedback. -n As Barry mentioned, there are many considerations. - Will GitHub provide a similar experience as bpo? Can the features valued by existing developers be served in a suitable way by GitHub issues? - What opportunity costs exist for remaining on bpo? Planning, reporting, integration with services, and accessibility are some. - Chicken and egg question: Are there 7000 open issues because the existing workflow with bpo inhibits acting on open issues with patches? Antoine, as for large projects on GitHub with many issues, TypeScript is a reasonable proxy with close to 4000 open issues yet only 126 open PRs. There are some nice planning things that have been done in the repo https://github.com/microsoft/TypeScript/issues as well as good documentation around their process and workflow. Thanks to Ezio and Berker for raising points in PEP 595. - Carol ___ 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
[Python-Dev] Online Devguide Status: Working Again
Sorry for the inconvenience yesterday. ___ 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
[Python-Dev] Update from the Python Steering Council about CPython Development
The Python Steering Council is pleased to provide an update to the Python community about Steering Council activity and CPython development. We've created a GitHub repo for Steering Council updates and helpful documents: https://github.com/python/steering-council Here's the latest update written after our meeting on February 26th: https://github.com/python/steering-council/blob/master/updates/2019-02-26_steering-council-update.md (https://link.getmailspring.com/link/2aacf155-36b1-4d80-a2c1-a948561c4...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fpython%2Fsteering-council%2Fblob%2Fmaster%2Fupdates%2F2019-02-26_steering-council-update.md=cHl0aG9uLWRldkBweXRob24ub3Jn) We'll be posting updates after each steering council meeting which will be roughly twice a month. ___ 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
Re: [Python-Dev] Anyone want to lead the sprints at PyCon US 2016?
On 6 May 2016, at 14:38, Brett Cannon wrote: On Fri, 6 May 2016 at 14:14 Camilla <camilla...@gmail.com> wrote: I was thinking about holding a Patch Review Party/Sprint, which would provide people unfamiliar with the Python dev process a way to contribute to the project and get familiar with running tests, applying patches and so forth. I have a list of easy-ish patches that I wanted to take a look at and I could expand that and use those as a starting for people who don't have any particular bug tracker issues in mind. I'm not a patch review guru by any means, though. Also not sure if this is a good idea or if this is just late night caffeine talking. I have absolutely no problem if you want to pitch this idea to new contributors who show up at the sprints! -Brett Camilla, I would be happy to support your effort. I find it a wonderful idea! Carol Carol Willing Research Software Engineer, Project Jupyter @ Cal Poly Director, Python Software Foundation 2016-04-28 20:07 GMT+01:00 Brett Cannon <br...@python.org>: No one stepped forward to lead the sprints this year, so I will put myself as the sprint leader and lean on everyone else who appears to help. :) On Tue, 5 Apr 2016 at 09:36 Brett Cannon <br...@python.org> wrote: The call has started to go out for sprint groups to list themselves online. Anyone want to specifically lead the core sprint this year? If no one specifically does then I will sign us up and do my usual thing of pointing people at the devguide and encourage people to ask questions but not do a lot of hand-holding (I'm expecting to be busy either working on GitHub migration stuff or doing other things that I have been neglecting due to my GitHub migration work). -- Forwarded message - From: Ewa Jodlowska <e...@python.org> Date: Mon, 4 Apr 2016 at 07:14 Subject: [PSF-Community] Sprinting at PyCon US 2016 To: <psf-commun...@python.org> Are you coming to PyCon US? Have you thought about sprinting? The coding Sprints are the hidden gem of PyCon, up to 4 days (June 2-5) of coding with many Python projects and their maintainers. And if you're coming to PyCon, taking part in the Sprints is easy! You don’t need to change your registration* to join the Sprints. There’s no additional registration fee, and you even get lunch. You do need to cover the additional lodging and other meals, but that’s it. If you’ve booked a room through the PyCon registration system, you'll need to contact the registration team at pycon2...@cteusa.com as soon as possible to request the extra nights. The sprinting itself (along with lunch every day) is free, so your only expenses are your room and other meals. If you're interested in what projects will be sprinting, just keep an eye on the sprints page on the PyCon web site at https://us.pycon.org/2016/community/sprints/ Be sure to check back, as groups are being added all the time. If you haven't sprinted before, or if you just need to brush up on sprinting tools and techniques, there will again be an 'Intro to Sprinting' session the evening of June 1, lead by Shauna Gordon-McKeon and other members of Python community. To grab a free ticket for this session, just visit https://www.eventbrite.com/e/introduction-to-open-source-the-pycon-sprints-tickets-22435151141 . *Please note that conference registration is sold out, but you do not need a conference registration to come to the Sprints. ___ PSF-Community mailing list psf-commun...@python.org https://mail.python.org/mailman/listinfo/psf-community ___ 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/camillamon%40gmail.com ___ 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/willingc%40willingconsulting.com ___ 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
Re: [Python-Dev] Burning down the backlog.
On 8/18/15 7:52 AM, R. David Murray wrote: On Tue, 18 Aug 2015 12:47:22 +1000, Ben Finney ben+pyt...@benfinney.id.au wrote: Robert Collins robe...@robertcollins.net writes: However - 9 isn't a bad number for 'patches that the triagers think are ready to commit' inventory. So yay!. Also - triagers, thank you for feeding patches through the process. Please keep it up :) If I were a cheerleader I would be able to lead a rousing “Yay, go team backlog burners!� Which at this point in time I think pretty much means Robert, who I also extend a hearty thanks to. (I think I moved one issue out of commit review because the test didn't fail, and that's been it for me since Robert started his burn down...) --David Thank you Robert, David, and Ben :D Is anyone game for setting another goal to tackle a targeted subset of patches in patch review and move them to commit review? ___ 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
Re: [Python-Dev] Burning down the backlog.
On 7/26/15 6:37 PM, R. David Murray wrote: On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore p.f.mo...@gmail.com wrote: On 26 July 2015 at 16:39, Berker PeksaÄŸ berker.pek...@gmail.com wrote: So, I'm hoping Carol will take what I've written above and turn it into updates for the devguide (assuming no one disagrees with what I've said :) David, I'm happy to try to incorporate your detailed steps into the devguide. ___ 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
[Python-Dev] Devguide - Add Communications Quick Start Section
I would like to add a Communications Quick Start section to the beginning of the Python Developer's Guide. Productive communication between each other will always be critical to future development of CPython and maintaining releases, infrastructure, documentation, and more. Unproductive communication saps energy of contributors, reduces engagement in the project, and limits creativity and fulfillment in contributing. As a contributor who finds great value in the power and zen of Python, I want to foster more effective and productive communication. I've been thinking about ways to do this since the PyCon sprints. New developers would benefit from understanding how to interact with the community and its norms. Existing contributors would hopefully benefit from less time reexplaining community communication norms. The Communications Quick Start section would be brief and practical much like the Quick Start section for downloading and testing the source code. Placing the Communications Quick Start section before the existing Quick Start section would emphasize the importance that productive communications has on CPython development. Thanks, Carol P.S. Thank you to all that devote time and energy to the development of CPython. I have posted this to the python-dev mailing list for feedback due to the recent discussions. Nick and Brett, please feel free to move this to python-ideas if you feel that would be a better place to discuss this addition to the devguide. ___ 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
Re: [Python-Dev] Devguide - Add Communications Quick Start Section
On 7/21/15 9:31 PM, Nick Coghlan wrote: On 22 July 2015 at 04:08, Brett Cannon br...@python.org wrote: On Tue, Jul 21, 2015 at 11:05 AM Carol Willing willi...@willingconsulting.com wrote: The Communications Quick Start section would be brief and practical much like the Quick Start section for downloading and testing the source code. Placing the Communications Quick Start section before the existing Quick Start section would emphasize the importance that productive communications has on CPython development. Sounds great to me! Social norms are just as important to get to speed on as technical requirements when contributing to an open source community, so this seems like a worthy project. +1 from me as well. The discussion of a more formal CoC on the python-committers list also highlighted for me that our main current problems don't appear to be with any ill-intent on anyone's part, but rather with well-intentioned messages that nevertheless have the effect of causing folks to feel unappreciated and resentful. A practical quick start guide is likely to be more effective in addressing that aspect than a more explicit CoC (although I still think the latter would be a good idea in the long run). Regards, Nick. I have created an issuehttp://bugs.python.org/issue24682 on the Quick Start: Communications section. Please feel free to add further suggestions there. Thanks for the support. Terry, I like your suggested wording :) ___ 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
Re: [Python-Dev] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)
On 5/31/15 8:39 AM, Stephen J. Turnbull wrote: What I would really like to see is a Python 3 (and if you really need Python 2, here's how it differs) version of Python: Essential Reference. Agreed. If anyone has Python 3 books, talks, or resources that they find helpful and of high quality, please send me an email and I will happily curate a cheatsheet, document, or website with the results. For example, Harry Percival's TDD book and tutorials on PyVideo.org are well done with a Python 3 focus. If you have other favorite Python 2 books that you wish were revised/rewritten to have a Python 3 focus, please email me that as well. I agree, but the cargo cult thing is big for people coming to Python because somebody told them it's a good way to do something practical. For our user group attendees (whether novice or experienced, teens or post-docs), practical and simple trumps shiny and complex. Search gives them a mountain of resources. Yet, these users are looking for guidance on a reasonable approach to do the practical things that interest them. These creators, innovators, and experimenters care less about programming language or version than they do about building their ideas. Fortunately, the Python language, especially when combined with the Python community and its outreach, enables building these ideas...when we are not tripping all over our own perspectives of which version should suit the use case. Practically, use whichever version is best suited to the use case. Warmly, Carol P.S. Whether you develop for version 2, version 3, or both, thank you for doing so :-) -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
Re: [Python-Dev] Mac popups running make test
On 5/10/15 10:29 AM, Tal Einat wrote: On Sun, May 10, 2015 at 5:07 PM, Brett Cannon br...@python.org mailto:br...@python.org wrote: On Sun, May 10, 2015 at 10:04 AM Skip Montanaro skip.montan...@gmail.com mailto:skip.montan...@gmail.com wrote: I haven't run the test suite in awhile. I am in the midst of running it on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: I assume this is testing some server listening on localhost. Is this a new thing, either with the Python test suite or with Mac OS X? (I'd normally be hidden behind a NAT firewall, but at the moment I am on a miserable public connection in a Peet's Coffee, so it takes on slightly more importance...) It's not new. Indeed, I've run into this as well. I've also seen the Crash Reporter pop up many times, but as far as I could tell, in all cases the test suite output told me it was expected. Perhaps tests which listen for network connections should also mention that, at least on Macs? Wouldn't hurt. Just requires tracking down which test(s) triggers it (might be more than one and I don't know if answering that popup applies for the rest of the test execution or once per test if you use -j). If anyone starts working on this, let me know if I can help, e.g. trying things on my own Mac. I believe that the message has to do with OS X's sandboxing implementation and the setting of the sandbox's entitlement keys. Here's an Apple doc: https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW9 I'm unaware of a way to work around this other than using Apple's code signing or adjusting target build settings in XCode :( If anyone knows a good way to workaround or manually set permission (other than clicking the Allow button), I would be interested. Warmly, Carol -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 4/21/15 9:17 AM, R. David Murray wrote: Please be respectful rather than inflammatory. Thank you David. If you read what I wrote, I did not say that I was going to stop contributing, I specifically talked about that gut reaction being both emotional and illogical. That doesn't make the reaction any less real, and the fact that such reactions exist is a data point you should consider in conducting your PR campaign for this issue. (I don't mean that last as a negative: this issue *requires* an honest PR campaign.) As David stated, gut reactions are real. These reactions have the potential, if listened to and respected, to lead toward an optimal (not ideal) solution. Likely, the implementation of optional static type checking will evolve from reasoned, respectful debate of the issues not inflammatory quotes. Quite frankly, belittling someone's understanding or knowledge does not serve the PEP or technical issues at hand. I like the option of static type checking for critical high availability and high reliability applications (i.e. air traffic control, financial transactions). I'm less interested in static type checking of inputs when prototyping or developing less critical applications. There have been good technical points made by many on this thread especially given the different use cases. These use cases, and likely a few more, are important to an honest, continued technical refinement of the PEP. Two areas of clarification would be helpful for me: 1. Optional: What does this really mean in practice? Am I opting in to static type checking and type hints? Or must I opt out of type hints? Having to opt out would probably put more burden on the educational use cases than opting in would for a large corporate project. 2. Clearly, great thought has been put into this PEP. If anyone has a good analysis of the potential impact on Python 3 adoption, please do pass along. I would be interested in reading the information. Warmly, Carol P.S. I do member a time when tools to easily check for memory leaks in C were new and magical. Looking at the Coverity scans, I'm glad that the old magic is reaping real benefits. -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
Re: [Python-Dev] Starting CPython development w/ Docker
On 4/20/15 7:52 AM, Brett Cannon wrote: On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com mailto:s.shanabr...@gmail.com wrote: I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. Saul, thanks for the steps, and I will be trying it out. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Would you mind proposing this idea to core-mentors...@python.org mailto:core-mentors...@python.org and seeing if anyone else would benefit? If others do try it out and like then feel free to file an issue at bugs.python.org http://bugs.python.org for devinabox to add your script. Please do share your good work with core-mentorship :) Brett, Up to date docker development containers (devinabox in the cloudy sky) would be helpful for new developers since there will be less questioning and uncertainty if the dev environment is set up correctly. ___ 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/willingc%40willingconsulting.com -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
Re: [Python-Dev] [RELEASED] Python 3.4.3 is now available
Appears to be fixed now on the MacOSx tab. On 27/02/2015 09:30, Guido van Rossum wrote: There's a GitHub tracker for the website: https://github.com/python/pythondotorg/issues Please report issues with the website there. On Fri, Feb 27, 2015 at 5:59 AM, Victor Stinner victor.stin...@gmail.com mailto:victor.stin...@gmail.com wrote: Hum, it's probably an attack of the Python 2 mafia who fight against Python 3! Victor 2015-02-27 13:51 GMT+01:00 Geoffrey Spear geoffsp...@gmail.com mailto:geoffsp...@gmail.com: The download button (for Windows anyway) on the python.org http://python.org Download dropdown menu is broken; there's a small gray square where the 3.4.3 button should be, with the 2.7.9 one working fine. On Wed, Feb 25, 2015 at 8:07 AM, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.3. Python 3.4.3 has many bugfixes and other small improvements over 3.4.2. You can find it here: https://www.python.org/downloads/release/python-343/ The release slipped by two or three days, depending on what time zone you're in. This is my fault--I apologize for the inconvenience. Cheers, /arry ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/geoffspear%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido) ___ 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/willingc%40willingconsulting.com -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
Re: [Python-Dev] rst files
Hello Ethan, In addition to Guido's suggestion, the Python Developer Guide's Section 7.4.9 should be helpful. Here's a link to Section 7 on Restructured Text https://docs.python.org/devguide/documenting.html#restructuredtext-primer You may also find the Sphinx project documentation helpful if you need additional details. Carol On 23/01/2015 15:55, Guido van Rossum wrote: This adds entries to the index of the document -- similar to the index at the end of a book. I think single vs. double refers to different types of entries. Check out this page: https://docs.python.org/3/genindex.html On Fri, Jan 23, 2015 at 3:43 PM, Ethan Furman et...@stoneleaf.us mailto:et...@stoneleaf.us wrote: Can somebody please explain this? .. index:: single: formatting, string (%) single: interpolation, string (%) single: string; formatting single: string; interpolation single: printf-style formatting single: sprintf-style formatting single: % formatting single: % interpolation Specifically, what does index mean? What does single vs double vs triple mean? Is there a reference somewhere I can read? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido) ___ 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/willingc%40willingconsulting.com -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ 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
[Python-Dev] Python 3.4.2rc1 Mac OS X
To all who contributed to Mac OS X improvements: Thank you! I downloaded and installed last night on Mavericks 10.9. It was quick, straightforward, and completed in seconds. For contrast, I talked several new users at an Intro to Python workshop this past weekend how to install 3.4.1; it took about 5 minutes to guide each user through installing 3.4.1. The new 3.4.2rc1 installer is a *big* improvement. It also seems as if launching the interpreter from the command line is also faster now :) -- *Carol Willing* Developer | Willing Consulting +1 760 456 9366 | https://willingconsulting.com ___ 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
