Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Nick Coghlan, 16.02.2013 08:49: > Yes, the PyPy team and scientific users of Python have a long history > of talking past each other (and abusing each other for the mutual lack > of understanding). However, that's no excuse for deliberately ignoring > the advantages JIT compilation can bring No-one's ignoring that. Philip already mentioned Numba, for example. The only question is whether this needs to happen outside of the existing ecosystem, or if we can't just embrace the 95-to-5 rule and use the right tools just for the performance critical bits of our code, without sacrificing what we achieved in the last 20 years. Stefan ___ 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 webpage promoting Compiler technology for CPython
On Sat, Feb 16, 2013 at 10:03 AM, Stefan Behnel wrote: > Nick Coghlan, 16.02.2013 08:49: >> Yes, the PyPy team and scientific users of Python have a long history >> of talking past each other (and abusing each other for the mutual lack >> of understanding). However, that's no excuse for deliberately ignoring >> the advantages JIT compilation can bring > > No-one's ignoring that. Philip already mentioned Numba, for example. The > only question is whether this needs to happen outside of the existing > ecosystem, or if we can't just embrace the 95-to-5 rule and use the right > tools just for the performance critical bits of our code, without > sacrificing what we achieved in the last 20 years. > > Stefan Hi Stefan. I'm sorry PyPy does not cater for your needs, by being not like CPython. This is a conscious decision that Armin made after the psyco experiment and this is the one you disagree with, but it also allows us to do cool stuff, whether you like it or not. I understand it might be frustrating and I understand you guys simply don't like us for that. I also understand that people would love to promote their own work, that's fine too. CPyext is hard not because PyPy is undebuggable, but because the problem to solve (be not like CPython, but look like CPython) is a hard one. Until we come up with an idea how to make it so most CPython C extensions work out of the box and don't need careful refcount fixes, the focus is indeed not that major. However, considering this, the discussion of a website listing random projects from useful to outright obscure does not belong to python-dev, please take it somewhere else. 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] PEP 427: wheel
On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote:
> #. Python scripts must appear in ``scripts`` and begin with exactly
>``b'#!python'`` in order to enjoy script wrapper generation and
>``#!python`` rewriting at install time. They may have any or no
>extension.
For compatibility with file encoding declarations, I believe this
needs to be relaxed to starting with '#!python' in the source file
encoding, rather than strictly b'#!python' (which will only be the
case for ASCII compatible encodings).
My rationale is that installers are going to need to read the source
file encoding for the scripts anyway, otherwise they may write the
shebang line back out with the wrong encoding, potentially leading to
decoding errors when attempting to run the script.
> #. ``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1
>or greater (PEP 314, PEP 345, PEP 426) format metadata.
I suggest removing the PEP references here and simply saying "is
Metadata version 1.1 or greater format metadata"
> #. ``Wheel-Version`` is the version number of the Wheel specification.
>``Generator`` is the name and optionally the version of the software
>that produced the archive. ``Root-Is-Purelib`` is true if the top
>level directory of the archive should be installed into purelib;
>otherwise the root should be installed into platlib. ``Tag`` is the
>wheel's expanded compatibility tags; in the example the filename would
>contain ``py2.py3-none-any``. ``Build`` is the build number and is
>omitted if there is no build number.
I suggest breaking these out into separate bullet points (they're a
bit hard to read as they stand)
Aside from those minor issues, the current version of the spec looks
fine to me - upload those fixes and I will accept it. If we later need
to define wheel 1.1 or 2.0 to handle additional situations, well,
that's why it's a versioned format :)
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] Point of building without threads?
Yury V. Zaytsev wrote: > On Mon, 2012-05-07 at 21:49 +0200, Antoine Pitrou wrote: > > > > I guess a long time ago, threading support in operating systems wasn't > > very widespread, but these days all our supported platforms have it. > > Is it still useful for production purposes to configure > > --without-threads? Do people use this option for something else than > > curiosity of mind? > > I hope that the intent behind asking this question was more of being > curious, rather then considering dropping --without-threads: > unfortunately, multithreading was, still is and probably will remain > troublesome on many supercomputing platforms. > > Often, once a new supercomputer is launched, as a developer you get a > half-baked C/C++ compiler with threading support broken to the point > when it's much easier to not use it altogether [*] rather than trying to > work around the compiler quirks. Out of curiosity: Do these incomplete compilers have any problem with either stdint.h or static inline functions in header files? Stefan Krah ___ 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] Submitting PEP 425 (compatibility tags)
On Sat, Feb 16, 2013 at 2:06 PM, Daniel Holth wrote:
> This is the improved compatibility tags PEP 425, specifying how part of the
> Wheel PEP 427 filenames work. Last time we discussed whether replacing .
> with _ was ugly but I concluded it was harmless.
>
> Submitted for your consideration,
>
> PEP: 425
> Title: Compatibility Tags for Built Distributions
> Version: $Revision$
> Last-Modified: 07-Aug-2012
> Author: Daniel Holth
> BDFL-Delegate: Nick Coghlan
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 27-Jul-2012
> Python-Version: 3.4
> Post-History: 8-Aug-2012, 18-Oct-2012, 15-Feb-2013
>
>
> Abstract
>
>
> This PEP specifies a tagging system to indicate with which versions of
> Python a built or binary distribution is compatible. A set of three
> tags indicate which Python implementation and language version, ABI,
> and platform a built distribution requires. The tags are terse because
> they will be included in filenames.
>
>
> PEP Editor's Note
> =
>
> While the naming scheme described in this PEP will not be supported directly
> in the standard library until Python 3.4 at the earliest, draft
> implementations may be made available in third party projects.
>
>
> Rationale
> =
>
> Today "python setup.py bdist" generates the same filename on PyPy
> and CPython, but an incompatible archive, making it inconvenient to
> share built distributions in the same folder or index. Instead, built
> distributions should have a file naming convention that includes enough
> information to decide whether or not a particular archive is compatible
> with a particular implementation.
>
> Previous efforts come from a time where CPython was the only important
> implementation and the ABI was the same as the Python language release.
> This specification improves upon the older schemes by including the Python
> implementation, language version, ABI, and platform as a set of tags.
>
> By comparing the tags it supports with the tags listed by the
> distribution, an installer can make an educated decision about whether
> to download a particular built distribution without having to read its
> full metadata.
>
> Overview
>
>
> The tag format is {python tag}-{abi tag}-{platform tag}
>
> python tag
> ‘py27’, ‘cp33’
> abi tag
> ‘cp32dmu’, ‘none’
> platform tag
> ‘linux_x86_64’, ‘any’
>
> For example, the tag py27-none-any indicates compatible with Python 2.7
> (any Python 2.7 implementation) with no abi requirement, on any platform.
>
> Use
> ===
>
> The `wheel` built package format includes these tags in its filenames,
> of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi
> tag}-{platform tag}.whl``. Other package formats may have their own
> conventions.
>
> Details
> ===
>
> Python Tag
> --
>
> The Python tag indicates the implementation and version required by
> a distribution. Major implementations have abbreviated codes, initially:
>
> * py: Generic Python (does not require implementation-specific features)
> * cp: CPython
> * ip: IronPython
> * pp: PyPy
> * jy: Jython
>
> Other Python implementations should use `sys.implementation.name`.
>
> The version is `py_version_nodot`. CPython gets away with no dot,
> but if one is needed the underscore `_` is used instead. PyPy should
> probably use its own versions here `pp18`, `pp19`.
>
> The version can be just the major version `2` or `3` `py2`, `py3` for
> many pure-Python distributions.
>
> Importantly, major-version-only tags like `py2` and `py3` are not
> shorthand for `py20` and `py30`. Instead, these tags mean the packager
> intentionally released a cross-version-compatible distribution.
>
> A single-source Python 2/3 compatible distribution can use the compound
> tag `py2.py3`. See `Compressed Tag Sets`, below.
>
> ABI Tag
> ---
>
> The ABI tag indicates which Python ABI is required by any included
> extension modules. For implementation-specific ABIs, the implementation
> is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be
> the CPython 3.3 ABI with debugging.
>
> The CPython stable ABI is `abi3` as in the shared library suffix.
>
> Implementations with a very unstable ABI may use the first 6 bytes (as
> 8 base64-encoded characters) of the SHA-256 hash of ther source code
> revision and compiler flags, etc, but will probably not have a great need
> to distribute binary distributions. Each implementation's community may
> decide how to best use the ABI tag.
>
> Platform Tag
>
>
> The platform tag is simply `distutils.util.get_platform()` with all
> hyphens `-` and periods `.` replaced with underscore `_`.
>
> * win32
> * linux_i386
> * linux_x86_64
>
> Use
> ===
>
> The tags are used by installers to decide which built distribution
> (if any) to download from a list of potential built distributions.
> The installer maintains a list of (pyver, abi, arch) tuples that it
> will support. If the built distribut
Re: [Python-Dev] PEP 427: wheel
On Sat, 16 Feb 2013 19:18:22 +1000 Nick Coghlan wrote: > On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote: > > #. Python scripts must appear in ``scripts`` and begin with exactly > >``b'#!python'`` in order to enjoy script wrapper generation and > >``#!python`` rewriting at install time. They may have any or no > >extension. > > For compatibility with file encoding declarations, I believe this > needs to be relaxed to starting with '#!python' in the source file > encoding, rather than strictly b'#!python' (which will only be the > case for ASCII compatible encodings). I may be wrong, but I am not aware that Python is able to read encoding declarations in a non-ASCII compatible encoding :-) Also, given the shebang line is for use by the OS, the appropriate encoding should be decided by the OS, not Python conventions. But I would surprised if a shebang-compatible used a non-ASCII encoding by default. Regards Antoine. ___ 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 427: wheel
On Sat, 16 Feb 2013 11:12:49 +0100 Antoine Pitrou wrote: > On Sat, 16 Feb 2013 19:18:22 +1000 > Nick Coghlan wrote: > > On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote: > > > #. Python scripts must appear in ``scripts`` and begin with exactly > > >``b'#!python'`` in order to enjoy script wrapper generation and > > >``#!python`` rewriting at install time. They may have any or no > > >extension. > > > > For compatibility with file encoding declarations, I believe this > > needs to be relaxed to starting with '#!python' in the source file > > encoding, rather than strictly b'#!python' (which will only be the > > case for ASCII compatible encodings). > > I may be wrong, but I am not aware that Python is able to read encoding > declarations in a non-ASCII compatible encoding :-) > > Also, given the shebang line is for use by the OS, the appropriate > encoding should be decided by the OS, not Python conventions. But I > would surprised if a shebang-compatible used a non-ASCII encoding by > default. I mean non-ASCII compatible. Regards Antoine. ___ 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 427: wheel
On Sat, Feb 16, 2013 at 8:12 PM, Antoine Pitrou wrote: > On Sat, 16 Feb 2013 19:18:22 +1000 > Nick Coghlan wrote: > I may be wrong, but I am not aware that Python is able to read encoding > declarations in a non-ASCII compatible encoding :-) > > Also, given the shebang line is for use by the OS, the appropriate > encoding should be decided by the OS, not Python conventions. But I > would surprised if a shebang-compatible used a non-ASCII encoding by > default. Oh, good point - which means the only comments are cosmetic ones, which I can fix while marking it accepted. 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 427: wheel
Nick Coghlan writes: > For compatibility with file encoding declarations, I believe this > needs to be relaxed to starting with '#!python' in the source file > encoding, rather than strictly b'#!python' (which will only be the > case for ASCII compatible encodings). In any PEP-263-compatible encoding it will be b'#!python'. Relaxing this is excessive generality for a new feature. I'm not sure what you mean by file encoding declarations if not PEP 263, which requires approximate[1] ASCII compatibility. PEP 3120 simply builds on PEP 263 by making UTF-8, rather than ISO 8859/1, the default encoding. > My rationale is that installers are going to need to read the source > file encoding for the scripts anyway, otherwise they may write the > shebang line back out with the wrong encoding, potentially leading to > decoding errors when attempting to run the script. Too bad if there's no PEP 263 declaration and the file is not in ASCII. I.e., the intersection of Python 2 and Python 3 default encodings. Footnotes: [1] Ie, Shift JIS and Big 5, or any encoding in which a pure ASCII string can be interpreted as a string in that encoding, are OK, but UTF-16 is not. ___ 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 427: wheel
Since Antoine and Stephen have pointed out my only non-cosmetic concern was an error on my part, I am accepting the PEP. I'll update the peps repo (including the cosmetic fixes) in a moment. Regards, 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 427: wheel
On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan wrote: > Since Antoine and Stephen have pointed out my only non-cosmetic > concern was an error on my part, I am accepting the PEP. I'll update > the peps repo (including the cosmetic fixes) in a moment. And done: http://hg.python.org/peps/rev/d272d7a97e0c Thank you to Daniel for his hard work on getting this through to completion. 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] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Stefan Behnel wrote: > > you'd just pass in this string: > > > >(arg1 : int, arg2 : float, arg3 : ExtType, *, arg4=None) -> ExtType2 I've mentioned this proposal in http://bugs.python.org/issue16612 , but it wasn't sufficient for the task. Stefan Krah ___ 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] Point of building without threads?
Yury V. Zaytsev, 08.01.2013 10:28: > Moreover, these days there is a clear trend towards OpenMP, so it has > become even harder to pressure the manufacturers to fix threads, because > they have 101 argument why you should port your code to OpenMP instead. I can't see OpenMP being an *alternative* to threads. You can happily acquire and release the GIL from OpenMP threads, for example. Stefan ___ 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 427: wheel
On Sat, 16 Feb 2013 21:27:28 +1000 Nick Coghlan wrote: > On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan wrote: > > Since Antoine and Stephen have pointed out my only non-cosmetic > > concern was an error on my part, I am accepting the PEP. I'll update > > the peps repo (including the cosmetic fixes) in a moment. > > And done: http://hg.python.org/peps/rev/d272d7a97e0c > > Thank you to Daniel for his hard work on getting this through to completion. Great! Here's hope for an improved Python 3.4 distutils experience:-) Regards Antoine. ___ 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] cpython: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.
Hello, On Sun, 17 Feb 2013 00:42:26 +0100 (CET) eric.snow wrote: > > +def test_pickle(self): > +ns = types.SimpleNamespace(breakfast="spam", lunch="spam") > + > +ns_pickled = pickle.dumps(ns) > +ns_roundtrip = pickle.loads(ns_pickled) > + > +self.assertEqual(ns, ns_roundtrip) > + I think you should test with all pickle protocols. Regards Antoine. ___ 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] cpython: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.
On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote: > I think you should test with all pickle protocols. I'll do that. -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] Cut/Copy/Paste items in IDLE right click context menu
On Sat, Nov 3, 2012 at 5:28 AM, Nick Coghlan wrote: > On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy wrote: >> [snip reasons] >> OK, I am convinced an info PEP would be a good idea. > > Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I > mainly want to ensure we clearly fence off "IDLE-the-application", > with (in effect) a 6 month release cycle synchronised across versions, > from the rest of the standard library. I have not seen much progress on this issue so I thought I would attempt to draft a PEP. This is my first PEP so go easy on me. Attached is a PEP titled "IDLE Enhancement Exception for All Branches", I am looking for feedback. Thanks. PEP: XXX Title: IDLE Enhancement Exception for All Branches Version: Last-Modified: Author: Todd Rovito BDFL-Delegate: Nick Coghlan Status: Draft Type: Informational Content-Type: text/x-rst Created: 16-Feb-2013 Python-Version: 2.7 Post-History: 16-Feb-2013 Abstract Generally only new features are applied to Python 3.4 but this PEP requests an exception for IDLE [1]_. IDLE is part of the standard library and has numerous outstanding issues [2]_. Since IDLE is often the first thing a new Python user sees it desperately needs to be brought up to date with modern GUI standards across the three major platforms Linux, Mac OS X, and Windows. Rationale = Python does have many advanced features yet Python is well known for being a easy computer language for beginners [3]_. A major Python philosophy is "batteries included" which is best demonstrated in Python's standard library with many modules that are not typically included with other programming languages [4]_. IDLE is a important "battery" in the Python toolbox because it allows a beginner to get started quickly without downloading and configuring a third party IDE. Additional patches to IDLE cannot break any existing program/library because IDLE is used by humans. Details === Python 2.7 does not accept bug fixes, this rule can be ignored for IDLE if the Python development team accepts this PEP [5]_. IDLE issues will be carefully tested on the three major platforms Linux, Mac OS X, and Windows before any commits are made.. References == .. [1] IDLE: Right Click Context Menu, Foord, Michael (http://bugs.python.org/issue1207589) .. [2] Meta-issue for "Invent with Python" IDLE feedback (http://bugs.python.org/issue13504) .. [3] Getting Started with Python (http://www.python.org/about/gettingstarted/) .. [4] Batteries Included (http://docs.python.org/2/tutorial/stdlib.html#batteries-included) .. [5] Python 2.7 Release Schedule (http://www.python.org/dev/peps/pep-0373/) Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: ___ 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] cpython: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.
On Sat, Feb 16, 2013 at 5:02 PM, Eric Snow wrote: > On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote: >> I think you should test with all pickle protocols. > > I'll do that. Out of curiousity, how critical is it to support protocols 0 and 1? I've made sure SimpleNamespace does, but it made me wonder what the use case is for the older protocols. -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] Cut/Copy/Paste items in IDLE right click context menu
On Sun, Feb 17, 2013 at 10:45 AM, Todd Rovito wrote: > On Sat, Nov 3, 2012 at 5:28 AM, Nick Coghlan wrote: >> On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy wrote: >>> [snip reasons] >>> OK, I am convinced an info PEP would be a good idea. >> >> Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I >> mainly want to ensure we clearly fence off "IDLE-the-application", >> with (in effect) a 6 month release cycle synchronised across versions, >> from the rest of the standard library. > I have not seen much progress on this issue so I thought I would > attempt to draft a PEP. This is my first PEP so go easy on me. > > Attached is a PEP titled "IDLE Enhancement Exception for All > Branches", I am looking for feedback. Thanks. That's a good start - please forward it to the PEP editors list (p...@python.org) to be posted. The rationale needs to be fleshed out a bit more along the lines of "IDLE is primarily used as an application that ships with Python, rather than as a library module used to build Python applications, that's why it is OK for a different standard to apply". Mentioning the point about Linux distros splitting it out into a separate package would also be useful. NY other two major comments: - be specific about which parts of the code base are covered by the exception - no need for extensive cross-OS testing prior to commit, that's a key part of the role of the buildbots Regards, 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] Cut/Copy/Paste items in IDLE right click context menu
Nick Coghlan: > - no need for extensive cross-OS testing prior to commit, that's a key > part of the role of the buildbots Are the buildbots able to test UI features like menu selections? Neil ___ 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] in a pickle: method lookup irregularities
(See http://bugs.python.org/issue16251) The pickle module looks up special methods on instances rather than using the behavior described in the language reference (or even just looking them up on the class). This means that custom __getattribute__() and __getattr__() implementations may get triggered (e.g. if there is no __reduce__() implemented). Bringing pickle in sync with the language reference would not involve a big change, but it would impact anyone that relies on the current behavior. Most notably, proxy types could exist which leverage the current semantics. I look at this as trading one "bug" for another in a . So I want to get some general feedback on the situation and see what others consider to be the trade-offs of fixing or not fixing this bug. I'm particularly interested in existing cases where code uses the current behavior. With that in hand we could assess what alternatives exist in those cases or how we could better document workarounds for the current behavior. -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] in a pickle: method lookup irregularities
On Sun, Feb 17, 2013 at 1:36 PM, Eric Snow wrote: > (See http://bugs.python.org/issue16251) > > The pickle module looks up special methods on instances rather than > using the behavior described in the language reference (or even just > looking them up on the class). This means that custom > __getattribute__() and __getattr__() implementations may get triggered > (e.g. if there is no __reduce__() implemented). > > Bringing pickle in sync with the language reference would not involve > a big change, but it would impact anyone that relies on the current > behavior. Most notably, proxy types could exist which leverage the > current semantics. > > I look at this as trading one "bug" for another in a . So I want to > get some general feedback on the situation and see what others > consider to be the trade-offs of fixing or not fixing this bug. I'm > particularly interested in existing cases where code uses the current > behavior. With that in hand we could assess what alternatives exist > in those cases or how we could better document workarounds for the > current behavior. I vaguely recall some discussions about this and other similar cases of metaclass confusion (perhaps related to the copy module). One possible approach is to look specifically for cases where type(obj) != obj.__class__ and handle them differently. The general trend has been towards more consistently ignoring instance attributes when looking up special methods, but you're right that this can be a backwards compatibility minefield. 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] Submitting PEP 425 (compatibility tags)
On Sat, Feb 16, 2013 at 2:06 PM, Daniel Holth wrote: > This is the improved compatibility tags PEP 425, specifying how part of the > Wheel PEP 427 filenames work. Last time we discussed whether replacing . > with _ was ugly but I concluded it was harmless. Daniel has updated the example and FAQ as I requested, so PEP 425 is now accepted. 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] Cut/Copy/Paste items in IDLE right click context menu
On Sun, 17 Feb 2013 14:00:24 +1100, Neil Hodgson wrote: > Nick Coghlan: > > > - no need for extensive cross-OS testing prior to commit, that's a key > > part of the role of the buildbots > >Are the buildbots able to test UI features like menu selections? Not to mention that the test suite is a bit sparse for Idle, despite recent efforts to improve this, even for the stuff that can be tested. --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
