Re: [Python-Dev] a new type for sys.implementation
On Thu, May 31, 2012 at 6:56 PM, Benjamin Peterson wrote: > 2012/5/31 Nick Coghlan : > > On Thu, May 31, 2012 at 8:26 PM, Mark Shannon wrote: > >> Eric Snow wrote: > >>> > >>> The implementation for sys.implementation is going to use a new (but > >>> "private") type[1]. It's basically equivalent to the following: > >> > >> > >> Does this really need to be written in C rather than Python? > > > > Yes, because we want to use it in the sys module. As you get lower > > down in the interpreter stack, implementing things in Python actually > > starts getting painful because of bootstrapping issues (e.g. that's > > why both _structseq and collections.namedtuple exist). > > sys.implementation could be added by site or some other startup file. > > Yes, why not do that instead of a new thing in C? I don't care about PyPy actually (since we kind of have to implement sys.implementation in python/RPython anyway, since it'll be different) but more that more code in C means more trouble usually. Another question (might be out of topic here). What we do in PyPy to avoid bootstrapping issues (since we have quite a bit implemented in Python, rather than RPython) is to "freeze" the bytecode at compile time (or make time) and put it in the executable. This avoids all sort of filesystem access issues, but might be slightly too complicated. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Fri, Jun 1, 2012 at 7:16 PM, Maciej Fijalkowski wrote: >> sys.implementation could be added by site or some other startup file. >> > > Yes, why not do that instead of a new thing in C? I don't care about PyPy > actually (since we kind of have to implement sys.implementation in > python/RPython anyway, since it'll be different) The idea is that sys.implementation is the way some interpreter internal details are exposed to the Python layer, thus it needs to handled in the implementation language, and explicitly *not* in Python (if it's in Python, then the implementation has to come up with some *other* API for accessing those internals from Python code, thus missing a large part of the point of the exercise). > Another question (might be out of topic here). What we do in PyPy to avoid > bootstrapping issues (since we have quite a bit implemented in Python, > rather than RPython) is to "freeze" the bytecode at compile time (or make > time) and put it in the executable. This avoids all sort of filesystem > access issues, but might be slightly too complicated. Yeah, we're already doing that for importlib._bootstrap. It's a PITA (especially when changing the compiler), and certainly not easier than just writing some C code for a component that's explicitly defined as being implementation specific. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
Nick Coghlan wrote: On Fri, Jun 1, 2012 at 7:16 PM, Maciej Fijalkowski wrote: sys.implementation could be added by site or some other startup file. Yes, why not do that instead of a new thing in C? I don't care about PyPy actually (since we kind of have to implement sys.implementation in python/RPython anyway, since it'll be different) The idea is that sys.implementation is the way some interpreter internal details are exposed to the Python layer, thus it needs to handled in the implementation language, and explicitly *not* in Python (if it's in Python, then the implementation has to come up with some *other* API for accessing those internals from Python code, thus missing a large part of the point of the exercise). Why? What is wrong with something like the following (for CPython)? class SysImplemention: "Define __repr__(), etc here " ... sys.implementation = SysImplemention() sys.implementation.name = 'cpython' sys.implementation.version = (3, 3, 0, 'alpha', 4) sys.implementation.hexversion = 0x30300a4 sys.implementation.cache_tag = 'cpython-33' Also, should the build/machine info be removed from sys.version and moved it to sys.implementation? Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Fri, Jun 1, 2012 at 9:49 PM, Mark Shannon wrote: > What is wrong with something like the following (for CPython)? > > class SysImplemention: > "Define __repr__(), etc here " > ... > > sys.implementation = SysImplemention() > sys.implementation.name = 'cpython' > sys.implementation.version = (3, 3, 0, 'alpha', 4) > sys.implementation.hexversion = 0x30300a4 > sys.implementation.cache_tag = 'cpython-33' Because now you're double keying data in a completely unnecessary fashion. The sys module initialisation code already has access to the info needed to fill out sys.implementation correctly, moving that code somewhere else purely for the sake of getting to write it in Python instead of C would be foolish. Some things are best written in Python, some make sense to write in the underlying implementation language. This is one of the latter because it's all about implementation details. > Also, should the build/machine info be removed from sys.version > and moved it to sys.implementation? No, as the contents of sys.version are already defined as implementation dependent. It remains as the easy to print version, while sys.implementation provides a programmatic interface. There may be other CPython-specific fields currently in sys.version that it makes sense to also include in sys.implementation, but: 1. That's *as well as*, not *instead of* 2. It's something that can be looked at *after* the initial implementation of the PEP has been checked in (and should only be done with a concrete use case, such as eliminating sys.version introspection in other parts of the stdlib or in third party code) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
Nick Coghlan wrote:
On Fri, Jun 1, 2012 at 9:49 PM, Mark Shannon wrote:
What is wrong with something like the following (for CPython)?
class SysImplemention:
"Define __repr__(), etc here "
...
sys.implementation = SysImplemention()
sys.implementation.name = 'cpython'
sys.implementation.version = (3, 3, 0, 'alpha', 4)
sys.implementation.hexversion = 0x30300a4
sys.implementation.cache_tag = 'cpython-33'
Because now you're double keying data in a completely unnecessary
fashion. The sys module initialisation code already has access to the
info needed to fill out sys.implementation correctly, moving that code
somewhere else purely for the sake of getting to write it in Python
instead of C would be foolish. Some things are best written in Python,
some make sense to write in the underlying implementation language.
This is one of the latter because it's all about implementation
details.
Previously you said that "it needs to handled in the implementation
language, and explicitly *not* in Python".
I asked why that was.
Now you seem to be suggesting that Python code would break the DRY rule,
but the C code would not. If the C code can avoid duplication, then so
can the Python code, as follows:
class SysImplementation:
"Define __repr__(), etc here "
...
import imp
tag = imp.get_tag()
sys.implementation = SysImplementation()
sys.implementation.name = tag[:tag.index('-')]
sys.implementation.version = sys.version_info
sys.implementation.hexversion = sys.hexversion
sys.implementation.cache_tag = tag
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 11 change: Windows Support Lifecycle
I have just codified our current policy on supporting Windows releases, namely that we only support some Windows version until Microsoft ends its extended support period. As a consequence, Windows XP will be supported until 08/04/2014, and Windows 7 until 14/01/2020 (unless Microsoft extends that date further). I have also added wording on Visual Studio support which may still require consensus. My proposed policy is this: 1. There is only one VS version supported for any feature release. Because of the different branches, multiple versions may be in use. 2. The version that we use for a new feature release must still have mainstream support (meaning it can still be purchased regularly). 3. We should strive to keep the number of VS versions used simultaneously small. VS 2008 has mainstream support until 09/04/2013, so we could have used it for 3.3 still, however, mainstream support ends within the likely lifetime of 3.3, so switching to VS 2010 was better. VS 2010 will have mainstream support until 14/07/2015, so we can likely use it for 3.4 as well, and only reconsider for 3.5 (at which point XP support will not be an issue anymore). VS 2012 is out for 3.4 as it doesn't support XP. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon wrote:
> import imp
> tag = imp.get_tag()
>
> sys.implementation = SysImplementation()
> sys.implementation.name = tag[:tag.index('-')]
> sys.implementation.version = sys.version_info
> sys.implementation.hexversion = sys.hexversion
This is wrong. sys.version_info is the language version, while
sys.implementation.version is the implementation version. They happen
to be the same for CPython because it's the reference interpreter, but
splitting the definition like this allows (for example) a 0.1 release
of a new implementation to target Python 3.3 and clearly indicate the
difference between the two version numbers.
As the PEP's rationale section says: "The status quo for
implementation-specific information gives us that information in a
more fragile, harder to maintain way. It is spread out over different
modules or inferred from other information, as we see with
platform.python_implementation().
This PEP is the main alternative to that approach. It consolidates the
implementation-specific information into a single namespace and makes
explicit that which was implicit."
The idea of the PEP is provide a standard channel from the
implementation specific parts of the interpreter (i.e. written in the
implementation language) through to the implementation independent
code in the standard library (i.e. written in Python). It's intended
to *replace* the legacy APIs in the long run, not rely on them.
While we're unlikely to bother actually deprecating legacy APIs like
imp.get_tag() (as it isn't worth the hassle), PEP 421 means we can at
least avoid *adding* to them. To achieve the aims of the PEP without
double-keying data it *has* to be written in C.
The long term goal here is that all the code in the standard library
should be implementation independent - PyPy, Jython, IronPython, et al
should be able to grab it and just run it. That means the
implementation specific stuff needs to migrate into the C code and get
exposed through standard APIs. PEP 421 is one step along that road.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 11 change: Windows Support Lifecycle
On Fri, Jun 1, 2012 at 8:22 AM, wrote: > I have just codified our current policy on supporting > Windows releases, namely that we only support some Windows > version until Microsoft ends its extended support period. > As a consequence, Windows XP will be supported until > 08/04/2014, and Windows 7 until 14/01/2020 (unless Microsoft > extends that date further). > > I have also added wording on Visual Studio support which may > still require consensus. My proposed policy is this: > > 1. There is only one VS version supported for any feature release. > Because of the different branches, multiple versions may be > in use. > 2. The version that we use for a new feature release must still > have mainstream support (meaning it can still be purchased > regularly). > 3. We should strive to keep the number of VS versions used > simultaneously small. > > VS 2008 has mainstream support until 09/04/2013, so we could have > used it for 3.3 still, however, mainstream support ends within the > likely lifetime of 3.3, so switching to VS 2010 was better. VS 2010 > will have mainstream support until 14/07/2015, so we can likely > use it for 3.4 as well, and only reconsider for 3.5 (at which point XP > support will not be an issue anymore). VS 2012 is out for 3.4 as it > doesn't support XP. This all sounds good to me. I think the rough timeline of our future releases lines up nicely, e.g., the VS version available around Python 3.5 won't support XP and neither would we. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Jun 01, 2012, at 11:49 PM, Nick Coghlan wrote: >The long term goal here is that all the code in the standard library >should be implementation independent - PyPy, Jython, IronPython, et al >should be able to grab it and just run it. That means the >implementation specific stuff needs to migrate into the C code and get >exposed through standard APIs. PEP 421 is one step along that road. Exactly. Or to put it another way, if you implemented sys.implementation in some stdlib Python module, you wouldn't be able to share that module between the various Python implementations. I think the stdlib should strive for *more* commonality across Python implementations, not less. Yes, you could conditionalize your way around that, but why do it when writing the code in the interpreter implementation language is easy enough? Plus, who wants to maintain the ugly mass of if-statements that would probably require? Eric's C code is easily auditable to anyone who knows the C API well enough, and I can't imagine it wouldn't be pretty trivial to write it in Java, RPython, or C#. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
Nick Coghlan wrote:
On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon wrote:
import imp
tag = imp.get_tag()
sys.implementation = SysImplementation()
sys.implementation.name = tag[:tag.index('-')]
sys.implementation.version = sys.version_info
sys.implementation.hexversion = sys.hexversion
This is wrong. sys.version_info is the language version, while
sys.implementation.version is the implementation version. They happen
to be the same for CPython because it's the reference interpreter, but
I thought this list was for CPython, not other implementations ;)
splitting the definition like this allows (for example) a 0.1 release
of a new implementation to target Python 3.3 and clearly indicate the
difference between the two version numbers.
As the PEP's rationale section says: "The status quo for
implementation-specific information gives us that information in a
more fragile, harder to maintain way. It is spread out over different
modules or inferred from other information, as we see with
platform.python_implementation().
This PEP is the main alternative to that approach. It consolidates the
implementation-specific information into a single namespace and makes
explicit that which was implicit."
The idea of the PEP is provide a standard channel from the
implementation specific parts of the interpreter (i.e. written in the
implementation language) through to the implementation independent
code in the standard library (i.e. written in Python). It's intended
to *replace* the legacy APIs in the long run, not rely on them.
I'm not arguing with the PEP, just discussing how to implement it.
While we're unlikely to bother actually deprecating legacy APIs like
imp.get_tag() (as it isn't worth the hassle), PEP 421 means we can at
least avoid *adding* to them. To achieve the aims of the PEP without
double-keying data it *has* to be written in C.
Could you justify that last sentence. What is special about C that means
that information does not have to be duplicated, yet it must be in Python?
I've already provided two implementations. The second derives all the
information it needs from other sources, thus conforming to DRY.
If the use of imp bothers you, then would this be OK:
I just picked imp.get_tag() because it has the relevant info. Would:
sys.implementation.cache_tag = (sys.implementation.name + '-' +
str(sys.version_info[0]) + str(str(sys.version_info[1]))
be acceptable?
The long term goal here is that all the code in the standard library
should be implementation independent - PyPy, Jython, IronPython, et al
should be able to grab it and just run it. That means the
implementation specific stuff needs to migrate into the C code and get
exposed through standard APIs. PEP 421 is one step along that road.
I don't see how that is relevant. sys.implementation can never be part
of the shared stdlib. That does not mean it has to be implemented in C.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
You have the burden of proof the wrong way around. sys is a builtin module.
C is the default language, absent a compelling reason to use Python
instead. The code is simple enough that there is no such reason, thus the
implementation will be in C.
--
Sent from my phone, thus the relative brevity :)
On Jun 2, 2012 12:30 AM, "Mark Shannon" wrote:
> Nick Coghlan wrote:
>
>> On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon wrote:
>>
>>> import imp
>>> tag = imp.get_tag()
>>>
>>> sys.implementation = SysImplementation()
>>> sys.implementation.name = tag[:tag.index('-')]
>>> sys.implementation.version = sys.version_info
>>> sys.implementation.hexversion = sys.hexversion
>>>
>>
>> This is wrong. sys.version_info is the language version, while
>> sys.implementation.version is the implementation version. They happen
>> to be the same for CPython because it's the reference interpreter, but
>>
>
> I thought this list was for CPython, not other implementations ;)
>
> splitting the definition like this allows (for example) a 0.1 release
>> of a new implementation to target Python 3.3 and clearly indicate the
>> difference between the two version numbers.
>>
>> As the PEP's rationale section says: "The status quo for
>> implementation-specific information gives us that information in a
>> more fragile, harder to maintain way. It is spread out over different
>> modules or inferred from other information, as we see with
>> platform.python_**implementation().
>>
>> This PEP is the main alternative to that approach. It consolidates the
>> implementation-specific information into a single namespace and makes
>> explicit that which was implicit."
>>
>> The idea of the PEP is provide a standard channel from the
>> implementation specific parts of the interpreter (i.e. written in the
>> implementation language) through to the implementation independent
>> code in the standard library (i.e. written in Python). It's intended
>> to *replace* the legacy APIs in the long run, not rely on them.
>>
>
> I'm not arguing with the PEP, just discussing how to implement it.
>
>
>> While we're unlikely to bother actually deprecating legacy APIs like
>> imp.get_tag() (as it isn't worth the hassle), PEP 421 means we can at
>> least avoid *adding* to them. To achieve the aims of the PEP without
>> double-keying data it *has* to be written in C.
>>
>
> Could you justify that last sentence. What is special about C that means
> that information does not have to be duplicated, yet it must be in Python?
> I've already provided two implementations. The second derives all the
> information it needs from other sources, thus conforming to DRY.
> If the use of imp bothers you, then would this be OK:
>
> I just picked imp.get_tag() because it has the relevant info. Would:
>
> sys.implementation.cache_tag = (sys.implementation.name + '-' +
> str(sys.version_info[0]) + str(str(sys.version_info[1]))
>
> be acceptable?
>
>
>> The long term goal here is that all the code in the standard library
>> should be implementation independent - PyPy, Jython, IronPython, et al
>> should be able to grab it and just run it. That means the
>> implementation specific stuff needs to migrate into the C code and get
>> exposed through standard APIs. PEP 421 is one step along that road.
>>
>
> I don't see how that is relevant. sys.implementation can never be part of
> the shared stdlib. That does not mean it has to be implemented in C.
>
> Cheers,
> Mark
>
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Jun 01, 2012, at 03:22 PM, Mark Shannon wrote: >I thought this list was for CPython, not other implementations ;) This list serves a dual purpose. Its primary purpose is to discuss development of Python-the-language. It's also where discussions about CPython-the-implementation occur, but that's because CPython is the current reference implementation of the language. While python-dev is not the primary forum for discussing implementation details of alternative implementations, I hope that those are not off-limits for this list, and should be especially welcome for issues that pertain to Python-the-language. Remember too that PEPs drive language changes, PEPs (generally) apply to all implementations of the language, and python-dev is where PEPs get discussed. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-05-25 - 2012-06-01) 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: open3450 (+10) closed 23308 (+54) total 26758 (+64) Open issues with patches: 1448 Issues opened (44) == #11820: idle3 shell os.system swallows shell command output http://bugs.python.org/issue11820 reopened by ned.deily #12370: Use of super overwrites use of __class__ in class namespace http://bugs.python.org/issue12370 reopened by ncoghlan #12510: IDLE get_the_calltip mishandles raw strings http://bugs.python.org/issue12510 reopened by terry.reedy #12932: dircmp does not allow non-shallow comparisons http://bugs.python.org/issue12932 reopened by terry.reedy #14917: Make os.symlink on Win32 detect if target is directory http://bugs.python.org/issue14917 opened by larry #14918: Incorrect explanation of TypeError exception http://bugs.python.org/issue14918 opened by tsou #14919: what disables one from adding self to the "nosy" list http://bugs.python.org/issue14919 opened by tshepang #14922: mailbox.Maildir.get_message() may fail when Maildir dirname is http://bugs.python.org/issue14922 opened by poliveira #14923: Even faster UTF-8 decoding http://bugs.python.org/issue14923 opened by storchaka #14926: random.seed docstring needs edit of "*a *is" http://bugs.python.org/issue14926 opened by smichr #14927: add "Do not supply int argument" to random.shuffle docstring http://bugs.python.org/issue14927 opened by smichr #14928: Fix importlib bootstrapping issues http://bugs.python.org/issue14928 opened by pitrou #14929: IDLE crashes on *Edit / Find in files ...* command http://bugs.python.org/issue14929 opened by fgracia #14933: Misleading documentation about weakrefs http://bugs.python.org/issue14933 opened by pitrou #14934: generator objects can clear their weakrefs before being resurr http://bugs.python.org/issue14934 opened by pitrou #14935: PEP 384 Refactoring applied to _csv module http://bugs.python.org/issue14935 opened by Robin.Schreiber #14936: PEP 3121, 384 refactoring applied to curses_panel module http://bugs.python.org/issue14936 opened by Robin.Schreiber #14937: IDLE's deficiency in the completion of file names (Python 32, http://bugs.python.org/issue14937 opened by fgracia #14940: Usage documentation for pysetup http://bugs.python.org/issue14940 opened by ncoghlan #14944: Setup & Usage documentation for pydoc, idle & 2to3 http://bugs.python.org/issue14944 opened by ncoghlan #14945: Setup & Usage documentation for selected stdlib modules http://bugs.python.org/issue14945 opened by ncoghlan #14946: packagingâs pysetup script should be named differently than http://bugs.python.org/issue14946 opened by eric.araujo #14949: Documentation should state clearly the differences between "py http://bugs.python.org/issue14949 opened by alexis #14950: Make packaging.install API less confusing and more extensible http://bugs.python.org/issue14950 opened by alexis #14953: Reimplement subset of multiprocessing.sharedctypes using memor http://bugs.python.org/issue14953 opened by sbt #14954: weakref doc clarification http://bugs.python.org/issue14954 opened by stoneleaf #14955: hmac.secure_compare() is not time-independent for unicode stri http://bugs.python.org/issue14955 opened by Jon.Oberheide #14956: custom PYTHONPATH may break apps embedding Python http://bugs.python.org/issue14956 opened by jankratochvil #14957: Improve docs for str.splitlines http://bugs.python.org/issue14957 opened by ncoghlan #14959: ttk.Scrollbar in Notebook widget freezes http://bugs.python.org/issue14959 opened by davidjamesbeck #14963: Use an iterative implementation for contextlib.ExitStack.__exi http://bugs.python.org/issue14963 opened by ncoghlan #14964: distutils2.utils.resolve_name cleanup http://bugs.python.org/issue14964 opened by Ronny.Pfannschmidt #14965: super() and property inheritance behavior http://bugs.python.org/issue14965 opened by ç«.é» #14966: Fully document subprocess.CalledProcessError http://bugs.python.org/issue14966 opened by ncoghlan #14967: distutils2.utils.resolve_name cannot be implemented to give co http://bugs.python.org/issue14967 opened by Ronny.Pfannschmidt #14968: Section "Inplace Operators" of :mod:`operator` should be a sub http://bugs.python.org/issue14968 opened by larsmans #14971: (unittest) loadTestsFromName does not work on method with a de http://bugs.python.org/issue14971 opened by alex.75 #14973: restore python2 unicode literals in "ur" strings http://bugs.python.org/issue14973 opened by rurpy2 #14974: rename packaging.pypi to packaging.index http://bugs.python.org/issue14974 opened by alexis #14975: import unicodedata, DLL load failed on Python 2.7.3 http://bugs.python.org/issue14975 opened by yfdyh000 #14976: Queue.PriorityQueue() is not interrupt safe http://b
Re: [Python-Dev] a new type for sys.implementation
On Fri, Jun 1, 2012 at 6:07 AM, Nick Coghlan wrote: > There may be other CPython-specific fields currently in sys.version > that it makes sense to also include in sys.implementation, but: > 1. That's *as well as*, not *instead of* > 2. It's something that can be looked at *after* the initial > implementation of the PEP has been checked in (and should only be done > with a concrete use case, such as eliminating sys.version > introspection in other parts of the stdlib or in third party code) Precisely. The PEP addresses this point directly: http://www.python.org/dev/peps/pep-0421/#adding-new-required-attributes -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Fri, Jun 1, 2012 at 7:17 AM, Mark Shannon wrote:
> Previously you said that "it needs to handled in the implementation
> language, and explicitly *not* in Python".
> I asked why that was.
>
> Now you seem to be suggesting that Python code would break the DRY rule,
> but the C code would not. If the C code can avoid duplication, then so
> can the Python code, as follows:
>
> class SysImplementation:
>
> "Define __repr__(), etc here "
> ...
>
> import imp
> tag = imp.get_tag()
>
> sys.implementation = SysImplementation()
> sys.implementation.name = tag[:tag.index('-')]
> sys.implementation.version = sys.version_info
> sys.implementation.hexversion = sys.hexversion
> sys.implementation.cache_tag = tag
This was actually the big motivator for PEP 421. Once PEP 421 is
final, imp.get_tag() will get its value from sys.implementation,
rather than the other way around. The point is to pull the
implementation-specific values into one place (as much as is
reasonable).
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Thu, May 31, 2012 at 9:08 PM, Barry Warsaw wrote: > On Jun 01, 2012, at 11:49 PM, Nick Coghlan wrote: > >>The long term goal here is that all the code in the standard library >>should be implementation independent - PyPy, Jython, IronPython, et al >>should be able to grab it and just run it. That means the >>implementation specific stuff needs to migrate into the C code and get >>exposed through standard APIs. PEP 421 is one step along that road. > > Exactly. Or to put it another way, if you implemented sys.implementation in > some stdlib Python module, you wouldn't be able to share that module between > the various Python implementations. I think the stdlib should strive for > *more* commonality across Python implementations, not less. Yes, you could > conditionalize your way around that, but why do it when writing the code in > the interpreter implementation language is easy enough? Plus, who wants to > maintain the ugly mass of if-statements that would probably require? Not only that, but any new/experimental/etc. implementation would either have be blessed in that module by Python committers (a la the platform module*) or would have to use a fork of the standard library. * I don't mean to put down the platform module, with has and will continue to serve us well. Rather, just pointing out that a small part of it demonstrates a limitation in the stdlib relative to alternate implementations. > > Eric's C code is easily auditable to anyone who knows the C API well enough, > and I can't imagine it wouldn't be pretty trivial to write it in Java, > RPython, or C#. And I'm by no means a C veteran. :) -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] setprofile and settrace inconsistency
Hi, When setting a trace function with settrace, the trace function when called with a new scope can return another trace function or None, indicating the inner scope should not be traced. I used settrace for some time but calling the trace function for every line of code is a performance killer. So I moved on to setprofile, which calls a trace function every function entry/exit. now here's the problem: the return value from the trace function is ignored (intentionally), denying the possibility to skip tracing of 'hot' or 'not interesting' code. I would like to propose two alternatives: 1. setprofile will not ignore the return value and mimic settrace's behavior. 2. setprofile is just a wrapper around settrace that limits it's functionality, lets make settrace more flexible so setprofile will be redundant. here's how: settrace will recieve an argument called 'events', the trace function will fire only on events contained in that list. for example: setprofile = partial(settrace, events=['call', 'return']) I personally prefer the second. Some context to this issue: I'm building a python tracer - a logger that records each and every function call. In order for it to run in production systems, the overhead should be minimal. I would like to allow the user to say which function/module/classes to trace or skip, for example: the user will skip all math/cpu intensive operations. another example: the user will want to trace his django app code but not the django framework. your thoughts? Thanks, Alon Horev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] what is happening with the regex module going into Python 3.3?
About the only thing I can think of from the language summit that we discussed doing for Python 3.3 that has not come about is accepting the regex module and getting it into the stdlib. Is this still being worked towards? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] setprofile and settrace inconsistency
Hi, When setting a trace function with settrace, the trace function when called with a new scope can return another trace function or None, indicating the inner scope should not be traced. I used settrace for some time but calling the trace function for every line of code is a performance killer. So I moved on to setprofile, which calls a trace function every function entry/exit. now here's the problem: the return value from the trace function is ignored (intentionally), denying the possibility to skip tracing of 'hot' or 'not interesting' code. I would like to propose two alternatives: 1. setprofile will not ignore the return value and mimic settrace's behavior. 2. setprofile is just a wrapper around settrace that limits it's functionality, lets make settrace more flexible so setprofile will be redundant. here's how: settrace will recieve an argument called 'events', the trace function will fire only on events contained in that list. for example: setprofile = partial(settrace, events=['call', 'return']) I personally prefer the second. Some context to this issue: I'm building a python tracer - a logger that records each and every function call. In order for it to run in production systems, the overhead should be minimal. I would like to allow the user to say which function/module/classes to trace or skip, for example: the user will skip all math/cpu intensive operations. another example: the user will want to trace his django app code but not the django framework. your thoughts? Thanks, Alon Horev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] whither PEP 407 and 413 (release cycle PEPs)?
Are these dead in the water or are we going to try to change our release cycle? I'm just asking since 3.3 final is due out in about 3 months and deciding on this along with shifting things if we do make a change could end up taking that long and I suspect if we don't do this for 3.3 we are probably never going to do it for Python 3 series as a whole. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setprofile and settrace inconsistency
On 6/1/2012 11:22 AM, Alon Horev wrote: your thoughts? Your post on python-ideas is the right place for this and discussion should be concentrated there. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
On 6/1/2012 1:27 PM, Brett Cannon wrote: About the only thing I can think of from the language summit that we discussed doing for Python 3.3 that has not come about is accepting the regex module and getting it into the stdlib. Is this still being worked towards? Since there is no PEP to define the details* of such an addition, I assume that no particular core developer focused on this. There have been a lot of other additions to take people's attention. Also, I do not remember seeing anything from Mathew Barnett about his views on the proposal. * Some details: Replacement of or addition to re. Relation to continued external project and 'ownership' of code. Relation, if any, to the Unicode Regular Expression Technical Standard, and its levels of conformance. http://unicode.org/reports/tr18/ The addition of ipaddress was not a drop-in process. There have been some docstrings changes and clarifications, some code changes and cleanups, and removal of stuff only needed for 2.x. I suspect that regex would get at least as much tuning once seriously looked at. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
On Fri, Jun 1, 2012 at 1:57 PM, Terry Reedy wrote: > On 6/1/2012 1:27 PM, Brett Cannon wrote: >> >> About the only thing I can think of from the language summit that we >> discussed doing for Python 3.3 that has not come about is accepting the >> regex module and getting it into the stdlib. Is this still being worked >> towards? > > > Since there is no PEP to define the details* of such an addition, I assume > that no particular core developer focused on this. There have been a lot of > other additions to take people's attention. Also, I do not remember seeing > anything from Mathew Barnett about his views on the proposal. > > * Some details: > > Replacement of or addition to re. At the language summit it was proposed that this regex project would enter as re, and the current re moves to sre. Everyone seemed to agree. > Relation to continued external project and 'ownership' of code. As with anything else, no more external. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit, Florence, July 2012
On 05/30/2012 05:06 AM, Larry Hastings wrote: Like Python? Like Italy? Like meetings? Then I've got a treat for you! I'll be chairing a Python Language Summit this July in historic Florence, Italy. It'll be on July 1st (the day before EuroPython starts) at the Grand Hotel Mediterraneo conference center. I have an update and a clarification. First, the clarification: the Language Summit is really intended for core developers. If you're not a core developer, then the meeting isn't for you. (Don't worry, you're not missing anything. It's about as interesting as doing your taxes.) Second, an update: enough people said it was too early for them to attend that we've rescheduled. It's now Saturday July 7th, the first day of the sprints. As before, please email me if you can attend (and you're a core developer!) so I can get a rough headcount. Ciao, //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whither PEP 407 and 413 (release cycle PEPs)?
My preference is that we plan and prepare during the 3.4 cycle, with a view to making a change for 3.5. I'd also like the first 3.4 alpha to be released in parallel with 3.3.1 Both PEPs should be updated with concrete transition and communication plans before any other action can seriously be considered. We have the potential to seriously upset a *lot* of people if we handle such a change badly (particularly when so many are still annoyed about Python 3). Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
ipaddress really made it in because I personally ran into the limitations of not having IP address support in the stdlib. I ended up doing quite a bit of prompting to ensure the process of cleaning up the API to modern stdlib standards didn't stall (even now, generating a module reference from the docstrings is still a pending task) With regex, the pain isn't there, since re already covers such a large subset of what regex provides. My perspective is that it's now too late to make a change that big for 3.3, but the in principle approval holds for anyone that wants to work with MRAB and get the idea written up as a PEP for 3.4. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
On 01/06/2012 18:27, Brett Cannon wrote: About the only thing I can think of from the language summit that we discussed doing for Python 3.3 that has not come about is accepting the regex module and getting it into the stdlib. Is this still being worked towards? Umpteen versions of regex have been available on pypi for years. Umpteen bugs against the original re module have been fixed. If regex can't now go into the standard library, what on earth can? -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
On Fri, Jun 1, 2012 at 7:37 PM, Mark Lawrence wrote: > Umpteen versions of regex have been available on pypi for years. Umpteen > bugs against the original re module have been fixed. If regex can't now go > into the standard library, what on earth can? Reviewing a 4000 line patch is probably the main roadblock here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #14957: clarify splitlines docs.
On Jun 2, 2012 6:21 AM, "r.david.murray" wrote: > > http://hg.python.org/cpython/rev/24572015e24f > changeset: 77288:24572015e24f > branch: 3.2 > parent: 77285:bf6305bce3af > user:R David Murray > date:Fri Jun 01 16:19:36 2012 -0400 > summary: > #14957: clarify splitlines docs. > > Initial patch by Michael Driscoll, I added the example. > > files: > Doc/library/stdtypes.rst | 8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > > diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst > --- a/Doc/library/stdtypes.rst > +++ b/Doc/library/stdtypes.rst > @@ -1329,7 +1329,13 @@ > >Return a list of the lines in the string, breaking at line boundaries. Line >breaks are not included in the resulting list unless *keepends* is given and > - true. > + true. This method uses the universal newlines approach to splitting lines. > + Unlike :meth:`~str.split`, if the string ends with line boundary characters > + the returned list does ``not`` have an empty last element. > + > + For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns > + ``['ab c', '', 'de fg', 'kl']``, while the same call with ``splinelines(True)`` > + returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``. s/splinelines/splitlines/ Maybe also show what split() would do for that string? > > > .. method:: str.startswith(prefix[, start[, end]]) > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #14957: clarify splitlines docs.
On Sat, 02 Jun 2012 10:42:13 +1000, Nick Coghlan wrote: > > + For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns > > + ``['ab c', '', 'de fg', 'kl']``, while the same call with > ``splinelines(True)`` > > + returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``. > > s/splinelines/splitlines/ Oops. > Maybe also show what split() would do for that string? I'd rather not, since the split examples are just above it in the docs. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what is happening with the regex module going into Python 3.3?
On Sat, Jun 2, 2012 at 10:37 AM, Mark Lawrence wrote: > On 01/06/2012 18:27, Brett Cannon wrote: >> >> About the only thing I can think of from the language summit that we >> discussed doing for Python 3.3 that has not come about is accepting the >> regex module and getting it into the stdlib. Is this still being worked >> towards? >> > > Umpteen versions of regex have been available on pypi for years. Umpteen > bugs against the original re module have been fixed. If regex can't now go > into the standard library, what on earth can? That's why it's approved *in principle* already. However, it's not a simple matter of dropping something into the standard library and calling it done, especially an extension module as complex as regex. Even integrating a simple pure Python module like ipaddr took substantial effort: 1. The API had to be reviewed to see if it was suitable for someone that was *not* familiar with the problem domain, but was instead learning about it from the standard library documentation. This isn't a big concern for regex, since it is replacing the existing re module, but this is the main reason ipaddr became ipaddress before PEP 3144 was approved (The ipaddr API plays fast and loose with network terminology in a way that someone that already *knows* that terminology can easily grasp, but would have been incredibly confusing to someone that is discovering those terms for the first time). 2. The code had to actually be added to the standard library (not a big effort for PEP 3144 - saving ipaddress.py into Lib/ and test_ipaddress.py into Lib/test/ pretty much covered it) 3. Redundant 2.x cruft needed to be weeded out (ongoing) 4. The howto guide needed to be incorporated into the documentation (and rewritten to be more suitable for genuine beginners) 5. An API module reference still needs to be incorporated into the standard library reference The effort to integrate regex is going to be substantially higher, since it's a significantly more complicated module: 1. A new, non-trivial C extension needs to be incorporated into both the autotools and Windows build processes 2. Due to PEP 393, there's a major change to the string implementation in 3.3. Does regex still build against that? Even if it builds, it should probably be ported to the new API for performance reasons. 3. Does regex build cleanly on all platforms supported by CPython? If not, do we need to keep the existing re module around as a fallback mechanism? 4. How do we merge the test suites? Do we keep the existing test suite, add the regex test suite, then filter for duplication afterwards? 5. What, precisely, *are* the backwards incompatibilities between regex and re? Does the standard library trigger any of them? Does the test suite? 6. How will the PyPI backport be maintained in the future? The amount of backwards compatibility cruft in standard library code should be minimised, but that potentially makes backports more difficult. ipaddress is in the 3.3 standard library because Peter Moody cared enough about the concept to initially submit it for inclusion, and because I volunteered to drive the review and integration process forward and to be the final arbiter of what counted as "good enough" for inclusion. That hasn't happened yet for regex - either nobody has cared enough to write a PEP for it, or the bystander effect has kicked in and everyone that cares is assuming *someone else* will take up the burden of being the PEP champion. So that's the first step: someone needs to take http://bugs.python.org/issue2636 and turn it into a PEP (searching the python-dev and python-ideas archives for references to previous discussions of the topic would also be good, along with summarising the open Unicode related re bugs reported by Tom Christensen where the answer is currently "use regex from PyPI instead of the standard library's re module" [1]). [1] http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=tchrist&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): #14957: clarify splitlines docs.
On Sat, Jun 2, 2012 at 1:24 PM, R. David Murray wrote: >> Maybe also show what split() would do for that string? > > I'd rather not, since the split examples are just above it in > the docs. Fair point - one of the downsides of reviewing a diff out of context :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
