On Feb 5, 2012 5:36 PM, "Steven D'Aprano" wrote:
>
> Paul Moore wrote:
>>
>> On 4 February 2012 11:25, Steven D'Aprano wrote:
>>>
>>> It strikes me that it would be helpful sometimes to programmatically
>>> recognise "preview" modules in the std lib. Could we have a
recommendation
>>> in PEP 8 th
Paul Moore wrote:
On 4 February 2012 11:25, Steven D'Aprano wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise "preview" modules in the std lib. Could we have a recommendation
in PEP 8 that such modules should have a global variable called PREVIEW, and
non-pre
+1
On Feb 4, 2012 8:37 PM, "Paul Moore" wrote:
>
> On 4 February 2012 11:25, Steven D'Aprano wrote:
> > It strikes me that it would be helpful sometimes to programmatically
> > recognise "preview" modules in the std lib. Could we have a
recommendation
> > in PEP 8 that such modules should have a
On 4 February 2012 11:25, Steven D'Aprano wrote:
> It strikes me that it would be helpful sometimes to programmatically
> recognise "preview" modules in the std lib. Could we have a recommendation
> in PEP 8 that such modules should have a global variable called PREVIEW, and
> non-preview modules
Terry Reedy wrote:
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed und
Woohoo! :)
___
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
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed under Abandoned, Withdr
Chris Withers wrote:
Every time I see things like the following I cry a little inside:
try:
try:
from py2stdliblocation import FooBar as Foo
except ImportError:
from py3stdliblocation import foo as Foo
except ImportError:
from pypilocation import Foo
The syntax is inelegant, bu
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org
On Tue, Jan 31, 2012 at 4:59 AM, Antoine Pitrou wrote:
> It would be nice if that pronouncement or decision could outline the
> steps required to include an "experimental" module in the stdlib, and
> the steps required to move it from "experimental" to "stable".
Actually, that's a good idea - Eli
On Sun, 29 Jan 2012 16:42:28 +1000
Nick Coghlan wrote:
> On Sun, Jan 29, 2012 at 1:29 PM, Guido van Rossum wrote:
> > On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan wrote:
> >> I'm willing to go along with that (especially given your report of
> >> AppEngine's experience with the "labs" namespace
Maybe that's another example of waiting too long for the perfect
decision though. In the last ~12 months, ipaddr was downloaded at
least 11,000 times from its home
(http://code.google.com/p/ipaddr-py/downloads/list). There's been a
fair amount of changes over that time and a new release was put out
On 1/29/2012 4:39 PM, Gregory P. Smith wrote:
> An example of this working: ipaddr is ready to go in. It got the
> eyeballs and API modifications while still a pypi library as a result
> of the discussion around the time it was originally suggested as being
> added. I or any other committers have
I think an advocacy of 3rd party modules would start with modules such as
ipaddr, requests, regex. Linking directly to them from the python core
documentation, while requesting they hold a successful moratorium in order
to be included in a later standard module release.
On Jan 30, 2012 10:47 AM, "N
On Mon, Jan 30, 2012 at 8:44 AM, Barry Warsaw wrote:
> Nothing beats people beating on it heavily for years in production code to
> shake things out. I often think a generic answer to "did I get the API right"
> could be "no, but it's okay" :)
Heh, my answer to complaints about the urrlib (etc)
On Jan 28, 2012, at 07:29 PM, Guido van Rossum wrote:
>Finally, if you really want to put warnings in whenever an
>experimental module is being used, make it a silent warning, like
>SilentDeprecationWarning. That allows people to request more strict
>warnings without unduly alarming the users of a
On 29 January 2012 21:39, Gregory P. Smith wrote:
> An example of this working: ipaddr is ready to go in. It got the
> eyeballs and API modifications while still a pypi library as a result
> of the discussion around the time it was originally suggested as being
> added. I or any other committers
On Fri, Jan 27, 2012 at 9:26 AM, Alex wrote:
> Eli Bendersky gmail.com> writes:
>
>>
>> Hello,
>>
>> Following an earlier discussion on python-ideas [1], we would like to
>> propose the following PEP for review. Discussion is welcome. The PEP
>> can also be viewed in HTML form at
>> http://www.py
On Sun, Jan 29, 2012 at 1:29 PM, Guido van Rossum wrote:
> On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan wrote:
>> I'm willing to go along with that (especially given your report of
>> AppEngine's experience with the "labs" namespace).
>>
>> Can we class this as a pronouncement on PEP 408? That i
On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan wrote:
> I'm willing to go along with that (especially given your report of
> AppEngine's experience with the "labs" namespace).
>
> Can we class this as a pronouncement on PEP 408? That is, "No to
> adding a __preview__ namespace, but yes to adding re
On Sun, Jan 29, 2012 at 3:15 AM, Guido van Rossum wrote:
> Hm. You could do this just as well without a __preview__ package. You
> just flag the module as experimental in the docs and get on with your
> life.
>
> We have some experience with this in Google App Engine. We used to use
> a separate "
On 1/28/2012 3:55 AM, Nick Coghlan wrote:
I am currently -something on the proposal as it because it will surely
create a lot of hassles and because I do not think it is necessary the
best solution to the motivating concerns.
Don't consider this PEP a purely theoretical proposal, because it
On Sat, Jan 28, 2012 at 4:08 PM, Antoine Pitrou wrote:
> Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
>> On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
>> > There are many reasons to import a module, such as viewing its
>> > documentation. And the warning will trigger if t
Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
> On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
> > There are many reasons to import a module, such as viewing its
> > documentation. And the warning will trigger if the import happens in
> > non-user code, such as a library; or
On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
> There are many reasons to import a module, such as viewing its
> documentation. And the warning will trigger if the import happens in
> non-user code, such as a library; or when there is a fallback for the
> module not being present. People
> >You're proposing that new experimental modules spit warnings when you
> >use them?
>
> To be explicit, when the system loada them.
There are many reasons to import a module, such as viewing its
documentation. And the warning will trigger if the import happens in
non-user code, such as a libra
Antoine Pitrou wrote:
>Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit :
>> Antoine Pitrou wrote:
>> >You will see people copying recipes found on the internet without
>> >knowing that they rely on unstable APIs.
>>
>> How. About doing them the way we do depreciated modules, and hav
Michael Foord wrote:
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
I think it's a bad idea to introduce a feature that's *supposed* to
break (in the sense of "make a break", ie, change the normal pattern)
with every release and then try to avoid breaking (in the sense of
"causing an unexpected
Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit :
> Antoine Pitrou wrote:
>
> >On Sat, 28 Jan 2012 13:14:36 -0500
> >Barry Warsaw wrote:
> >> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
> >>
> >> >So I do not support the __preview__ package. I think we're better
> >off
> >
Antoine Pitrou wrote:
>On Sat, 28 Jan 2012 13:14:36 -0500
>Barry Warsaw wrote:
>> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
>>
>> >So I do not support the __preview__ package. I think we're better
>off
>> >flagging experimental modules in the docs than in their name. For
>the
>> >sp
On Sat, 28 Jan 2012 13:14:36 -0500
Barry Warsaw wrote:
> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
>
> >So I do not support the __preview__ package. I think we're better off
> >flagging experimental modules in the docs than in their name. For the
> >specific case of the regex module,
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
>So I do not support the __preview__ package. I think we're better off
>flagging experimental modules in the docs than in their name. For the
>specific case of the regex module, the best way to adoption may just
>be to include it in the stdlib
On Sat, Jan 28, 2012 at 5:04 AM, Paul Moore wrote:
> On 28 January 2012 09:18, Nick Coghlan wrote:
>
>> It's basically us saying to Python users "We're explicitly flagging
>> this PyPI module for inclusion in the next major Python release. We've
>> integrated it into our build process, test suite
On Sat, 28 Jan 2012 00:09:13 -0500
Scott Dial wrote:
> On 1/27/2012 8:48 PM, Barry Warsaw wrote:
> > The thinking goes like this: if you would normally use an __preview__ module
> > because you can't get approval to download some random package from PyPI,
> > well
> > then your distro probably co
On Sat, 28 Jan 2012 02:49:40 -0500
Matt Joiner wrote:
> FWIW I'm now -1 for this idea. Stronger integration with PyPI and
> packaging systems is much preferable.
That will probably never happen. "pip install XXX" is the best we
(python-dev and the community) can do. "import some_module" won't
mag
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
Michael Foord writes:
> >> Assuming the module is then promoted to the the standard library
proper in
> >> release ``3.X+1``, it will be moved to a permanent location in the
library::
> >>
> >> import example
> >>
> >>
On 28/01/2012 13:55, Matt Joiner wrote:
__preview__ would fall into this category as well). And yet I have
essentially no means of gaining access to any 3rd party modules,
whether they are packaged by the distro or obtained from PyPI. (And
"build your own" isn't an option in many cases, if only
On 28/01/2012 05:09, Scott Dial wrote:
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so ge
On 27/01/2012 22:54, Barry Warsaw wrote:
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API, and I think despite the caveats that are explicit in
__
On 28/01/2012 13:04, Paul Moore wrote:
On 28 January 2012 09:18, Nick Coghlan wrote:
It's basically us saying to Python users "We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into our build process, test suite and binary releases,
Hi,
Am 27.01.2012 um 18:26 schrieb Alex:
> I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
> instead of it's final destination directly because it needs feedback/possibly
> changes. However, given the release cycle of the stdlib (~18 months), any
> feedback it gets ca
> __preview__ would fall into this category as well). And yet I have
> essentially no means of gaining access to any 3rd party modules,
> whether they are packaged by the distro or obtained from PyPI. (And
> "build your own" isn't an option in many cases, if only because a C
> compiler may well no
On 1/28/2012 2:10 AM, Nick Coghlan wrote:
> On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull
> wrote:
>> Executive summary:
>>
>> If the promise to remove the module from __preview__ is credible (ie,
>> strictly kept), then __preview__ will have a specific audience in
>> those who want the st
On 28 January 2012 01:48, Barry Warsaw wrote:
> The thinking goes like this: if you would normally use an __preview__ module
> because you can't get approval to download some random package from PyPI, well
> then your distro probably could or should provide it, so get it from them. In
> fact, if
On 28 January 2012 09:18, Nick Coghlan wrote:
> It's basically us saying to Python users "We're explicitly flagging
> this PyPI module for inclusion in the next major Python release. We've
> integrated it into our build process, test suite and binary releases,
> so you don't even have to download
Wiadomość napisana przez Simon Cross w dniu 28 sty 2012, o godz. 08:58:
> +1. I'd much rather just use the module from PyPI.
>
> It would be good to have a practical guide on how to manage the
> transition from third-party to core library module though. A PEP with
> a list of modules earmarked fo
On Sat, Jan 28, 2012 at 6:38 PM, Stephen J. Turnbull wrote:
> I don't have an opinion on whether this is an argument for rejecting
> the PEP or for rewriting it (specifically, seriously beefing up the
> "after trying it, maybe we won't want to maintain it" rationale). I
> also think that if "we n
On Sat, Jan 28, 2012 at 5:49 PM, Matt Joiner wrote:
> FWIW I'm now -1 for this idea. Stronger integration with PyPI and
> packaging systems is much preferable. Python core public releases are
> no place for testing.
People saying this: we KNOW this approach doesn't work in all cases.
If it worked
Nick Coghlan writes:
> People need to remember there's another half to this equation: the
> core dev side.
Why? There's nothing about it in the PEP.
> The reason *regex* specifically isn't in the stdlib already is
> largely due to (perhaps excessive) concerns about the potential
> maintena
> +1. I'd much rather just use the module from PyPI.
>
> It would be good to have a practical guide on how to manage the
> transition from third-party to core library module though. A PEP with
> a list of modules earmarked for upcoming inclusion in the standard
> library (and which Python version t
On Sat, Jan 28, 2012 at 9:49 AM, Matt Joiner wrote:
> FWIW I'm now -1 for this idea. Stronger integration with PyPI and
> packaging systems is much preferable. Python core public releases are
> no place for testing.
+1. I'd much rather just use the module from PyPI.
It would be good to have a pr
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
On Sat, Jan 28, 2012 at 2:42 AM, Matt Joiner wrote:
> On Fri, Jan 27, 2012 at 12:26 PM, Alex wrote:
>> I think a significantly healthier p
On Fri, Jan 27, 2012 at 12:26 PM, Alex wrote:
> I think a significantly healthier process (in terms of maximizing feedback and
> getting something into it's best shape) is to let a project evolve naturally
> on
> PyPi and in the ecosystem, give feedback to it from an inclusion perspective,
> and
On Sat, Jan 28, 2012 at 4:37 PM, Nick Coghlan wrote:
> I think that's an excellent idea - in that case, the distro vendor is
> taking over the due diligence responsibilities, which are the main
> point of __preview__.
Heh, contradicted myself in my next email. python-dev handling due
diligence is
On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull wrote:
> Executive summary:
>
> If the promise to remove the module from __preview__ is credible (ie,
> strictly kept), then __preview__ will have a specific audience in
> those who want the stdlib candidate code and are willing to deal with
> a
On Sat, Jan 28, 2012 at 11:48 AM, Barry Warsaw wrote:
> Would it be acceptable then for a distro to disable __preview__ or empty it
> out?
>
> The thinking goes like this: if you would normally use an __preview__ module
> because you can't get approval to download some random package from PyPI, we
On Sat, Jan 28, 2012 at 07:41, Stephen J. Turnbull wrote:
> Eli Bendersky writes:
>
> > My point is that if our users accept *this*, in the stable stdlib, I
> > see no reason they won't accept the same happening between __preview__
> > and a graduated module, when they (hopefully) understand th
Eli Bendersky writes:
> My point is that if our users accept *this*, in the stable stdlib, I
> see no reason they won't accept the same happening between __preview__
> and a graduated module, when they (hopefully) understand the intention
> of __preview__.
If it doesn't happen with sufficient
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
> The thinking goes like this: if you would normally use an __preview__ module
> because you can't get approval to download some random package from PyPI, well
> then your distro probably could or should provide it, so get it from them.
That is my thought
Executive summary:
If the promise to remove the module from __preview__ is credible (ie,
strictly kept), then __preview__ will have a specific audience in
those who want the stdlib candidate code and are willing to deal with
a certain amount of instability in that code.
(Whether that audience is
Michael Foord writes:
> >> Assuming the module is then promoted to the the standard library proper in
> >> release ``3.X+1``, it will be moved to a permanent location in the
> >> library::
> >>
> >> import example
> >>
> >> And importing it from ``__preview__`` will no longer work.
>
>> No, potentially wrong in cases where the APIs are different. Even with the
>> try...except ImportError dance around StringIO / cStringIO there are some
>> API differences. But for a lot of use cases it works fine (simplejson and
>> json aren't *identical*, but it works for most people).
>
>
>
>
Michael Foord wrote:
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it i
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial a
On 27/01/2012 20:43, Steven D'Aprano wrote:
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT
expected to have a for
On Jan 28, 2012, at 11:13 AM, Nick Coghlan wrote:
>Really, regex is the *reason* this PEP exists: we *know* we need to
>either replace or seriously enhance "re" (since its Unicode handling
>isn't up to scratch), but we're only *pretty sure* adding "regex" to
>the stdlib is the right answer. Adding
On Jan 28, 2012, at 11:27 AM, Nick Coghlan wrote:
>* for an intranet web service deployment where due diligence adds
>significant overhead to any use of third party packages
Which really means that *we* are assuming the responsibility for this due
diligence. And of course, we should not add anyt
On Jan 28, 2012, at 11:37 AM, Nick Coghlan wrote:
>Then the stdlib docs for that module (while it is in __preview__)
>would say "If you are able to easily use third party packages, package
> offers this API for multiple Python versions with stronger API
>stability guarantees. This preview version
On Sat, Jan 28, 2012 at 8:54 AM, Barry Warsaw wrote:
> I think the OS vendor problem is easier with an application that uses some
> PyPI package, because I can always make that package available to the
> application by pulling in the version I care about. It's harder if a newer,
> incompatible ve
On Sat, Jan 28, 2012 at 6:43 AM, Steven D'Aprano wrote:
> This PEP only makes sense if we assume that __preview__.spam and spam *will*
> be different, even if only in minor ways, and that there might not even be a
> spam. There should be no expectation that every __preview__ module must
> graduate
n Sat, Jan 28, 2012 at 3:26 AM, Alex wrote:
> I think a significantly healthier process (in terms of maximizing feedback and
> getting something into it's best shape) is to let a project evolve naturally
> on
> PyPi and in the ecosystem, give feedback to it from an inclusion perspective,
> and th
On Fri, Jan 27, 2012 at 11:48 PM, Matt Joiner wrote:
> +0. I think the idea is right, and will help to get good quality
> modules in at a faster rate. However it is compensating for a lack of
> interface and packaging standardization in the 3rd party module world.
No, it really isn't. virtualenv
On Fri, 27 Jan 2012 17:54:14 -0500
Barry Warsaw wrote:
> On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
>
> >On Fri, 27 Jan 2012 16:10:51 -0500
> >Barry Warsaw wrote:
> >>
> >> I'm -1 on this as well. It just feels like the completely wrong way to
> >> stabilize an API, and I think despit
On Jan 27, 2012, at 10:02 PM, Paul Moore wrote:
>Agreed entirely. We need a way to signal somehow that a module is
>being seriously considered for stdlib inclusion. That *would* result
>in more uptake, and hence more testing and feedback.
I'm just not convinced that's a message that we can clearl
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
>On Fri, 27 Jan 2012 16:10:51 -0500
>Barry Warsaw wrote:
>>
>> I'm -1 on this as well. It just feels like the completely wrong way to
>> stabilize an API, and I think despite the caveats that are explicit in
>> __preview__, Python will just ca
On 27 January 2012 21:48, Antoine Pitrou wrote:
> Well, obviously __preview__ is not for the most conservative users. I
> think the name clearly conveys the idea that you are trying out
> something which is not in its definitive state, doesn't it?
Agreed. But that in turn implies to me that __pre
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw wrote:
>
> I'm -1 on this as well. It just feels like the completely wrong way to
> stabilize an API, and I think despite the caveats that are explicit in
> __preview__, Python will just catch tons of grief from users and haters about
> API instabi
On Jan 27, 2012, at 05:26 PM, Alex wrote:
>I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
>instead of it's final destination directly because it needs feedback/possibly
>changes. However, given the release cycle of the stdlib (~18 months), any
>feedback it gets can't
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial and wrong.
Since thing and __preview__.thing
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT expected to
have a forward-compatible, stable, API. This is a featu
Eli Bendersky gmail.com> writes:
>
> Hello,
>
> Following an earlier discussion on python-ideas [1], we would like to
> propose the following PEP for review. Discussion is welcome. The PEP
> can also be viewed in HTML form at
> http://www.python.org/dev/peps/pep-0408/
>
> [1] http://mail.pytho
On Fri, Jan 27, 2012 at 17:34, Benjamin Peterson wrote:
> 2012/1/27 Eli Bendersky :
>> Criteria for "graduation"
>> -
>
> I think you also need "Criteria for being placed in __preview__". Do
> we just toss everything someone suggests in?
>
I hoped to have this covered by:
>> Something along the lines of :
>>
>> if sys.version_info[:2] == (3, X):
>> from __preview__ import example
>> else:
>> raise ImportError( 'Package example is only available as preview in
>> Python version 3.X. Please check the documentation of your version of
>> Python to see if an
>> Assuming the module is then promoted to the the standard library proper in
>> release ``3.X+1``, it will be moved to a permanent location in the library::
>>
>> import example
>>
>> And importing it from ``__preview__`` will no longer work.
>
> Why not leave it accessible through __preview__
Hello Philippe,
On Fri, 27 Jan 2012 17:09:08 +0100
Philippe Fremy wrote:
>
> According to the PEP, the interface may change betweeen __preview__ and
> final inclusion in stdlib. It would be unwise as a developer to assume
> that a program written for the preview version will work correctly in
>
On 27/01/2012 16:25, Michael Foord wrote:
> On 27/01/2012 14:37, Philippe Fremy wrote:
>> Hi,
>>
>> A small comment from a user perspective.
>>
>> Since a package in preview is strongly linked to a given version of
>> Python, any program taking advantage of it becomes strongly specific to
>> a give
On 27/01/2012 15:35, Matt Joiner wrote:
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson -> json):
try:
from __preview__ import thing
except Import
On 27/01/2012 15:34, Benjamin Peterson wrote:
2012/1/27 Eli Bendersky:
Criteria for "graduation"
-
I think you also need "Criteria for being placed in __preview__". Do
we just toss everything someone suggests in?
And given that permanently deleting something from __pre
> A more normal incantation, as is often the way for packages that became
> parts of the standard library after first being a third party library
> (sometimes under a different name, e.g. simplejson -> json):
>
> try:
> from __preview__ import thing
> except ImportError:
> import thing
>
> So
2012/1/27 Eli Bendersky :
> Criteria for "graduation"
> -
I think you also need "Criteria for being placed in __preview__". Do
we just toss everything someone suggests in?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org/
On 27/01/2012 14:37, Philippe Fremy wrote:
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
>
> Following an earlier discussion on python-ideas [1], we would like to
> propose the following PEP for review. Discussion is welcome. The PEP
> can also be viewed in HTML form at
> http://www.python.org/dev/peps/pep-0408/
A big +1 from m
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for any upgrade or downgrade of
python version. T
+0. I think the idea is right, and will help to get good quality
modules in at a faster rate. However it is compensating for a lack of
interface and packaging standardization in the 3rd party module world.
___
Python-Dev mailing list
Python-Dev@python.org
95 matches
Mail list logo
