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
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
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 invoke
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
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
+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
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.
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky eli...@gmail.com 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
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 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Benderskyeli...@gmail.com 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
2012/1/27 Eli Bendersky eli...@gmail.com:
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
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 no need
On 27/01/2012 15:34, Benjamin Peterson wrote:
2012/1/27 Eli Benderskyeli...@gmail.com:
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
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
2012/1/26 Ethan Furman et...@stoneleaf.us:
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:
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 given version of
Hello Philippe,
On Fri, 27 Jan 2012 17:09:08 +0100
Philippe Fremy p...@freehackers.org 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
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__ too?
I
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 and how you can
On Fri, Jan 27, 2012 at 17:34, Benjamin Peterson benja...@python.org wrote:
2012/1/27 Eli Bendersky eli...@gmail.com:
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
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
Eli Bendersky eliben at 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]
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
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
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 Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman et...@stoneleaf.us 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
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
2012/1/27 Serhiy Storchaka storch...@gmail.com:
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
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
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
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
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 be
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw ba...@python.org 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
On 27 January 2012 21:48, Antoine Pitrou solip...@pitrou.net 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
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furmanet...@stoneleaf.us 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
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 clearly
On Fri, 27 Jan 2012 17:54:14 -0500
Barry Warsaw ba...@python.org wrote:
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw ba...@python.org wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API,
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
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, but
Terry Reedy wrote:
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furmanet...@stoneleaf.us 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
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
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
On Fri, Jan 27, 2012 at 11:48 PM, Matt Joiner anacro...@gmail.com 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
n Sat, Jan 28, 2012 at 3:26 AM, Alex alex.gay...@gmail.com 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
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.
The
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
On Sat, Jan 28, 2012 at 6:43 AM, Steven D'Aprano st...@pearwood.info 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__
Hi,
On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson benja...@python.org wrote:
2011/11/8 stefan brunthaler s.bruntha...@uci.edu:
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.
2012/1/27 stefan brunthaler s.bruntha...@uci.edu:
Hi,
On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson benja...@python.org wrote:
2011/11/8 stefan brunthaler s.bruntha...@uci.edu:
How does that sound?
I think I can hear real patches and benchmarks most clearly.
I spent the better part of
On Sat, Jan 28, 2012 at 8:54 AM, Barry Warsaw ba...@python.org 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,
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
X offers this API for multiple Python versions with stronger API
stability guarantees. This preview version of
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
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
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 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
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
2012/1/27 Steven D'Aprano st...@pearwood.info:
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
On Fri, Jan 27, 2012 at 5:19 PM, Benjamin Peterson benja...@python.org 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
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
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).
Okay,
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
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
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 sufficiently
On Sat, Jan 28, 2012 at 07:41, Stephen J. Turnbull step...@xemacs.org 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)
On Sat, Jan 28, 2012 at 10:33 AM, Ethan Furman et...@stoneleaf.us 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:
-
On Sat, Jan 28, 2012 at 11:48 AM, Barry Warsaw ba...@python.org 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
On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull step...@xemacs.org 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
On Sat, Jan 28, 2012 at 4:37 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com 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
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 anacro...@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com
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
71 matches
Mail list logo
