Re: [Python-Dev] Pyston: a Python JIT on LLVM

[Antoine Pitrou]

Hello,

Le 03/04/2014 20:19, Kevin Modzelewski a écrit :

I'm excited to announce Pyston, a Python JIT under development at
Dropbox, built on top of LLVM.  You can read more about it at the
introductory blog post
,
or check out the code on github .


I'm a bit surprised by the approach. Why don't you simply process 
CPython bytecode, rather than strive to reimplement Python fully?


Also, I wonder if it's worthwhile to use a conservative GC, rather than 
reuse the original refcounting scheme (especially since you want to 
support existing extension modules).


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pyston: a Python JIT on LLVM

[Dag Sverre Seljebotn]

On 04/04/2014 12:42 AM, Sturla Molden wrote:

Kevin Modzelewski  wrote:


Since it's the question that I think most people will inevitably (and
rightly) ask, why do we think there's a place for Pyston when there's PyPy
and (previously) Unladen Swallow?


Have you seen Numba, the Python JIT that integrates with NumPy?

http://numba.pydata.org


Specifically, Numba compiles to LLVM too, and tries to be somewhat 
general-purpose although it's tuned to numerical code. And their reason 
for not using PyPy is the same: C extensions. So while their "market 
segment" is different from yours, the technology may not be.


Dag Sverre




It uses LLVM to compile Python bytecode. When I have tried it I tend to get
speed comparable to -O2 in C for numerical and algorithmic code.

Here is an example, giving a 150 times speed boost to Python:

http://stackoverflow.com/questions/21811381/how-to-shove-this-loop-into-numpy/21818591#21818591


Sturla

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/d.s.seljebotn%40astro.uio.no



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Brett Cannon]

This broke compilation on at least OS X, but I'm willing to bet for all
UNIX-based systems. I have a fix in the works.


On Fri, Apr 4, 2014 at 9:34 AM, giampaolo.rodola  wrote:

> http://hg.python.org/cpython/rev/c9239171e429
> changeset:   90128:c9239171e429
> user:Giampaolo Rodola' 
> date:Fri Apr 04 15:34:17 2014 +0200
> summary:
>   fix #21076: turn signal module constants into enums
>
> files:
>   Doc/library/signal.rst   |  10 +++
>   Doc/whatsnew/3.5.rst |   5 +
>   Lib/signal.py|  84 
>   Lib/test/test_doctest.py |   2 +-
>   Lib/test/test_signal.py  |  39 +++-
>   Modules/signalmodule.c   |   4 +-
>   PC/config.c  |   2 +-
>   7 files changed, 138 insertions(+), 8 deletions(-)
>
>
> diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst
> --- a/Doc/library/signal.rst
> +++ b/Doc/library/signal.rst
> @@ -65,6 +65,16 @@
>  Module contents
>  ---
>
> +.. versionchanged:: 3.5
> +   signal (SIG*), handler (:const:`SIG_DFL`, :const:`SIG_IGN`) and sigmask
> +   (:const:`SIG_BLOCK`, :const:`SIG_UNBLOCK`, :const:`SIG_SETMASK`)
> +   related constants listed below were turned into
> +   :class:`enums `.
> +   :func:`getsignal`, :func:`pthread_sigmask`, :func:`sigpending` and
> +   :func:`sigwait` functions return human-readable
> +   :class:`enums `.
> +
> +
>  The variables defined in the :mod:`signal` module are:
>
>
> diff --git a/Doc/whatsnew/3.5.rst b/Doc/whatsnew/3.5.rst
> --- a/Doc/whatsnew/3.5.rst
> +++ b/Doc/whatsnew/3.5.rst
> @@ -134,6 +134,11 @@
>  Improved Modules
>  
>
> +* Different constants of :mod:`signal` module are now enumeration values
> using
> +  the :mod:`enum` module. This allows meaningful names to be printed
> during
> +  debugging, instead of integer “magic numbers”. (contribute by Giampaolo
> +  Rodola' in :issue:`21076`)
> +
>  * :class:`xmlrpc.client.ServerProxy` is now a :term:`context manager`
>(contributed by Claudiu Popa in :issue:`20627`).
>
> diff --git a/Lib/signal.py b/Lib/signal.py
> new file mode 100644
> --- /dev/null
> +++ b/Lib/signal.py
> @@ -0,0 +1,84 @@
> +import _signal
> +from _signal import *
> +from functools import wraps as _wraps
> +from enum import IntEnum as _IntEnum
> +
> +_globals = globals()
> +
> +Signals = _IntEnum(
> +'Signals',
> +{name: value for name, value in _globals.items()
> + if name.isupper()
> +and (name.startswith('SIG') and not name.startswith('SIG_'))
> +or name.startswith('CTRL_')})
> +
> +class Handlers(_IntEnum):
> +SIG_DFL = _signal.SIG_DFL
> +SIG_IGN = _signal.SIG_IGN
> +
> +_globals.update(Signals.__members__)
> +_globals.update(Handlers.__members__)
> +
> +if 'pthread_sigmask' in _globals:
> +class Sigmasks(_IntEnum):
> +SIG_BLOCK = _signal.SIG_BLOCK
> +SIG_UNBLOCK = _signal.SIG_UNBLOCK
> +SIG_SETMASK = _signal.SIG_SETMASK
> +
> +_globals.update(Sigmasks.__members__)
> +
> +
> +def _int_to_enum(value, enum_klass):
> +"""Convert a numeric value to an IntEnum member.
> +If it's not a known member, return the numeric value itself.
> +"""
> +try:
> +return enum_klass(value)
> +except ValueError:
> +return value
> +
> +
> +def _enum_to_int(value):
> +"""Convert an IntEnum member to a numeric value.
> +If it's not a IntEnum member return the value itself.
> +"""
> +try:
> +return int(value)
> +except (ValueError, TypeError):
> +return value
> +
> +
> +@_wraps(_signal.signal)
> +def signal(signalnum, handler):
> +handler = _signal.signal(_enum_to_int(signalnum),
> _enum_to_int(handler))
> +return _int_to_enum(handler, Handlers)
> +
> +
> +@_wraps(_signal.getsignal)
> +def getsignal(signalnum):
> +handler = _signal.getsignal(signalnum)
> +return _int_to_enum(handler, Handlers)
> +
> +
> +if 'pthread_sigmask' in _globals:
> +@_wraps(_signal.pthread_sigmask)
> +def pthread_sigmask(how, mask):
> +sigs_set = _signal.pthread_sigmask(how, mask)
> +return set(_int_to_enum(x, Signals) for x in sigs_set)
> +pthread_sigmask.__doc__ = _signal.pthread_sigmask.__doc__
> +
> +
> +@_wraps(_signal.sigpending)
> +def sigpending():
> +sigs = _signal.sigpending()
> +return set(_int_to_enum(x, Signals) for x in sigs)
> +
> +
> +if 'sigwait' in _globals:
> +@_wraps(_signal.sigwait)
> +def sigwait(sigset):
> +retsig = _signal.sigwait(sigset)
> +return _int_to_enum(retsig, Signals)
> +sigwait.__doc__ = _signal.sigwait
> +
> +del _globals, _wraps
> diff --git a/Lib/test/test_doctest.py b/Lib/test/test_doctest.py
> --- a/Lib/test/test_doctest.py
> +++ b/Lib/test/test_doctest.py
> @@ -2897,7 +2897,7 @@
>
>  def test_main():
>  # Check the doctest cases in doctest itself:
> -support.run_doctest(doctest, verbosity=True)
> +ret = support.run_doctest(doctest, verbosity=True)
>  # Check the doctest cases defined here:

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Brett Cannon]

On Fri, Apr 4, 2014 at 10:12 AM, Brett Cannon  wrote:

> This broke compilation on at least OS X, but I'm willing to bet for all
> UNIX-based systems. I have a fix in the works.
>

Fix is in rev c6e63bb132fb .


>
>
> On Fri, Apr 4, 2014 at 9:34 AM, giampaolo.rodola <
> python-check...@python.org> wrote:
>
>> http://hg.python.org/cpython/rev/c9239171e429
>> changeset:   90128:c9239171e429
>> user:Giampaolo Rodola' 
>> date:Fri Apr 04 15:34:17 2014 +0200
>> summary:
>>   fix #21076: turn signal module constants into enums
>>
>> files:
>>   Doc/library/signal.rst   |  10 +++
>>   Doc/whatsnew/3.5.rst |   5 +
>>   Lib/signal.py|  84 
>>   Lib/test/test_doctest.py |   2 +-
>>   Lib/test/test_signal.py  |  39 +++-
>>   Modules/signalmodule.c   |   4 +-
>>   PC/config.c  |   2 +-
>>   7 files changed, 138 insertions(+), 8 deletions(-)
>>
>>
>> diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst
>> --- a/Doc/library/signal.rst
>> +++ b/Doc/library/signal.rst
>> @@ -65,6 +65,16 @@
>>  Module contents
>>  ---
>>
>> +.. versionchanged:: 3.5
>> +   signal (SIG*), handler (:const:`SIG_DFL`, :const:`SIG_IGN`) and
>> sigmask
>> +   (:const:`SIG_BLOCK`, :const:`SIG_UNBLOCK`, :const:`SIG_SETMASK`)
>> +   related constants listed below were turned into
>> +   :class:`enums `.
>> +   :func:`getsignal`, :func:`pthread_sigmask`, :func:`sigpending` and
>> +   :func:`sigwait` functions return human-readable
>> +   :class:`enums `.
>> +
>> +
>>  The variables defined in the :mod:`signal` module are:
>>
>>
>> diff --git a/Doc/whatsnew/3.5.rst b/Doc/whatsnew/3.5.rst
>> --- a/Doc/whatsnew/3.5.rst
>> +++ b/Doc/whatsnew/3.5.rst
>> @@ -134,6 +134,11 @@
>>  Improved Modules
>>  
>>
>> +* Different constants of :mod:`signal` module are now enumeration values
>> using
>> +  the :mod:`enum` module. This allows meaningful names to be printed
>> during
>> +  debugging, instead of integer “magic numbers”. (contribute by Giampaolo
>> +  Rodola' in :issue:`21076`)
>> +
>>  * :class:`xmlrpc.client.ServerProxy` is now a :term:`context manager`
>>(contributed by Claudiu Popa in :issue:`20627`).
>>
>> diff --git a/Lib/signal.py b/Lib/signal.py
>> new file mode 100644
>> --- /dev/null
>> +++ b/Lib/signal.py
>> @@ -0,0 +1,84 @@
>> +import _signal
>> +from _signal import *
>> +from functools import wraps as _wraps
>> +from enum import IntEnum as _IntEnum
>> +
>> +_globals = globals()
>> +
>> +Signals = _IntEnum(
>> +'Signals',
>> +{name: value for name, value in _globals.items()
>> + if name.isupper()
>> +and (name.startswith('SIG') and not name.startswith('SIG_'))
>> +or name.startswith('CTRL_')})
>> +
>> +class Handlers(_IntEnum):
>> +SIG_DFL = _signal.SIG_DFL
>> +SIG_IGN = _signal.SIG_IGN
>> +
>> +_globals.update(Signals.__members__)
>> +_globals.update(Handlers.__members__)
>> +
>> +if 'pthread_sigmask' in _globals:
>> +class Sigmasks(_IntEnum):
>> +SIG_BLOCK = _signal.SIG_BLOCK
>> +SIG_UNBLOCK = _signal.SIG_UNBLOCK
>> +SIG_SETMASK = _signal.SIG_SETMASK
>> +
>> +_globals.update(Sigmasks.__members__)
>> +
>> +
>> +def _int_to_enum(value, enum_klass):
>> +"""Convert a numeric value to an IntEnum member.
>> +If it's not a known member, return the numeric value itself.
>> +"""
>> +try:
>> +return enum_klass(value)
>> +except ValueError:
>> +return value
>> +
>> +
>> +def _enum_to_int(value):
>> +"""Convert an IntEnum member to a numeric value.
>> +If it's not a IntEnum member return the value itself.
>> +"""
>> +try:
>> +return int(value)
>> +except (ValueError, TypeError):
>> +return value
>> +
>> +
>> +@_wraps(_signal.signal)
>> +def signal(signalnum, handler):
>> +handler = _signal.signal(_enum_to_int(signalnum),
>> _enum_to_int(handler))
>> +return _int_to_enum(handler, Handlers)
>> +
>> +
>> +@_wraps(_signal.getsignal)
>> +def getsignal(signalnum):
>> +handler = _signal.getsignal(signalnum)
>> +return _int_to_enum(handler, Handlers)
>> +
>> +
>> +if 'pthread_sigmask' in _globals:
>> +@_wraps(_signal.pthread_sigmask)
>> +def pthread_sigmask(how, mask):
>> +sigs_set = _signal.pthread_sigmask(how, mask)
>> +return set(_int_to_enum(x, Signals) for x in sigs_set)
>> +pthread_sigmask.__doc__ = _signal.pthread_sigmask.__doc__
>> +
>> +
>> +@_wraps(_signal.sigpending)
>> +def sigpending():
>> +sigs = _signal.sigpending()
>> +return set(_int_to_enum(x, Signals) for x in sigs)
>> +
>> +
>> +if 'sigwait' in _globals:
>> +@_wraps(_signal.sigwait)
>> +def sigwait(sigset):
>> +retsig = _signal.sigwait(sigset)
>> +return _int_to_enum(retsig, Signals)
>> +sigwait.__doc__ = _signal.sigwait
>> +
>> +del _globals, _wraps
>> diff --git a/Lib/test/test_doctest.py b/Lib/test/test_doctes

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Victor Stinner]

2014-04-04 16:21 GMT+02:00 Brett Cannon :
> Fix is in rev c6e63bb132fb.

Hum, this one was not enough for me. I also modified Modules/Setup.config.in:

changeset:   90137:df5120efb86e
tag: tip
user:Victor Stinner 
date:Fri Apr 04 16:30:04 2014 +0200
files:   Modules/Setup.config.in
description:
Issue #21076: the C signal module has been renamed to _signal


diff -r c6e63bb132fb -r df5120efb86e Modules/Setup.config.in
--- a/Modules/Setup.config.in   Fri Apr 04 10:20:28 2014 -0400
+++ b/Modules/Setup.config.in   Fri Apr 04 16:30:04 2014 +0200
@@ -7,7 +7,7 @@
 @USE_THREAD_MODULE@_thread _threadmodule.c

 # The signal module
-@USE_SIGNAL_MODULE@signal signalmodule.c
+@USE_SIGNAL_MODULE@_signal signalmodule.c

 # The rest of the modules previously listed in this file are built
 # by the setup.py script in Python 2.1 and later.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Brett Cannon]

On Fri Apr 04 2014 at 10:34:06 AM, Victor Stinner 
wrote:

> 2014-04-04 16:21 GMT+02:00 Brett Cannon :
> > Fix is in rev c6e63bb132fb.
>
> Hum, this one was not enough for me. I also modified Modules/
> Setup.config.in:
>

Wasn't for me either in the end as it failed when I did a distclean. The
unfortunately bit me in the middle of trying to get a 3.4->default merge so
I just tried to do the best I could. This might take a little while to
clean up as the Windows 7 buildbot now builds -- which it has been doing
for a while -- but claims it can't find _signal.sigpending which I can at
least see on OS X so that bit of code my need tweaking.

-Brett


>
> changeset:   90137:df5120efb86e
> tag: tip
> user:Victor Stinner 
> date:Fri Apr 04 16:30:04 2014 +0200
> files:   Modules/Setup.config.in
> description:
> Issue #21076: the C signal module has been renamed to _signal
>
>
> diff -r c6e63bb132fb -r df5120efb86e Modules/Setup.config.in
> --- a/Modules/Setup.config.in   Fri Apr 04 10:20:28 2014 -0400
> +++ b/Modules/Setup.config.in   Fri Apr 04 16:30:04 2014 +0200
> @@ -7,7 +7,7 @@
>  @USE_THREAD_MODULE@_thread _threadmodule.c
>
>  # The signal module
> -@USE_SIGNAL_MODULE@signal signalmodule.c
> +@USE_SIGNAL_MODULE@_signal signalmodule.c
>
>  # The rest of the modules previously listed in this file are built
>  # by the setup.py script in Python 2.1 and later.
>
> Victor
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Giampaolo Rodola']

Sorry for the troubles. :(
I committed this because it worked on my local copy of Python 3.5 but after
I tried a brand new "hg clone" it didnt.


On Fri, Apr 4, 2014 at 4:43 PM, Brett Cannon  wrote:

>
>
> On Fri Apr 04 2014 at 10:34:06 AM, Victor Stinner <
> victor.stin...@gmail.com> wrote:
>
>> 2014-04-04 16:21 GMT+02:00 Brett Cannon :
>> > Fix is in rev c6e63bb132fb.
>>
>> Hum, this one was not enough for me. I also modified Modules/
>> Setup.config.in:
>>
>
> Wasn't for me either in the end as it failed when I did a distclean. The
> unfortunately bit me in the middle of trying to get a 3.4->default merge so
> I just tried to do the best I could. This might take a little while to
> clean up as the Windows 7 buildbot now builds -- which it has been doing
> for a while -- but claims it can't find _signal.sigpending which I can at
> least see on OS X so that bit of code my need tweaking.
>
> -Brett
>
>
>>
>> changeset:   90137:df5120efb86e
>> tag: tip
>> user:Victor Stinner 
>> date:Fri Apr 04 16:30:04 2014 +0200
>> files:   Modules/Setup.config.in
>> description:
>> Issue #21076: the C signal module has been renamed to _signal
>>
>>
>> diff -r c6e63bb132fb -r df5120efb86e Modules/Setup.config.in
>> --- a/Modules/Setup.config.in   Fri Apr 04 10:20:28 2014 -0400
>> +++ b/Modules/Setup.config.in   Fri Apr 04 16:30:04 2014 +0200
>> @@ -7,7 +7,7 @@
>>  @USE_THREAD_MODULE@_thread _threadmodule.c
>>
>>  # The signal module
>> -@USE_SIGNAL_MODULE@signal signalmodule.c
>> +@USE_SIGNAL_MODULE@_signal signalmodule.c
>>
>>  # The rest of the modules previously listed in this file are built
>>  # by the setup.py script in Python 2.1 and later.
>>
>> Victor
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>
>


-- 
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix #21076: turn signal module constants into enums

[Oleg Broytman]

On Fri, Apr 04, 2014 at 05:08:37PM +0200, Giampaolo Rodola' 
 wrote:
> Sorry for the troubles. :(
> I committed this because it worked on my local copy of Python 3.5 but after
> I tried a brand new "hg clone" it didnt.

   make distclean was not enough?

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] New absolute __file__ in Python 3.4

[anatoly techtonik]

https://docs.python.org/3.4/whatsnew/3.4.html#other-language-changes

1. Is this absolute name with symlinks resolved?
2. Why there is a special case for __main__?
(i.e. Special cases aren't special enough to break the rules.)
3. What link should I click in Python reference to read
about standard globals like __file__ and this change?
https://docs.python.org/3.4/library/index.html
something like this in PHP
http://www.php.net/manual/en/language.constants.predefined.php
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2014-03-28 - 2014-04-04)
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:
  open4550 (+16)
  closed 28376 (+52)
  total  32926 (+68)

Open issues with patches: 2093 


Issues opened (48)
==

#21087: imp.frozen_init() incorrectly removes module during reload
http://bugs.python.org/issue21087  opened by eric.snow

#21088: curses addch() argument position reverses in Python3.4.0
http://bugs.python.org/issue21088  opened by masamoto

#21090: File read silently stops after EIO I/O error
http://bugs.python.org/issue21090  opened by ivank

#21091: EmailMessage.is_attachment should be a method
http://bugs.python.org/issue21091  opened by brandon-rhodes

#21095: EmailMessage should support Header objects
http://bugs.python.org/issue21095  opened by brandon-rhodes

#21099: Switch applicable importlib tests to use PEP 451 API
http://bugs.python.org/issue21099  opened by eric.snow

#21101: Extend the PyDict C API to handle cases where the hash value i
http://bugs.python.org/issue21101  opened by rhettinger

#21103: Encoding str to IDNA with ellipsis decomposes to empty labels
http://bugs.python.org/issue21103  opened by chfoo

#21106: Updated Mac folder icon
http://bugs.python.org/issue21106  opened by viveksjain

#21107: Add pgen.vcxproj to allow regenerating grammar files on Window
http://bugs.python.org/issue21107  opened by zach.ware

#21108: Add examples for importlib in doc
http://bugs.python.org/issue21108  opened by sahutd

#21109: tarfile: Traversal attack vulnerability
http://bugs.python.org/issue21109  opened by Daniel.Garcia

#21110: Slowdown and high memory usage when adding a new module in emb
http://bugs.python.org/issue21110  opened by MrValdez

#2: PyLong_AsUnsignedLongAndOverflow does not exist
http://bugs.python.org/issue2  opened by h.venev

#21112: 3.4 regression: unittest.expectedFailure no longer works on Te
http://bugs.python.org/issue21112  opened by William.Schwartz

#21114: wsgiref.simple_server doesn't handle multi-line headers correc
http://bugs.python.org/issue21114  opened by Alan.Braithwaite

#21116: Failure to create multiprocessing shared arrays larger than 50
http://bugs.python.org/issue21116  opened by mboquien

#21117: inspect.signature: inaccuracies for partial functions
http://bugs.python.org/issue21117  opened by yselivanov

#21118: str.translate is absurdly slow in majority of use cases (takes
http://bugs.python.org/issue21118  opened by josh.rosenberg

#21119: asyncio create_connection resource warning
http://bugs.python.org/issue21119  opened by landersson

#21120: PyArena type is used in headers from the limited API
http://bugs.python.org/issue21120  opened by aponomarenko

#21121: -Werror=declaration-after-statement is added even for extensio
http://bugs.python.org/issue21121  opened by nilsge

#21122: CPython fails to build modules with LLVM LTO on Mac OS X
http://bugs.python.org/issue21122  opened by Sjlver

#21124: _struct module compilation error under Cygwin 1.7.17 on Python
http://bugs.python.org/issue21124  opened by dellair.jie

#21126: Integrate doctest.run_docstring_examples() with unittest
http://bugs.python.org/issue21126  opened by giampaolo.rodola

#21127: Path objects cannot be constructed from str subclasses
http://bugs.python.org/issue21127  opened by Antony.Lee

#21128: testing stdlib and compatibility with pypy
http://bugs.python.org/issue21128  opened by mattip

#21130: equivalent functools.partial instances should compare equal
http://bugs.python.org/issue21130  opened by theller

#21131: test_faulthandler.test_register_chain fails on 64bit ppc/arm w
http://bugs.python.org/issue21131  opened by bkabrda

#21132: Failure to import win32api
http://bugs.python.org/issue21132  opened by woakesd

#21133: unittest discover should allow option to run each package sepa
http://bugs.python.org/issue21133  opened by the.mulhern

#21134: Segfault when stringifying UnicodeEncodeError (or UnicodeDecod
http://bugs.python.org/issue21134  opened by Marek.Kowalski

#21136: fractions.Fraction.__pow__ does unneeded renormalization
http://bugs.python.org/issue21136  opened by Orborde

#21137: Better repr for threading.Lock()
http://bugs.python.org/issue21137  opened by rhettinger

#21138: mimetypes.MimeType UnicodeDecodeError
http://bugs.python.org/issue21138  opened by tanbro

#21139: Idle: change default reformat width from 70 to 72
http://bugs.python.org/issue21139  opened by terry.reedy

#21140: Idle: saving an OutputWindow should default to .txt
http://bugs.python.org/issue21140  opened by terry.reedy

#21141: Don't mention Perl in Windows build output
http://bugs.python.org/issue21141  opened by zach.ware

#21142: Daily/weekly ABI scan?
http://bugs.python.org/issue21142  opened by ncoghlan

#21144: ensurepip "AssertionError: Multiple .dist-info directories"
http://bugs.python.org/issue21144  opened

Re: [Python-Dev] New absolute __file__ in Python 3.4

[Terry Reedy]

On 4/4/2014 11:21 AM, anatoly techtonik wrote:

https://docs.python.org/3.4/whatsnew/3.4.html#other-language-changes

1. Is this absolute name with symlinks resolved?
2. Why there is a special case for __main__?
(i.e. Special cases aren't special enough to break the rules.)


Did you read the linked issue?
http://bugs.python.org/issue18416


3. What link should I click in Python reference to read
 about standard globals like __file__ and this change?
 https://docs.python.org/3.4/library/index.html


I don't know how you got that link. Learn to use the general index 
listed on the contents page and top right of every page. For underscore 
names, https://docs.python.org/3/genindex-_.html. __file__ will lead you 
to the module entry in Chapter 3 Data model, section 2 The standard type 
hierarchy. Looking up module/namespace gets you to the same place. It is 
possible that the discussion of '__file__' should be slightly revised in 
light of the What's new entry.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pyston: a Python JIT on LLVM

[Kevin Modzelewski]

Using optional type annotations is a really promising strategy and may
eventually be added to Pyston, but our primary target right now is
unmodified and untyped Python code.  I think there's room for both
approaches -- I think the "using type annotations to achieve near-native
performance" can be very useful ex. in a numerical computing context, but
might not apply as well to a "large web application" case.

On Thu, Apr 3, 2014 at 3:42 PM, Sturla Molden wrote:

> Kevin Modzelewski  wrote:
>
> > Since it's the question that I think most people will inevitably (and
> > rightly) ask, why do we think there's a place for Pyston when there's
> PyPy
> > and (previously) Unladen Swallow?
>
> Have you seen Numba, the Python JIT that integrates with NumPy?
>
> http://numba.pydata.org
>
> It uses LLVM to compile Python bytecode. When I have tried it I tend to get
> speed comparable to -O2 in C for numerical and algorithmic code.
>
> Here is an example, giving a 150 times speed boost to Python:
>
>
> http://stackoverflow.com/questions/21811381/how-to-shove-this-loop-into-numpy/21818591#21818591
>
>
> Sturla
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/kmod%40dropbox.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pyston: a Python JIT on LLVM

[Kevin Modzelewski]

On Fri, Apr 4, 2014 at 1:59 AM, Antoine Pitrou  wrote:

>
> I'm a bit surprised by the approach. Why don't you simply process CPython
> bytecode, rather than strive to reimplement Python fully?
>

The original choice to operate on Python AST rather than bytecode was made
somewhat arbitrarily, but I think I still support that decision since it
avoids having to do a potentially performance-degrading translation between
a stack language and a register language.  It means we lose the ability to
execute pyc-only distributions, but I suppose that support for that could
be added if it becomes important.

As for why we're building our own runtime as part of all of this (which I
think is what you're getting at), I think that a lot of the performance of
an implementation is caught up in the runtime and isn't just about the AST-
or bytecode- execution.  There are a couple systems out there that will
compile Python to C modules, where all the behavior is implemented using
calls back through the C API.  I haven't tried them, but I'd suspect that
without type information, the gains from doing this aren't that great,
since while you can get rid of bytecode dispatch and perhaps get a better
view of control flow, it doesn't address anything about the dynamic nature
of Python.  For example, in Pyston the fast path for an instance attribute
lookup (with no __getattribute__) will be just two loads: one to lookup the
attribute array and one to load the appropriate offset.  I'd say that it's
necessary to have a different runtime to support that, because it has to be
cooperative and 1) use a different object representation everywhere and 2)
know how to backpatch attribute-lookups to fully take advantage of it.
 That said, we definitely try to not reimplement something if we don't need
to.


> Also, I wonder if it's worthwhile to use a conservative GC, rather than
> reuse the original refcounting scheme (especially since you want to support
> existing extension modules).


I wonder that too :)  The only way to know for sure will be to get it
working on real code, but I feel comfortable with the approach since I
trust that everyone else using GCs are happy and for a reason, and I think
it's possible any GC-related advantages can mask the related
extension-compatibility cost.

I was pretty happy when we switched from refcounting to a tracing GC; the
refcounting was already somewhat optimized (didn't emit any
obviously-duplicate increfs/decrefs), but removing the refcounting
operations opened up a number of other optimizations.  As a simple example,
when refcounting you can't typically do tail call elimination because you
have to do some decrefs() at the end of the function, and those decrefs
will also typically keep the variables live even if they didn't otherwise
need to be.  It was also very hard to tell that certain operations were
no-ops, since even if something is a no-op at the Python level, it can
still do a bunch of refcounting.  You can (and we almost did) write an
optimizer to try to match up all the incref's and decref's, but then you
have to start proving that certain variables remain the same after a
function call, etc  I'm sure it's possible, but using a GC instead made
all of these optimizations much more natural.



Pyston is definitely far on one side of the effort-vs-potential-payoff
spectrum, and it's certainly fair to say that there are other approaches
that would be less work to implement.  I think that with the wealth of very
impressive existing options, though, it makes sense to take the risky path
and to shoot very high, and I'm fortunate to be in a situation where we can
make a risky bet like that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com