Re: [Python-Dev] http://pythonmentors.com/
On 11/02/2012 03:14, Eli Bendersky wrote: On Sat, Feb 11, 2012 at 03:38, Jesse Noller wrote: I've been trying to publicize it on twitter, my blog, google plus and elsewhere. help welcome. It also appears in the first paragraph of "Contributing" in the dev guide - which is pointed to by the main page at python.org (Core Development link). Mark, do you have a concrete idea of how it can be made more prominent? Eli Eli, quite frankly no :( The stock answer "put it on the main page at python.org" if actually followed up in all cases would result in something unreadable, as the page would be too noisy and displayed in something like Palatino size 1 (if there is such a thing). I'm just crossing my fingers and hoping that someone with far more than my own miniscule imagination can come up with a sensible suggestion. -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://pythonmentors.com/
> Eli, quite frankly no :( > > The stock answer "put it on the main page at python.org" if actually > followed up in all cases would result in something unreadable, as the page > would be too noisy and displayed in something like Palatino size 1 (if there > is such a thing). > > I'm just crossing my fingers and hoping that someone with far more than my > own miniscule imagination can come up with a sensible suggestion. > Well, I think the situation is pretty good now. If one goes to python.org and is interested in contributing, clicking on the "Core Development" link is a sensible step, right? It then leads to the Devguide, which is a relatively new thing. Reading that opening page of the devguide which is linked to from "Core Development" should give aspiring contributors all the information they need, including a link to the mentorship site. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Fri, 10 Feb 2012 16:06:15 +0200 Eli Bendersky wrote: > > Following the intensive and fruitful discussion of the (now rejected) > PEP 408 > (http://mail.python.org/pipermail/python-dev/2012-January/115850.html), > we've drafted PEP 411 to summarize the conclusions with regards to the > process of marking packages provisional. Note that this is an > informational PEP, and that for the sake of completeness it duplicates > some of the contents of PEP 408. I think the word "provisional" doesn't mean anything to many (non-native English speaking) people. I would like to suggest something clearer, e.g. "experimental" or "unstable" - which have the benefit of *already* having a meaning in other software-related contexts. > The package has been included in the standard library on a > provisional basis. While major changes are not anticipated, as long as > this notice remains in place, backwards incompatible changes are > permitted if deemed necessary by the standard library developers. Such > changes will not be made gratuitously - they will occur only if > serious API flaws are uncovered that were missed prior to inclusion of > the package. That's too wordy. Let's stay clear and to the point: "This package is unstable/experimental. Its API may change in the next release." (and put a link to the relevant FAQ section if necessary) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Sat, Feb 11, 2012 at 04:32:56PM +1000, Nick Coghlan wrote:
>
> This would then be seen by pydoc and help(), as well as being amenable
> to programmatic inspection.
>
Would using
warnings.warn('This is a provisional API and may change radically from'
' release to release', ProvisionalWarning)
where ProvisionalWarning is a new exception/warning category (a subclaass of
FutureWarning?) be considered too intrusive?
-Toshio
pgpsUYqg9uSvm.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Sat, 11 Feb 2012, Steven D'Aprano wrote: Arguably, the canonical test for whether a package is provisional or not should be the existence of __provisional__: for package in packages: if hasattr(package, '__provisional__') assert package documentation includes boilerplate else: assert package documentation does not includes boilerplate Could the documentation generator simply insert the boilerplate if and only if the package has the __provisional__ attribute? I'm not an expert in Python documentation but isn't it generated from properly-formatted comments within the Python source? Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for new dictionary implementation
Hello Mark, I think the PEP should explain what happens when a keys table needs resizing when setting an object's attribute. Reading the implementation, it seems the sharing can disappear definitely, which seems a bit worrying. Regards Antoine. On Wed, 08 Feb 2012 19:18:14 + Mark Shannon wrote: > Proposed PEP for new dictionary implementation, PEP 410? > is attached. > > Cheers, > Mark. > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Fri, Feb 10, 2012 at 11:32 PM, Nick Coghlan wrote: > On Sat, Feb 11, 2012 at 1:39 PM, Eric Snow > wrote: >> Is there more to it than having a simple __provisional__ attribute on >> the module and/or a list at sys.provisional_modules? > > Yes. As soon as we touch functional code, it because something to be > tested and the process overhead on our end is noticeably higher. > > However, I'd be fine with requiring that a short form for the notice > appear at the start of the module docstring. For example: > > "The API of this module is currently provisional. Refer to the > documentation for details." > > This would then be seen by pydoc and help(), as well as being amenable > to programmatic inspection. Sounds good enough to me. Realistically, the utility of getting provisional modules distributed with the stdlib far outweighs the theoretical use cases of programmatic inspection. If something like "__provisional__" turns out to be really useful, that bridge can be crossed later. I certainly don't want this PEP bogged down by a relatively superfluous point. :) -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for new dictionary implementation
Antoine Pitrou wrote: Hello Mark, I think the PEP should explain what happens when a keys table needs resizing when setting an object's attribute. If the object is the only instance of a class, it remains split, otherwise the table is combined. Most OO code will set attributes in the __init__ method so all attributes are set before a second instance is created. For more complex use patterns, it is impossible to know what is the best approach, so the implementation allows extra insertions up to the point of a resize when it reverts to the combined table (non-shared keys). (This may not be the case in the bitbucket repository, I'll push the newer version tomorrow). Reading the implementation, it seems the sharing can disappear definitely, which seems a bit worrying. It is immediately re-split (to allow sharing) when only one instance of the class exists. I've implemented it that way (resize->combined then re-split) as most resizes (999 out of 1000) will be of combined tables, and I don't want to complicate the fast path. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Sun, Feb 12, 2012 at 1:20 AM, Antoine Pitrou wrote: > On Fri, 10 Feb 2012 16:06:15 +0200 > Eli Bendersky wrote: >> >> Following the intensive and fruitful discussion of the (now rejected) >> PEP 408 >> (http://mail.python.org/pipermail/python-dev/2012-January/115850.html), >> we've drafted PEP 411 to summarize the conclusions with regards to the >> process of marking packages provisional. Note that this is an >> informational PEP, and that for the sake of completeness it duplicates >> some of the contents of PEP 408. > > I think the word "provisional" doesn't mean anything to many > (non-native English speaking) people. I would like to suggest something > clearer, e.g. "experimental" or "unstable" - which have the benefit of > *already* having a meaning in other software-related contexts. No, those words are far too strong. "Provisional" is exactly the right word for the meaning we want to convey (see http://dictionary.reference.com/browse/provisional, especially the second sense). Radical changes to provisional modules are highly unlikely (if we're that wrong about a module, we're more likely to just drop it than we are to change it significantly), but tweaks to eliminate rough edges are a real possibility. Truly experimental, unstable code has no place in the standard library in the first place (that's one of the things PyPI is for). For the record (and the PEP should probably mention this), the end user facing explanation of provisional modules is closely modelled on the one Red Hat use in explaining their Tech Preview concept: https://access.redhat.com/support/offerings/techpreview/ (Unfortunately, Google don't appear to have a clear user facing explanation of the meaning of "experimental" disclaimers in Google App Engine APIs, although it appears such APIs really are closer in nature to being truly experimental than what we're proposing for the stdlib) Now, what would make sense is to have a definition of "provisional API" in the glossary, and link to that from the module docs, rather than explaining the concept separately in each provisional module. The notice in each package could then be shortened to: The API has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the API) may occur if deemed necessary by the standard library developers. The phrase "provisional basis" would then be a link to the glossary term "provisional API", defined as: A provisional API is one which has been deliberately excluded from the standard library's normal backwards compatibility guarantees. While major changes to such APIs are not expected, as long as they are marked as provisional, backwards incompatible changes (up to and including removal of the API) may occur if deemed necessary by the standard library developers. Such changes will not be made gratuitously - they will occur only if serious flaws are uncovered that were missed prior to inclusion of the API. This process allows the standard library to continue to evolve over time, without locking in problematic design errors for extended periods of time. See PEP 411 for more details. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
On Sun, Feb 12, 2012 at 2:45 AM, Isaac Morland wrote: > Could the documentation generator simply insert the boilerplate if and only > if the package has the __provisional__ attribute? I'm not an expert in > Python documentation but isn't it generated from properly-formatted comments > within the Python source? It can be, but, in the case of the standard library, generally isn't. While there's a certain attraction to using a __provisional__ attribute (checked by both Sphinx and pydoc) to standardise the boilerplate for provisional APIs, I don't think PEP 411 should be conditional on deciding *how* we implement the notices. It should just say "provisional APIs permit well justified changes that would otherwise be disallowed by backwards compatibility concerns, and these are the notices that must be put in place to indicate to users that an API is provisional". Whether we do that via copy-and-paste in the docs and docstring or by a flag in the source code is really an implementation detail separate from the process definition. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] requirements for moving __import__ over to importlib?
Le 07/02/2012 23:21, Brett Cannon a écrit : > On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman wrote: >> Yeah, startup performance getting worse kinda sucks for command-line >> apps. And IIRC it's been getting worse over the past few releases... >> >> Anyway, I think there was enough of a python3 port for Mercurial (from >> various GSoC students) that you can probably run some of the very >> simple commands (like hg parents or hg id), which should be enough for >> your purposes, right? > Possibly. Where is the code? hg clone http://selenic.com/repo/hg/ cd hg python3 contrib/setup3k.py build ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
