Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale
On 05/27/2017 11:46 PM, INADA Naoki wrote: Now I approve the PEP 538. Thank you, Nick and Inada-san! -- ~Ethan~ ___ 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] Aligning the packaging.python.org theme with the rest of the docs
On Sat, 27 May 2017 14:26:54 +1000 Nick Coghlan wrote: > > Thoughts? Should we stick with pypa-theme as the name? Switch to > psf-docs-theme? Publish both, with pypa-theme adding PyPA specific > elements to a more general psf-docs-theme? > [...] > > Future requests to use the theme (beyond CPython and the PyPA) could > then be run through the PSF Trademarks committee, as with requests to > use the registered marks. Did you consider that whoever designed the theme might not agree with such a drastic policy change? You should first get their agreement for this. And what about derived works (which probably do exist already)? I don't know what the current legal situation for the theme is. I'm assuming it's licensed under an open source license (or perhaps implicitly believed to be so, which would be embarassing). If that's the case, I'm opposed to requiring that previously freely-reusable resources now need to get through a case-by-case approval process. This is at odds with the principles of free and open source software. (by the way I don't think that Alabaster is really comparable. "High contrast" isn't the only concern here. It's actually difficult to find a theme that ticks all the boxes in terms of being able to emphasize structure, having a sensible colour theme, displaying long-winded doc pages in a compact and readable form, etc.) Alternatively, you could have the PSF commission a designer and produce a truly specific theme for "official" Python docs. But perhaps that would be trying to solve a problem that does not truly exist (that is, that people would judge a third-party doc "official" just because it reuses the same grey-ish Sphinx theme). Or you could deem the use of the trademark-protected Python logo sufficient to denote "official" docs (which would still allow for variety in theming, which btw exists even within the Python docs: witness the theme difference between 2.7 and 3.x), and call it a day. Regards Antoine. ___ 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] Aligning the packaging.python.org theme with the rest of the docs
I'm -1 on going down the suggested route of Apple et al. for an open source language. We don't need more trademarks to "protect" ourselves against fellow open source projects. I see this whole trademark business that OSS projects are getting into in recent years in a more and more critical light. On one hand you have the open source idea, where you want to enable anyone to reuse your code. The OSS copyright licenses implement this idea nicely. On the other hand, you have trademark law which limits this reusability by imposing strict rules on how you can reuse the names, designs, colors, etc. trademarked by the OSS project (or else - TM lawyers tell you - you lose the rights to the TMs). The latter has to be handled with great care, since while you do want to protect the trademarks against malicious use by third parties (e.g. a company registering the same mark and then preventing use of the trademark in their jurisdiction), you don't want to hinder the original intent of having an open source license. In particular, you don't want to bully community projects which try to further the use of our open source software by using similar marks. In my role as PSF TM committee member, it's often painful to have to tell community members that they cannot use e.g. really nice looking variants of the Python logo for their projects. Let's not add more pain. If you want to make PSF related projects be recognized as such, simply add the PSF logo to the footer of the site and provide some blurb explaining the relationships to the about page. We could also have a special "PSF Project" logo for such a purpose. Use of the logo would then be subject to the TM requirements, but not the looks and UI of the site. On 28.05.2017 07:31, Nick Coghlan wrote: > On 28 May 2017 at 06:54, Guido van Rossum wrote: >> Are you also going to stop others from using the psf theme? > > I think it would definitely make sense to discourage the use of this > particular theme for projects that aren't relatively directly > affiliated with the PSF - there are plenty of other pip-installable > high contrast themes out there that aren't closely associated with a > particular backing organisation. > > The one Jon was originally considering for the PyPA docs was > Alabaster, which is now the default theme in Sphinx 1.3+: > https://alabaster.readthedocs.io/en/latest/ > > So I think it would be appropriate to include a sentence like the > following in the README for psf-docs-theme: > > "Please limit use of this theme to projects which are closely > affiliated with the Python Software Foundation, and have permission > from either the CPython core development team or the PSF itself for > such use. For other projects looking for a simple, high contrast, pip > installable Sphinx theme, we recommend the Alabaster theme used by > default in Sphinx 1.3+." > > Cheers, > Nick. > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 28 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.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] PEP 544: Protocols - second round
Thanks everyone for interesting suggestions! @Antoine @Guido: Some of the possible options for the title are: * Protocols (structural subtyping) * Protocols (static duck typing) * Structural subtyping (static duck typing) which one do you prefer? @Nick: Yes, explicit imports are not necessary for static type checkers (I will add a short comment about this). @Mark: I agree with Guido on all points here. For example, collections.abc.Iterable is already a class, and lots of code uses isinstance(obj, collections.abc.Iterable) and similar checks with other ABCs (also in a structural manner, i.e. via __subclasshook__). So that disabling this will case many breakages. The question of whether typing.Iterable[int] should be a class is independent (orthogonal) and does not belong to this PEP. -- Ivan ___ 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] PEP 544: Protocols - second round
> Some of the possible options for the title are It seems like you're talking about something most other languages would refer to as "Interfaces". What is unique about this proposal that would call for not using the industry standard language? > Type-hints should not have runtime semantics, beyond those that they have as classes > lots of code uses isinstance(obj, collections.abc.Iterable) and similar checks with other ABCs Having interfaces defined as something extended from abc doesn't necessitate their use at runtime, but it does open up a great deal of options for those of us who want to do so. I've been leveraging abc for a few years now to implement a lightweight version of what this PEP is attempting to achieve (https://github.com/kevinconway/iface). Once you start getting into dynamically loaded plugins you often lose the ability to strictly enforce the shape of the input until runtime. In those cases, I've found it exceedingly useful to add 'isinstance' and 'issubbclass' as assertions to input of untrusted types for the tests and non-production deployments. For a perf boost in prod you can throw the -O flag and strip out the assertions to remove the runtime checks. I've found that to be a valuable pattern. On Sun, May 28, 2017 at 8:21 AM Ivan Levkivskyi wrote: > Thanks everyone for interesting suggestions! > > @Antoine @Guido: > Some of the possible options for the title are: > * Protocols (structural subtyping) > * Protocols (static duck typing) > * Structural subtyping (static duck typing) > which one do you prefer? > > @Nick: > Yes, explicit imports are not necessary for static type checkers (I will > add a short comment about this). > > @Mark: > I agree with Guido on all points here. For example, > collections.abc.Iterable is already a class, > and lots of code uses isinstance(obj, collections.abc.Iterable) and > similar checks with other ABCs > (also in a structural manner, i.e. via __subclasshook__). So that > disabling this will case many breakages. > The question of whether typing.Iterable[int] should be a class is > independent (orthogonal) and > does not belong to this PEP. > > -- > Ivan > > > ___ > 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/kevinjacobconway%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/archive%40mail-archive.com
Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs
I agree with MAL and have also been on the Trademarks Committee for 8-9 years. Protecting an actual Mark like the logo is fine, as painful as it is to someone's say no to an attractive derived logo. But trying to protect a look-and-feel is way too far down the path of evil (it's what some proprietary companies we want to be different from do). Moreover, when when that's done it's not generally as trademark but as "trade dress" copyright... which is a concept I opposed ethically, but know it's the usual legal instrument. On May 28, 2017 5:08 AM, "M.-A. Lemburg" wrote: > I'm -1 on going down the suggested route of Apple et al. for an > open source language. > > We don't need more trademarks to "protect" ourselves against > fellow open source projects. > > I see this whole trademark business that OSS projects are getting > into in recent years in a more and more critical light. > > On one hand you have the open source idea, where you want to enable > anyone to reuse your code. The OSS copyright licenses implement this > idea nicely. > > On the other hand, you have trademark law which limits > this reusability by imposing strict rules on how you can reuse the > names, designs, colors, etc. trademarked by the OSS project (or > else - TM lawyers tell you - you lose the rights to the TMs). > > The latter has to be handled with great care, since while you > do want to protect the trademarks against malicious use by third > parties (e.g. a company registering the same mark and then preventing > use of the trademark in their jurisdiction), you don't want to > hinder the original intent of having an open source license. In > particular, you don't want to bully community projects which try to > further the use of our open source software by using similar marks. > > In my role as PSF TM committee member, it's often painful to have to > tell community members that they cannot use e.g. really nice looking > variants of the Python logo for their projects. Let's not add more > pain. > > If you want to make PSF related projects be recognized as such, > simply add the PSF logo to the footer of the site and provide > some blurb explaining the relationships to the about page. > > We could also have a special "PSF Project" logo for such a > purpose. Use of the logo would then be subject to the TM > requirements, but not the looks and UI of the site. > > > > On 28.05.2017 07:31, Nick Coghlan wrote: > > On 28 May 2017 at 06:54, Guido van Rossum wrote: > >> Are you also going to stop others from using the psf theme? > > > > I think it would definitely make sense to discourage the use of this > > particular theme for projects that aren't relatively directly > > affiliated with the PSF - there are plenty of other pip-installable > > high contrast themes out there that aren't closely associated with a > > particular backing organisation. > > > > The one Jon was originally considering for the PyPA docs was > > Alabaster, which is now the default theme in Sphinx 1.3+: > > https://alabaster.readthedocs.io/en/latest/ > > > > So I think it would be appropriate to include a sentence like the > > following in the README for psf-docs-theme: > > > > "Please limit use of this theme to projects which are closely > > affiliated with the Python Software Foundation, and have permission > > from either the CPython core development team or the PSF itself for > > such use. For other projects looking for a simple, high contrast, pip > > installable Sphinx theme, we recommend the Alabaster theme used by > > default in Sphinx 1.3+." > > > > Cheers, > > Nick. > > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, May 28 2017) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > > > ::: We implement business ideas - efficiently in both time and costs ::: > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >Registered at Amtsgericht Duesseldorf: HRB 46611 >http://www.egenix.com/company/contact/ > http://www.malemburg.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/ > mertz%40gnosis.cx > ___ 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] PEP 544: Protocols - second round
On 28 May 2017 at 16:13, Kevin Conway wrote: > > Some of the possible options for the title are > It seems like you're talking about something most other languages would > refer to as "Interfaces". What is unique about this proposal that would > call for not using the industry standard language? > Well, I would say there is no "industry standard language" about structural subtyping. There are interfaces, protocols, traits, mixins, typeclasses, roles, and probably some other terms I am not aware of - all with subtly different semantics in different languages. There are several reasons why we use term protocol and not interface. Two important reasons for me are: * The term protocol is already de-facto standard in Python for things like sequence protocol, iterator protocol, descriptor protocol, etc. * Protocols are very different from Java interfaces in one important aspect: they don't require explicit declaration of implementation, they are mainly oriented on duck-typing. Maybe we need to add a short section to rejected ideas? > Type-hints should not have runtime semantics, beyond those that they have > as classes > > lots of code uses isinstance(obj, collections.abc.Iterable) and > similar checks with other ABCs > Having interfaces defined as something extended from abc doesn't > necessitate their use at runtime, but it does open up a great deal of > options for those of us who want to do so. I've been leveraging abc for a > few years now to implement a lightweight version of what this PEP is > attempting to achieve > IIUC this is not the main goal of the PEP, the main goal is to provide support/standard for _static_ structural subtyping. Possibility to use protocols in runtime context is rather a minor bonus that exists mostly to provide a seamless transition for projects that already use ABCs. -- Ivan ___ 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] PEP 544: Protocols - second round
On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi wrote: > On 28 May 2017 at 16:13, Kevin Conway wrote: > >> > Some of the possible options for the title are >> It seems like you're talking about something most other languages would >> refer to as "Interfaces". What is unique about this proposal that would >> call for not using the industry standard language? >> > > Well, I would say there is no "industry standard language" about > structural subtyping. There are interfaces, protocols, > traits, mixins, typeclasses, roles, and probably some other terms I am not > aware of - all with subtly different semantics > in different languages. There are several reasons why we use term protocol > and not interface. > Two important reasons for me are: > * The term protocol is already de-facto standard in Python for things like > sequence protocol, iterator protocol, > descriptor protocol, etc. > * Protocols are very different from Java interfaces in one important > aspect: they don't require explicit > declaration of implementation, they are mainly oriented on duck-typing. > Maybe we need to add a short section to rejected ideas? > If you feel like it. Regarding the title, I'd like to keep the word Protocol in the title too, so I'd go with "Protocols: Structural subtyping (duck typing)" -- hope that's not too long to fit in a PEP title field. > > Type-hints should not have runtime semantics, beyond those that they >> have as classes >> > lots of code uses isinstance(obj, collections.abc.Iterable) and >> similar checks with other ABCs >> Having interfaces defined as something extended from abc doesn't >> necessitate their use at runtime, but it does open up a great deal of >> options for those of us who want to do so. I've been leveraging abc for a >> few years now to implement a lightweight version of what this PEP is >> attempting to achieve >> > > IIUC this is not the main goal of the PEP, the main goal is to provide > support/standard for _static_ structural subtyping. > Possibility to use protocols in runtime context is rather a minor bonus > that exists mostly to provide a seamless transition > for projects that already use ABCs. > Is something like this already in the PEP? It deserves attention in one of the earlier sections. -- --Guido van Rossum (python.org/~guido) ___ 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
