Re: [Python-Dev] bytes-like objects
On 10/06/2014 06:34 AM, Nick Coghlan wrote: > 3. "buffer" is a completely new term for most users, and one that > refers to an implementation detail of memoryview, moreso than > something developers actually need to care about. Using it directly in > error messages and documentation is to make the abstraction leak in a > way that raises unnecessary barriers to entry. Especially since buffer() is gone in Py3. The only prominent mention of "buffer" in the docs is now the C API section that explains the buffer protocol. Since this is cross-referenced from the "bytes-like object" glossary, it will lead people who want to write such an object to the right place. Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes-like objects
On 06/10/14 10:33, Georg Brandl wrote: > bytes-like object Howdy, two small comments: 1) just as a quick check, I did a Python search for exactly that phrase https://docs.python.org/3/search.html?q=bytes-like+object&check_keywords=yes&area=default with zero results. Maybe it would be a good thing if glossary entries were always found via the search page. 2) And about this glossary entry: "An object that supports the Buffer Protocol" - can I take that for granted, as a real definition, meaning """an object is bytes-like iff it supports the buffer protocol"""? cheers - Chris -- Christian Tismer :^) [email protected] Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://www.pydica.net/ 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fixing 2.7.x
With the incredibly long life span of 2.7, which bugs should we *not* fix? For example, in http://bugs.python.org/issue22297 I mentioned one reason to not fix that bug was that the fix was not in 3.1-3.3, but 2.7 will outlive all those plus a couple more. So, what are the current guidelines on what to fix? Is it still security only, with the rest being carrots for switching? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, 06 Oct 2014 09:08:23 -0700 Ethan Furman wrote: > With the incredibly long life span of 2.7, which bugs should we *not* fix?* Those that are not bugs but enhancement requests. On that issue, you pointed out there was no regression and that enums were never meant to be supported by the json module at that time, so IMHO it's a won't fix. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
In article <[email protected]>, Ethan Furman wrote: > With the incredibly long life span of 2.7, which bugs should we *not* fix? > > For example, in http://bugs.python.org/issue22297 I mentioned one reason to > not fix that bug was that the fix was not in > 3.1-3.3, but 2.7 will outlive all those plus a couple more. > > So, what are the current guidelines on what to fix? Is it still security > only, with the rest being carrots for switching? Python release families are in one of four states: 1. in-development feature: the default branch, unreleased = 3.5 2. maintenance: currently released and actively maintained, bug fixes, no compatibility breaks, no new features without very compelling use cases, discussion, and release manager approval. = 2.7.x and 3.4.x 3. security: "fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch." = 3.2.x and 3.3.x 4. retired: no fixes of any kind from python-dev = all other releases So 2.7.x is not "security only" and wouldn't reach that stage until 2020 under current policy. http://legacy.python.org/dev/peps/pep-0373/#id5 https://docs.python.org/devguide/devcycle.html#branches -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > So 2.7.x is not "security only" and wouldn't reach that stage until 2020 > under current policy. Apparently no other 2.x release qualifies as "security only" at this point? I would have expected at least 2.6 to fall into that category. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
In article , Skip Montanaro wrote: > Apparently no other 2.x release qualifies as "security only" at this > point? I would have expected at least 2.6 to fall into that category. 2.6 had its five-year run. "Python 2.6.9 is the final security-only source-only maintenance release of the Python 2.6 series. With its release on October 29, 2013, all official support for Python 2.6 has ended. Python 2.6 is no longer being maintained for any purpose." http://legacy.python.org/dev/peps/pep-0361/ -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Tue, Oct 7, 2014 at 4:33 AM, Skip Montanaro wrote: > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: >> So 2.7.x is not "security only" and wouldn't reach that stage until 2020 >> under current policy. > > Apparently no other 2.x release qualifies as "security only" at this > point? I would have expected at least 2.6 to fall into that category. Was until about a year ago. http://legacy.python.org/dev/peps/pep-0361/ ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > 3. security: "fixing issues exploitable by attackers such as crashes, > privilege escalation and, optionally, other issues such as denial of > service attacks. Any other changes are not considered a security risk > and thus not backported to a security branch." >= 3.2.x and 3.3.x 3.1 is still in this category, is it not? According to PEP 375, it's a few months past due for its last release. http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06.10.14 20:55, Zachary Ware wrote: > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: >> 3. security: "fixing issues exploitable by attackers such as crashes, >> privilege escalation and, optionally, other issues such as denial of >> service attacks. Any other changes are not considered a security risk >> and thus not backported to a security branch." >>= 3.2.x and 3.3.x > > 3.1 is still in this category, is it not? According to PEP 375, it's > a few months past due for its last release. > > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases > I don't think that the rules should be implicitly considered compatible between the 2.X and 3.X series. Python 2.X has a history that extends to X==6, X==5 and even X==4, as a really conservative POV with an extent over more than 10 years. I believe, such a thing does not exist for the Python 3.X series at all. My impression is that no 3.X user ever would want to stick with any older version. Is that true, or am I totally wrong? cheers -- Chris - -- Christian Tismer :^) [email protected] Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://www.pydica.net/ 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUMur7AAoJEOcwEVD7e+4OW0UIAJk2ZTFX3OjBrt1G0RZc9nPb hHVxGJNXNeBellM9BpmoW9t9hgk94lAIgmh5hop5uMt32o9CH47s97rKw7K1ekl5 sML/4hl5/BLRiHXgwSB1ZltqZrvG/xsE6AE1v37BcPf/X3T4UfPhW30z+43eaBJw Q3b21EwxxUJGJ//GWwi2+buCfkfRuePBIB4MQiMm3/JI9h03EPbRoQ0/53huKLeW I7oAemVzprQHw7coaTf6EOHFTlmUfHvm5K9ywpabX10/Ediz1suJfPMPdzUigHG3 G3ABMKAA1YockpfIDU/7rpmDcliblpjU5MT4BsZycuYXOyUesV6uDaLMOdO5fEY= =ZuoT -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014 at 2:18 PM, Christian Tismer wrote: > My impression is that no 3.X user ever would want to stick > with any older version. > > Is that true, or am I totally wrong? My impression is that you're mostly right, but only because those who would still be on 3.1 are actually still on 2.5 ;). However as one who uses 3.x exclusively, I do still use 3.2 on a regular basis simply because it's the last release to support Windows 2000 and it does everything I need to do on that platform. Either way, that seems a bit tangential to my original point, which was that 3.1 is still technically an open security branch which is due to be closed (with or without it's last security release, which was due in June). -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semi-official read-only Github mirror of the CPython Mercurial repository
Eli, Thanks for setting this up. People are evidently finding it quite useful and are wondering if it could be more frequently run. We don't want you to have to absorb the bandwidth costs yourself, though. Is the code you use available somewhere? It shouldn't be hard to set up the cron job on PSF infrastructure. On Sat, Jul 12, 2014, at 09:15, Eli Bendersky wrote: > Just a quick update on this. I've finally found time to set up a VPS at > DigitalOcean of myself, and I'm moving the cronjob for updating the > Github > mirrors to it. This lets me ramp up the update frequency. For now I'll > set > it to every 4 hours, but in the future I may make it even more frequent. > Hopefully this will not overrun my bandwidth allocation :) > > The CPython mirror (https://github.com/python/cpython) has been pretty > popular so far, with over 70 forks. > > Eli > > > > On Mon, Sep 30, 2013 at 6:09 AM, Eli Bendersky wrote: > > > Hi all, > > > > https://github.com/python/cpython is now live as a semi-official, *read > > only* Github mirror of the CPython Mercurial repository. Let me know if you > > have any problems/concerns. > > > > I still haven't decided how often to update it (considering either just N > > times a day, or maybe use a Hg hook for batching). Suggestions are welcome. > > > > The methodology I used to create it is via hg-fast-export. I also tried to > > pack and gc the git repo as much as possible before the initial Github push > > - it went down from almost ~2GB to ~200MB (so this is the size of a fresh > > clone right now). > > > > Eli > > > > P.S. thanks Jesse for the keys to https://github.com/python > > > > > > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, 06 Oct 2014 21:18:23 +0200, Christian Tismer wrote: > On 06.10.14 20:55, Zachary Ware wrote: > > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > >> 3. security: "fixing issues exploitable by attackers such as crashes, > >> privilege escalation and, optionally, other issues such as denial of > >> service attacks. Any other changes are not considered a security risk > >> and thus not backported to a security branch." > >>= 3.2.x and 3.3.x > > > > 3.1 is still in this category, is it not? According to PEP 375, it's > > a few months past due for its last release. > > > > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases > > > > I don't think that the rules should be implicitly considered > compatible between the 2.X and 3.X series. > > Python 2.X has a history that extends to X==6, X==5 and > even X==4, as a really conservative POV with an extent over more > than 10 years. > > I believe, such a thing does not exist for the Python 3.X series > at all. My impression is that no 3.X user ever would want to stick > with any older version. > > Is that true, or am I totally wrong? I don't think you are *totally* wrong, but I don't think you are really right, either. I myself have at least one system (I didn't check them all) running 3.2 that I have intentionally only done security fixes on rather than upgrade python3. It's mostly laziness (given that my distro provides the security updates), since I don't think there would be any compatibility problems with the few python3 programs running on it, but I'm likely not the only one. So yes, the same rules should apply to python3 as apply to python2, especially since more distros are about to start shipping python3 as the system python (Arch has been since 2011). 3.1, however, is most likely a dead issue. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
Hi, 2014-10-06 18:08 GMT+02:00 Ethan Furman : > With the incredibly long life span of 2.7, which bugs should we *not* fix? I started a list of Python 2 bugs that will not be fixed: http://haypo-notes.readthedocs.org/python.html#bugs-that-won-t-be-fixed-in-python-2-anymore It *is* possible to fix all bugs, but it requires a large amount of work, and we decided to focus our energy on Python 3. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Idea to support lazy loaded names.
I've got an idea for Python but don't know where to post it. It seems
like this may be the right place.
When developing Python libraries (and any other language for that
matter), items are separated into modules for organization and other
purpose. The following is an example fake framework to illustrate this:
mini-framework/
__init__.py
app.py
class BaseApplication
class Application
class ProxyApplication
config.py
class Config
class ConfigLoader
template.py
class Template
class TemplateCompiler
class TemplateManager
In order to be used externally, one must reference the module:
from miniframework.app import Application
from miniframework.template import TemplateManager
This can be solved by importing these values directly in __init__.py.
However this requires fully loading those imported modules:
__init__.py:
from .app import BaseApplication, Application, ProxyApplication
from .config import Config, ConfigLoader
from .template import Template, TemplateCompiler, TemplateManager
One idea I had was to support lazy imported names. I've seen some
frameworks implement this in various means, and figured the idea is good
to be part Python.
The idea is that for a new module attribute to exist: __lazyload__.
During the access of any attribute for a module, the following would
happen:
* If the named attribute already exists, use it
* If the named attribute does not already exist:
* If a lazy load of the name has already been attempted, result in
a NameError
* If a lazy load of the name has not yet been attempted:
* Check the __lazyload__ module attribute for the name, perform
the loading operation and assign the module attribute the
value if found or result in a NameError
* Even if not found, set a flag that lazy load has been
attempted so it will not be attempted again for the same name
The __lazyload__ attribute is intended to be a dictionary. The key of
the dictionary is the name of the attribute that would be set/tested
for in the module. The value of the dictionary is a string that
represents either the module name to load or the module name and
attribute to load. If the value starts with a dot, then it is treated
as a relative import relative to the module/package containing the
__lazyload__ value.
With this idea, the packages __init__.py file could look like this:
__lazyload__ = {
'BaseApplication': '.app.BaseApplication',
'Application': '.app.Application',
...
}
The end use of the package (and even the developer) can then perform an
import as follows:
from miniframework import Application
instead of:
from miniframework.app import Application
This allows the public api be be cleaner, while still being efficient
by not loading all modules in __init__.py until the value is actually
accessed.
Brian Allen Vanderburg II
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Idea to support lazy loaded names.
On Mon, Oct 6, 2014, at 16:36, Brian Allen Vanderburg II wrote: > I've got an idea for Python but don't know where to post it. [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On 2014-10-06, 20:03 GMT, Victor Stinner wrote: > I started a list of Python 2 bugs that will not be fixed: > http://haypo-notes.readthedocs.org/python.html\ > #bugs-that-won-t-be-fixed-in-python-2-anymore > > It *is* possible to fix all bugs, but it requires a large amount of > work, and we decided to focus our energy on Python 3. What about bugs which have patch already devleoped for both py3k and py2k. Hint: I would love to have some movement on http://bugs.python.org/issue19494 :) Best, Matěj ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
In article , Zachary Ware wrote: > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > > 3. security: "fixing issues exploitable by attackers such as crashes, > > privilege escalation and, optionally, other issues such as denial of > > service attacks. Any other changes are not considered a security risk > > and thus not backported to a security branch." > >= 3.2.x and 3.3.x > 3.1 is still in this category, is it not? According to PEP 375, it's > a few months past due for its last release. > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases I don't think Benjamin was planning any further security releases. But, in any case, the PEP should be updated, I guess. Benjamin? -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014, at 19:13, Ned Deily wrote: > In article > , > Zachary Ware wrote: > > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > > > 3. security: "fixing issues exploitable by attackers such as crashes, > > > privilege escalation and, optionally, other issues such as denial of > > > service attacks. Any other changes are not considered a security risk > > > and thus not backported to a security branch." > > >= 3.2.x and 3.3.x > > 3.1 is still in this category, is it not? According to PEP 375, it's > > a few months past due for its last release. > > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases > > I don't think Benjamin was planning any further security releases. But, > in any case, the PEP should be updated, I guess. Benjamin? Oh, yeah, I'm really tired of 3.1, so it's over. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
