On Jan 26, 2012, at 7:19 PM, Ethan Furman wrote:
> One of the open issues from PEP 3134 is suppressing context: currently there
> is no way to do it. This PEP proposes one.
Thanks for proposing fixes to this issue.
It is an annoying problem.
Raymond
__
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 10:33 AM, Ethan Furman wrote:
> Because at this point it is possible to do:
>
> raise ValueError from NameError
>
> outside a try block. I don't see it as incredibly useful, but I don't know
> that it's worth making it illegal.
>
> So the question is:
>
> - should 'rai
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 Fri, Jan 27, 2012 at 5:19 PM, Benjamin Peterson wrote:
> Hello everyone,
> In effort to get a fix out before Perl 6 goes mainstream, Barry and I
> have decided to pronounce on what we want for our stable releases.
> What we have decided is that
> 1. Simple hash randomization is the way to go. W
2012/1/27 Steven D'Aprano :
> Benjamin Peterson wrote:
>>
>> Hello everyone,
>> In effort to get a fix out before Perl 6 goes mainstream, Barry and I
>> have decided to pronounce on what we want for our stable releases.
>> What we have decided is that
>> 1. Simple hash randomization is the way to g
Benjamin Peterson wrote:
Hello everyone,
In effort to get a fix out before Perl 6 goes mainstream, Barry and I
have decided to pronounce on what we want for our stable releases.
What we have decided is that
1. Simple hash randomization is the way to go. We think this has the
best chance of actual
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
1. Simple hash randomization is the way to go. We think this has the
best chance of actually fixing the problem while being fairly
straightforward such that we're comfortable putting it in a stable
release.
2. It will be off by default in stable releases and enabled by an
envar at runtime. This wi
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
2012/1/27 stefan brunthaler :
> Hi,
>
> On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote:
>> 2011/11/8 stefan brunthaler :
>>> How does that sound?
>>
>> I think I can hear real patches and benchmarks most clearly.
>>
> I spent the better part of my -20% time on implementing the work as
> "su
Hi,
On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote:
> 2011/11/8 stefan brunthaler :
>> How does that sound?
>
> I think I can hear real patches and benchmarks most clearly.
>
I spent the better part of my -20% time on implementing the work as
"suggested". Please find the benchmarks attache
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
Hello everyone,
In effort to get a fix out before Perl 6 goes mainstream, Barry and I
have decided to pronounce on what we want for our stable releases.
What we have decided is that
1. Simple hash randomization is the way to go. We think this has the
best chance of actually fixing the problem while
On Sat, 28 Jan 2012 01:53:40 +0100
mar...@v.loewis.de wrote:
>
> > How so? None of the patches did, but I think it was said several times
> > that other types (int, tuple, float) could also be converted to use
> > randomized hashes. What's more, there isn't any technical difficulty in
> > doing so
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
How so? None of the patches did, but I think it was said several times
that other types (int, tuple, float) could also be converted to use
randomized hashes. What's more, there isn't any technical difficulty in
doing so.
The challenge again is about incompatibility: the more types you apply th
Terry Reedy wrote:
The PEP does not address the issue of whether the new variation of raise
is valid outside of an except block. My memory is that it was not to be
and I think it should not be. One advantage of the 'as' form is that it
is clear that raising the default as something else is inva
Terry Reedy wrote:
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be
> I don't consider it mandatory to fix all issues with hash collision.
> In fact, none of the strategies fixes all issues with hash collisions;
> even the hash-randomization solutions only deal with string keys, and
> don't consider collisions on non-string keys.
How so? None of the patches did,
On 1/27/2012 11:39 AM, mar...@v.loewis.de wrote:
Another issue occurs to me: when a hash with colliding keys (one that
has been attacked, and has trees) has a non-string key added, isn't
the flattening process likely to have extremely poor performance?
Correct.
Thanks for the clarificatio
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 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better
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
As already mentioned, the vulnerability of 64-bit Python rather theoretical and
not practical. The size of the hash makes the attack is extremely unlikely.
Unfortunately this assumption is not correct. It works very good with
64bit-hashing.
It's much harder to create (efficiently) 64-bit has
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
2012/1/27 Serhiy Storchaka :
> As already mentioned, the vulnerability of 64-bit Python rather theoretical
> and not practical. The size of the hash makes the attack is extremely
> unlikely. Perhaps the easiest change, avoid 32-bit Python on the
> vulnerability, will use 64-bit (or more) hash on
As already mentioned, the vulnerability of 64-bit Python rather theoretical and
not practical. The size of the hash makes the attack is extremely unlikely.
Perhaps the easiest change, avoid 32-bit Python on the vulnerability, will use
64-bit (or more) hash on all platforms. The performance is co
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman wrote:
> Guido van Rossum wrote:
>>
>> Did you consider to just change the
>> words so users can ignore it more easily?
>
>
> Yes, that has also been discussed.
>
> Speaking for myself, it would be only slightly better.
>
> Speaking for everyone that w
Another issue occurs to me: when a hash with colliding keys (one
that has been attacked, and has trees) has a non-string key added,
isn't the flattening process likely to have extremely poor
performance?
Correct. "Don't do that, then"
I don't consider it mandatory to fix all issues with
On 1/26/2012 10:47 PM, Glenn Linderman wrote:
On 1/26/2012 10:25 PM, Gregory P. Smith wrote:
(and on top of all of this I believe we're all settled on having per
interpreter hash randomization_as well_ in 3.3; but this AVL tree
approach is one nice option for a backport to fix the major
vulnera
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better.
Speaking for everyone that wants context suppression (using Steven
D'Aprano's words): chained excep
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
ACTIVITY SUMMARY (2012-01-20 - 2012-01-27)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3234 (+25)
closed 22437 (+32)
total 25671 (+57)
Open issues wit
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
2012/1/26 Ethan Furman :
> PEP: XXX
Congratulations, you are now PEP 409.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
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
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.python.org/pipermail/python-ideas/2012-January/013246.html
However, note that my comment on Glenn's question regarding a stdlib
addition of a tree type still applies
I agree with all that. Having a tree-based mapping type in the standard
library is a different issue entirely.
___
Python-Dev mailing list
Pytho
mar...@v.loewis.de, 27.01.2012 09:55:
> So I found Ian Piumarta's AVL tree 1.0 from 2006. I trust Ian Piumarta
> to get it right (plus I reviewed the code a little). There are some
> API glitches (such as assuming a single comparison function, whereas
> it would better be rewritten to directly invo
I'm curious why AVL tree rather than RB tree, simpler implementation?
Somewhat arbitrary. AVL trees have a better performance than RB trees
(1.44 log2(N) vs 2 log2(N) in the worst case). Wrt. implementation,
I looked around for a trustworthy, reusable, free (as in speech),
C-only implementation
Glenn Linderman, 27.01.2012 07:47:
> Can we have a tree type in 3.3, independent of dict?
I'd be happy to see that happen, but I guess the usual requirements on
stdlib extensions would apply here. I.e., someone has to write the code,
make sure people actually use it to prove that it's worth being
74 matches
Mail list logo
