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
The point is not the length of the string, but the size of string
space for inspection. To search for a string with a specified 64-bit
hash to iterate over 2 ** 64 strings. Spending on a single string scan
1 nanosecond (a very optimistic estimate), it would take 2 ** 64 / 1e9
/ (3600 * 24 *
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
Zitat von Serhiy Storchaka :
27.01.12 23:08, Frank Sievertsen написав(ла):
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 g
2012/1/28 T.B. :
> Hello python-dev,
>
> This is probably worth of a bug report: While looking at threading.py I
> noticed that Semaphore's counter can go below zero. This is opposed to the
> docs: "The counter can never go below zero; ...". Just try:
>
> import threading
> s = threading.Semaphore(
Hello python-dev,
This is probably worth of a bug report: While looking at threading.py I
noticed that Semaphore's counter can go below zero. This is opposed to
the docs: "The counter can never go below zero; ...". Just try:
import threading
s = threading.Semaphore(0.5)
# You can now acquire
Nick Coghlan wrote:
On Sat, Jan 28, 2012 at 10:33 AM, Ethan Furman wrote:
So the question is:
- should 'raise ... from ...' be legal outside a try block?
- should 'raise ... from None' be legal outside a try block?
Given that it would be quite a bit of work to make it illegal, my
preferen
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 14:21:18 +0200
Maciej Fijalkowski wrote:
> Hi
>
> Something that's maybe worth mentioning is that the "official" python
> benchmark suite http://hg.python.org/benchmarks/ has a pretty
> incomplete set of benchmarks for python 3 compared to say what we run
> for pypy: https://b
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
Am 28.01.2012 02:19, schrieb Benjamin Peterson:
> 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 thi
27.01.12 23:08, Frank Sievertsen написав(ла):
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 mu
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
27.01.12 23:08, Frank Sievertsen написав(ла):
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 mu
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
Hi
Something that's maybe worth mentioning is that the "official" python
benchmark suite http://hg.python.org/benchmarks/ has a pretty
incomplete set of benchmarks for python 3 compared to say what we run
for pypy: https://bitbucket.org/pypy/benchmarks I think a very
worthwhile project would be to
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
stefan brunthaler wrote:
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 t
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
44 matches
Mail list logo
