On behalf of the Python development team, I'm happy to announce the
first alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.
On Sun, Mar 4, 2012 at 12:35 PM, "Martin v. Löwis" wrote:
>> So, how to handle stack overflows (of the C stack)?
>> To prevent a stack overflow an exception must be raised before
>> the VM runs out C stack. To do this we need 2 pieces of info:
>> a) How much stack we've used
>> b) How much stack i
Armin Ronacher active-4.com> writes:
> I would hope they both have the same effect. Namely stripping the 'u'
> prefix in all variations.
Okay, that's all I was curious about.
> Why did I go with the tokenize approach? Because I never even
> considered a 2to3 solution. Part of the reason why
Am 04.03.2012 23:53, schrieb Steven D'Aprano:
> Armin Rigo wrote:
>> Hi Mark,
>>
>> On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
>>> You can't solve the too much time, without solving the halting problem,
>>
>> Not sure what you mean by that. It seems to me that it's particularly
>> easy to
Armin Ronacher active-4.com> writes:
> Considering such an import hook has to run over all imports because it
> would not know which to rewrite and which not I think it would be
> equally problematic, especially if libraries would magically activate
> that hook.
You could be right, but it sounds
Armin Rigo wrote:
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
You can't solve the too much time, without solving the halting problem,
Not sure what you mean by that. It seems to me that it's particularly
easy to do in a roughly portable way, with alarm() for example on all
UN
Hi,
On 3/4/12 9:00 PM, Vinay Sajip wrote:
> I realise that the implementation is different, using tokenize rather than
> lib2to3, but in terms of its effect on the transformed code, what are the
> differences between this hook and running 2to3 with just the fix_unicode
> fixer?
I would hope they
Hi,
On 3/4/12 4:44 PM, Guido van Rossum wrote:
> I'd love a pointer to the rubygems debacle...
Setuptools worked because Python had .pth files for a long, long time.
When the Ruby world started moving packages into nonstandard locations
(GameName/) something needed to activate that
import machiner
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
> You can't solve the too much time, without solving the halting problem,
Not sure what you mean by that. It seems to me that it's particularly
easy to do in a roughly portable way, with alarm() for example on all
UNIXes.
A bientôt,
Hi Greg,
On Sun, Mar 4, 2012 at 22:44, Greg Ewing wrote:
>> Segfaults (most of them) can generally be made into arbitrary code
>> execution,
>
> Can you give an example of how this can be done?
You should find tons of documented examples of various attacks. It's
not easy, but it's possible. Fo
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
> I don't think it is as hard as all that.
> All the crashers can be fixed, and with minimal effect on performance.
I will assume that you don't mean just to fix the files in
Lib/test/crashers, but to fix the general issues that each is
Mark Shannon wrote:
You can't solve the too much time, without solving the halting problem,
but you can make sure all code is interruptable (i.e. Cntrl-C works).
If you can arrange for Ctrl-C to interrupt the process cleanly,
then (at least on Unix) you can arrange to receive a signal
after a
Maciej Fijalkowski wrote:
Segfaults (most of them) can generally be made into arbitrary code
execution,
Can you give an example of how this can be done?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
Thomas Wouters wrote:
Why even have separate tp_as_sequence and tp_as_mapping anymore? That
particular distinction never existed for Python types, so why should it
exist for C types at all? I forget if there was ever a real point to it,
I imagine the original motivation was to provide a fast
Armin Ronacher active-4.com> writes:
> The current work in progress install time hook can be found here:
> https://github.com/mitsuhiko/unicode-literals-pep/tree/master/install-hook
I realise that the implementation is different, using tokenize rather than
lib2to3, but in terms of its effect o
> So, how to handle stack overflows (of the C stack)?
> To prevent a stack overflow an exception must be raised before
> the VM runs out C stack. To do this we need 2 pieces of info:
> a) How much stack we've used
> b) How much stack is available.
Python has already dedicated counters for stack de
On Sat, Mar 3, 2012 at 5:02 AM, Lennart Regebro wrote:
> I'm not sure that's true at all. In most cases where you support both
> Python 2 and Python 3, most strings will be "native", ie, without
> prefix in either Python 2 or Python 3. The native case is the most
> common case.
>
Exactly. The r
On Sun, 2012-03-04 at 17:34 +1000, Nick Coghlan wrote:
> My rewritten version of PEP 414 is now up
> (http://www.python.org/dev/peps/pep-0414/). It describes in detail a
> lot more of the historical background that was taken as read when
> Guido accepted the PEP.
"""
Just as support for string exc
On Mar 04, 2012, at 05:34 PM, Nick Coghlan wrote:
>My rewritten version of PEP 414 is now up
>(http://www.python.org/dev/peps/pep-0414/). It describes in detail a lot more
>of the historical background that was taken as read when Guido accepted the
>PEP.
Nick, really great job with your rewrite o
Armin Rigo wrote:
Hi all,
On Sun, Mar 4, 2012 at 03:51, Guido van Rossum wrote:
Could we put asserts in the places where segfaults may happen?
No. I checked Lib/test/crashers/*.py and none of them would be safe
with just a failing assert. If they were, we'd have written the
assert long ago
Hi all,
On Sun, Mar 4, 2012 at 03:51, Guido van Rossum wrote:
> Could we put asserts in the places where segfaults may happen?
No. I checked Lib/test/crashers/*.py and none of them would be safe
with just a failing assert. If they were, we'd have written the
assert long ago :-( "mutation_insi
On Sun, Mar 4, 2012 at 6:43 AM, Armin Ronacher
wrote:
> Please do not write or advocate for import hooks, especially not for
> porting purposes. It would either mean that people start adding that
> hook on their own to the code (and that awfully reminds me of the days
> of 'require "rubygems"' in
On Sat, Mar 3, 2012 at 11:34 PM, Nick Coghlan wrote:
> My rewritten version of PEP 414 is now up
> (http://www.python.org/dev/peps/pep-0414/). It describes in detail a
> lot more of the historical background that was taken as read when
> Guido accepted the PEP.
Thanks very much! It looks great to
Armin Ronacher active-4.com> writes:
> Please do not write or advocate for import hooks, especially not for
> porting purposes. It would either mean that people start adding that
> hook on their own to the code (and that awfully reminds me of the days
> of 'require "rubygems"' in the Ruby world)
There is even easier way to exceed the time-limit timeout and to eat CPU:
sum(xrange(10)).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
$ python execfile.py badhash.py
Hang up.
class badhash: __hash__ = int(42).__hash__
set([badhash() for _ in range(10)])
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Hi,
Jut to reiterate what I wrote on IRC:
Please do not write or advocate for import hooks, especially not for
porting purposes. It would either mean that people start adding that
hook on their own to the code (and that awfully reminds me of the days
of 'require "rubygems"' in the Ruby world) or
Hi,
On 3/4/12 2:01 PM, Nick Coghlan wrote:
> Nice :)
>
> Do you have any more updates left to do? I saw the change, the tests,
> the docs and the tokenizer updates go by on python-checkins, so if
> you're done we can mark the PEP as Final (at which point the inclusion
> in the first alpha is impl
On Sat, 3 Mar 2012 18:20:22 -0800
Thomas Wouters wrote:
>
> I'm not sure how the ABCs, which are abstract declarations of semantics,
> tie into this specific implementation detail. ABCs work just as well for
> Python types as for C types, and Python types don't have this distinction.
> The distin
On Sun, Mar 4, 2012 at 11:46 PM, Armin Ronacher
wrote:
> Hi,
>
> It should also be added that the Python 3.3 alpha will release with support:
>
> Python 3.3.0a0 (default:042e7481c7b4, Mar 4 2012, 12:37:26)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "cre
Hi,
It should also be added that the Python 3.3 alpha will release with support:
Python 3.3.0a0 (default:042e7481c7b4, Mar 4 2012, 12:37:26)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u"Hello" + ' World!'
Zbigniew Jędrzejewski-Szmek in.waw.pl> writes:
> if sys.version_info[0] < 3:
> raise NotImplementedError('This hook is implemented for Python 3 only')
>
> Wouldn't it be better if the hook did nothing when on python 2?
> I think it'll make it necessary to use something like
Actually I'v
On 03/04/2012 10:34 AM, Vinay Sajip wrote:
> https://bitbucket.org/vinay.sajip/uprefix/
import uprefix; uprefix.register_hook()
import frob.subwob.subsubwob
frob.subwob.subsubwob.w
Hi,
it's pretty cool that 150 lines is enough to have this functionality.
This guard:
if sys.ver
Stefan Krah, 04.03.2012 12:33:
> Thomas Wouters wrote:
>> Do you test against pydebug builds of Python, or otherwise a build that
>> actually enables asserts?
>
> Yes, I do (and much more than that):
>
> http://hg.python.org/features/cdecimal/file/40917e4b51aa/Modules/_decimal/python/runall-memor
Having a look at the "crashers" in Lib/test/crashers it seems to me that
they fall into four groups.
1. Unsafe gc functions like getreferrers()
2. Stack overflows.
3. "Normal" bugs that can be fixed on a case-by-case basis
(like borrowed_ref_1.py and borrowed_ref_2.py)
4. Things that don't crash
Thomas Wouters wrote:
> Do you test against pydebug builds of Python, or otherwise a build that
> actually enables asserts?
Yes, I do (and much more than that):
http://hg.python.org/features/cdecimal/file/40917e4b51aa/Modules/_decimal/python/runall-memorydebugger.sh
http://hg.python.org/features
Nick Coghlan gmail.com> writes:
> My rewritten version of PEP 414 is now up
> (http://www.python.org/dev/peps/pep-0414/). It describes in detail a
> lot more of the historical background that was taken as read when
> Guido accepted the PEP.
Nice work - thanks!
I've implemented a first attempt a
> Is your implementation (adapted to a standalone type) something you
> could put up on the cheeseshop?
Short answer: no.
My implementation (attached to the issue #14162) reuses most of
private PyDict functins which are not exported and these functions
have to be modified to accept a frozendict a
38 matches
Mail list logo
