Re: [Python-Dev] AST optimizer implemented in Python
Stefan Behnel, 12.08.2012 08:00: > Victor Stinner, 11.08.2012 20:30: >> I started to implement an AST optimizer in Python. It's easy to create >> a new AST tree, so I'm surprised that I didn't find any existing >> project. >> >> https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py > > Since you're about to do pretty much the same thing, here is the code that > Cython uses for its static tree optimisations. It's not based on Python's > own AST, but most of the concepts should apply more or less directly to > that as well. > > https://github.com/cython/cython/blob/master/Cython/Compiler/Optimize.py Another thing I think I should mention is my TreePath implementation, mostly stealing from Fredrik Lundh's ElementPath. https://github.com/cython/cython/blob/master/Cython/Compiler/TreePath.py We basically only use it for test assertions against the AST, for example here: https://github.com/cython/cython/blob/master/tests/run/builtinslice.pyx But it wouldn't be all that hard to extend it into a pattern matching tool, so that you could basically say "if this expression matches the current subtree, then jump to optimiser a), for another expression use optimiser b), else leave things untouched". Stefan ___ Python-Dev mailing list [email protected] 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): zip() returns an iterator, make a list() of it; thanks to Martin from docs@
On Sun, Aug 12, 2012 at 1:25 AM, sandro.tosi wrote: > http://hg.python.org/cpython/rev/233673503217 > changeset: 78512:233673503217 > user:Sandro Tosi > date:Sun Aug 12 10:24:50 2012 +0200 > summary: > zip() returns an iterator, make a list() of it; thanks to Martin from docs@ > diff --git a/Doc/tutorial/datastructures.rst b/Doc/tutorial/datastructures.rst > - >>> zip(*matrix) > + >>> list(zip(*matrix)) > [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)] Is there a reason we don't run the doctests in the Doc/ folder's .rst files as part of regrtest (e.g. via DocFileSuite), or is that something we just haven't gotten around to doing? --Chris ___ Python-Dev mailing list [email protected] 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): zip() returns an iterator, make a list() of it; thanks to Martin from docs@
Just now doctest-like code blocks in Doc/* are used for two different targets: 1. regular doctests 2. notation for documentation While former can be tested the later will definitely fail (missing variables, functions, files etc.) Also docs contains mixed notation, when, say, function declared as regular code block than called from doctest (see functools.lru_cache examples). Doctest obviously failed because it cannot find function. For now if you will try to run doctest on Doc/**.rst you will get *a lot* of failures. I doubt if we will convert all docs to pass doctests, at least quickly. Also making docs doctest-safe sometimes requires less clean and worse readable notation. On Sun, Aug 12, 2012 at 3:40 PM, Chris Jerdonek wrote: > On Sun, Aug 12, 2012 at 1:25 AM, sandro.tosi > wrote: >> http://hg.python.org/cpython/rev/233673503217 >> changeset: 78512:233673503217 >> user:Sandro Tosi >> date:Sun Aug 12 10:24:50 2012 +0200 >> summary: >> zip() returns an iterator, make a list() of it; thanks to Martin from docs@ > >> diff --git a/Doc/tutorial/datastructures.rst >> b/Doc/tutorial/datastructures.rst >> - >>> zip(*matrix) >> + >>> list(zip(*matrix)) >> [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)] > > Is there a reason we don't run the doctests in the Doc/ folder's .rst > files as part of regrtest (e.g. via DocFileSuite), or is that > something we just haven't gotten around to doing? > > --Chris > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] 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): zip() returns an iterator, make a list() of it; thanks to Martin from docs@
On Sun, Aug 12, 2012 at 11:00 PM, Andrew Svetlov wrote: > I doubt if we will convert all docs to pass doctests, at least quickly. > Also making docs doctest-safe sometimes requires less clean and worse > readable notation. About the only thing that could work in a reasonable way is a doctest mode for 3.4 where it could be told to ignore files unless they contained some kind of "doctest-safe" marker. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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): zip() returns an iterator, make a list() of it; thanks to Martin from docs@
Sounds good. On Sun, Aug 12, 2012 at 4:37 PM, Nick Coghlan wrote: > On Sun, Aug 12, 2012 at 11:00 PM, Andrew Svetlov > wrote: >> I doubt if we will convert all docs to pass doctests, at least quickly. >> Also making docs doctest-safe sometimes requires less clean and worse >> readable notation. > > About the only thing that could work in a reasonable way is a doctest > mode for 3.4 where it could be told to ignore files unless they > contained some kind of "doctest-safe" marker. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] 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): zip() returns an iterator, make a list() of it; thanks to Martin from docs@
On Sun, Aug 12, 2012 at 6:37 AM, Nick Coghlan wrote: > On Sun, Aug 12, 2012 at 11:00 PM, Andrew Svetlov > wrote: >> I doubt if we will convert all docs to pass doctests, at least quickly. >> Also making docs doctest-safe sometimes requires less clean and worse >> readable notation. > > About the only thing that could work in a reasonable way is a doctest > mode for 3.4 where it could be told to ignore files unless they > contained some kind of "doctest-safe" marker. I created an issue for this here: http://bugs.python.org/issue15629 --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.0 beta 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm happy to announce the
second beta release of Python 3.3.0 -- a little later than originally
scheduled, but much better for it.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html (*)
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlAnxVAACgkQN9GcIYhpnLAECACcDeE+N2AfYVnuwMkq682znfDU
ODAAn0J87+MVA9WHEV5iYZd3ub9ZhbpC
=LvY0
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
On Sat, Aug 11, 2012 at 8:03 PM, Brett Cannon wrote: > > It would also be very easy to expand importlib.abc.SourceLoader to add a > method which is called with source and returns the bytecode to be written > out which people could override with AST optimizations before sending the > bytecode back. That way we don't have to get into the whole business of AST > transformations if we don't want to (although, as Victor pointed out, there > are some people who do want this formally supported). I'm not sure if this is directly related or not, but making this mechanism support custom compilation for new filename suffixes would be nice, especially for various e.g. HTML/XML templating systems that compile to Python or bytecode. Specifically, having a way to add a new source suffix (e.g. ".kid", ".zpt", etc.) and a matching compilation function, such that it's automatically picked up for compilation by both the filesystem and zip importers would be awesome. It'd also allow for DSLs and syntax experiments using alternative filename extensions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
I'm not sure if this is directly related or not, but making this mechanism support custom compilation for new filename suffixes would be nice, especially for various e.g. HTML/XML templating systems that compile to Python or bytecode. Specifically, having a way to add a new source suffix (e.g. ".kid", ".zpt", etc.) and a matching compilation function, such that it's automatically picked up for compilation by both the filesystem and zip importers would be awesome. It'd also allow for DSLs and syntax experiments using alternative filename extensions. How would the compilation (and the resulting code) then be invoked? If it is through import statements, it should already be possible to have import load an html file. However, ISTM that what you want is not modules, but files which rather are similar to individual functions. So the feature would go as an extension to exec() or eval(). I'm skeptical that this can be generalized in a useful manner - the exec/eval/execfile family already has variations depending on whether the thing to run is a single statement, a block, or an expression. It matters whether it gets its parameters passed, or somehow draws them from the environment - and then, which sources? If you would want to support HTML template engines alone, you find that they typically have many distinct parameter sets (the request, the ORM, the process environment, and then actual python-level parameters). So defining something that compiles it may be the easy part; the tricky part is defining something that then executes it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
> I started to implement an AST optimizer in Python. It's easy to create
> a new AST tree, so I'm surprised that I didn't find any existing
> project.
I done more research. I found the AST optimizer of PyPy, which
implements basic optimizations:
https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/optimize.py
So there is also something like an AST optimizer in Cython:
https://github.com/cython/cython/blob/master/Cython/Compiler/Optimize.py
https://github.com/cython/cython/blob/master/Cython/Compiler/ParseTreeTransforms.py
https://github.com/cython/cython/blob/master/Cython/Compiler/Builtin.py
https://github.com/cython/cython/blob/master/Cython/Compiler/Pipeline.py#L123
--
> https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py
I moved the script to a new dedicated project on Bitbucket:
https://bitbucket.org/haypo/astoptimizer
Join the project if you want to help me to build a better optimizer!
It now works on Python 2.5-3.3.
> There is BytecodeAssembler [1], but it seems to be specialized on
> bytecode. There are (at least?) 3 different issues to implement an AST
> optimizer, but in C, not in Python:
>
> http://bugs.python.org/issue1346238
> http://bugs.python.org/issue10399
> http://bugs.python.org/issue11549
Oh, http://bugs.python.org/issue10399 includes an optimizer
implemented in Python: Lib/__optimizer__.py. It inlines functions and
create specialized versions of a function.
> My proof-of-concept only implements very basic optimizations like 1+1
> => 2 or "abcdef"[:3] => "abc", but it should easy to extend it to do
> more interesting optimization like function inlining.
It is also possible to call functions and methods at compile time, if
there have no border effect (and don't depend on the environnement).
For example, len("abc") is always 3. I added a lot of such functions,
especially builtin functions.
I added options to enable more aggressive optimizations if we know
that result will run on the same host than the compiler (os.name,
sys.byteorder, ... are replaced by their value).
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
On Sat, Aug 11, 2012 at 1:30 PM, Victor Stinner wrote: > Hi, > > I started to implement an AST optimizer in Python. It's easy to create > a new AST tree, so I'm surprised that I didn't find any existing > project. > > https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py Very cool. > To test its peephole optimizations (by checking manually its final > bytecode), I wrote a patch for Python to disable Python internal > peephole optimizer (on bytecode): > https://bitbucket.org/haypo/misc/src/tip/python/compile_disable_peephole.patch > > -- > > There is BytecodeAssembler [1], but it seems to be specialized on > bytecode. There are (at least?) 3 different issues to implement an AST > optimizer, but in C, not in Python: > > http://bugs.python.org/issue1346238 > http://bugs.python.org/issue10399 > http://bugs.python.org/issue11549 I read through the issues a while back and each is interesting in its own right. However, each is a specific implementation that is somewhat general, but geared towards one optimization (folding, inlining, etc...). ISTM, that we need to step back a bit and define a what an AST optimizer for Python should look like (or even if it really makes any sense at all). I imagine having some facilities to manage and add new passes would be useful, for instance. I think this work probably merits a PEP (considering we essentially have four competing implementations for AST optimization now). This is an interesting project and I would happily volunteer to help flesh out the details of a prototype and working on a PEP. -- # Meador ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
On Aug 12, 2012 12:56 PM, "PJ Eby" wrote: > I'm not sure if this is directly related or not, but making this > mechanism support custom compilation for new filename suffixes would > be nice, especially for various e.g. HTML/XML templating systems that > compile to Python or bytecode. > > Specifically, having a way to add a new source suffix (e.g. ".kid", > ".zpt", etc.) and a matching compilation function, such that it's > automatically picked up for compilation by both the filesystem and zip > importers would be awesome. It'd also allow for DSLs and syntax > experiments using alternative filename extensions. +1 I'm hacking around this right now for a project I'm working on. I definitely do this through the import system. Inserting a look-alike path hook and monkeypatching the cached path entry finders is not difficult, but certainly fragile and less than ideal. Consequently I've been looking into simple and not-so-simple solutions to making it easier to add new suffixes to be handled. The source/pyc-to-code-to-module path during imports is so prevalent and critical that it may benefit from its own model. This is similar to how the path-based import subsystem has its own special-case model. Or source-based imports just need better special-casing in the path-based import subsystem. Perhaps just adding and using sys.source_suffixes as a mapping of suffixes to loader classes. -eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
On Sun, Aug 12, 2012 at 6:07 PM, Eric Snow wrote: > On Aug 12, 2012 12:56 PM, "PJ Eby" wrote: > > I'm not sure if this is directly related or not, but making this > > mechanism support custom compilation for new filename suffixes would > > be nice, especially for various e.g. HTML/XML templating systems that > > compile to Python or bytecode. > > > > Specifically, having a way to add a new source suffix (e.g. ".kid", > > ".zpt", etc.) and a matching compilation function, such that it's > > automatically picked up for compilation by both the filesystem and zip > > importers would be awesome. It'd also allow for DSLs and syntax > > experiments using alternative filename extensions. > > +1 > > I'm hacking around this right now for a project I'm working on. I > definitely do this through the import system. Inserting a look-alike path > hook and monkeypatching the cached path entry finders is not difficult, but > certainly fragile and less than ideal. > Why are you doing that? Can't you just use FileFinder with new loaders and file suffixes? Why do you feel the need to much with any cache? > Consequently I've been looking into simple and not-so-simple solutions to > making it easier to add new suffixes to be handled. The > source/pyc-to-code-to-module path during imports is so prevalent and > critical that it may benefit from its own model. > 3.4 will expose more of this. The source-to-code method would get you the transformation that PJE wants while 3.3 already has FileFinder handle the finding of the proper files for you. Toss in a method or two to help in parsing byte-compiled files and writing them and most of the process is then exposed. > This is similar to how the path-based import subsystem has its own > special-case model. Or source-based imports just need better > special-casing in the path-based import subsystem. Perhaps just adding and > using sys.source_suffixes as a mapping of suffixes to loader classes. > This is starting to get off-topic, but no more adding stuff to sys in regards to import. There is already too much global state that is preventing good encapsulation and we don't need to make it any worse. The more we add to sys in regards to import the farther we get from any import engine solution that we might want to evolve towards. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST optimizer implemented in Python
On Mon, Aug 13, 2012 at 7:05 AM, Meador Inge wrote: > This is an interesting project and I would happily volunteer to help flesh > out the details of a prototype and working on a PEP. Also, if there are possible AST improvements that would help in 3.4+, that option *is* on the table (this was an issue with cleaning up some of the constant folding support - there's some silliness in the current AST that was inherited from the 2.x series, but really isn't needed in 3.x). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 2.7 + https + urlopen = ?
I am a python 2.7.x user and am hoping to reach with this email some python
developers who would be sympathetic to this scenario (And I understand that you
might not, which is perfectly fine -- I've already requested one developer not
to reply ) :
How would you feel, if you issued :
import urllib
urlopen("""https://server.domain.com""";).read()
and the command got you data from some other URL without telling you! You use
firefox, and the site is different than the data you got! Same with chrome.
Safari. Even IE !
Cheated? (Well I was mad -- after IE worked).
Then, you dig a little and say, hey there are bugs in networks/code, lets try
the other tools that are available on python 2.x, who uses urlopen from urllib
in 2012. There are tons, right?
urllib2, urllib, urllib3, requests, twisted.getPage, ...
None of them worked! Wow. Then you wonder, whats going on. You poke one of the
server administrator, and he sends you the logs, and you see the problem. The
keyword being "SNI". Now you start googling. First read about SNI perhaps. Here
is a 2 line summary:
SNI is a server side "feature" that extends SSL and TLS protocols to let you
talk to a https server which is on an IP that serves multiple certificates for
multiple https servers. SNI was first used in 2004 and OpenSSL started support
in 2006. In 2007, it was backported to OpenSSL 0.9.x. In 2009 there was a bug
filed with python-devs for fixing this in 2.6. The feature enhancement (or "bug
fix") eventually happened -- for 3.2+.
(http://en.wikipedia.org/wiki/Server_Name_Indication)
Then you google more and you land up on this page:
http://bugs.python.org/issue5639
which shows you that 2.6 has a patch. Then you wonder, why wasn't it included
in 2.7 -- and you read -- AP : "No, Python 2 only receives bug fixes.". You
instantly hate the guy. Sorry AP, nothing personal, but please do not reply to
this post. I think I know what your reply will be.
After a lot of pain, I got myself out of this trouble, and my code now works
correctly on 2.7.x (thanks to Jean-Paul Calderone's pyopenssl). But do "you"
think this is a "feature" and not a "bug"? -- And do you think debating on
this, killing time on the debate, and letting all python 2.x users suffer
sooner or later is right --. Something as basic as urlopen!
Thanks for your time and I wish good luck to most python users.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 2.7 + https + urlopen = ?
I am a python 2.7.x user and am hoping to reach with this email some python
developers who would be sympathetic to this scenario (And I understand that you
might not, which is perfectly fine -- I've already requested one developer not
to reply ) :
How would you feel, if you issued :
import urllib
urlopen("""https://server.domain.com""";).read()
and the command got you data from some other URL without telling you! You use
firefox, and the site is different than the data you got! Same with chrome.
Safari. Even IE !
Cheated? (Well I was mad -- after IE worked).
Then, you dig a little and say, hey there are bugs in networks/code, lets try
the other tools that are available on python 2.x, who uses urlopen from urllib
in 2012. There are tons, right?
urllib2, urllib, urllib3, requests, twisted.getPage, ...
None of them worked! Wow. Then you wonder, whats going on. You poke one of the
server administrator, and he sends you the logs, and you see the problem. The
keyword being "SNI". Now you start googling. First read about SNI perhaps. Here
is a 2 line summary:
SNI is a server side "feature" that extends SSL and TLS protocols to let you
talk to a https server which is on an IP that serves multiple certificates for
multiple https servers. SNI was first used in 2004 and OpenSSL started support
in 2006. In 2007, it was backported to OpenSSL 0.9.x. In 2009 there was a bug
filed with python-devs for fixing this in 2.6. The feature enhancement (or "bug
fix") eventually happened -- for 3.2+.
(http://en.wikipedia.org/wiki/Server_Name_Indication)
Then you google more and you land up on this page:
http://bugs.python.org/issue5639
which shows you that 2.6 has a patch. Then you wonder, why wasn't it included
in 2.7 -- and you read -- AP : "No, Python 2 only receives bug fixes.". You
instantly hate the guy. Sorry AP, nothing personal, but please do not reply to
this post. I think I know what your reply will be.
After a lot of pain, I got myself out of this trouble, and my code now works
correctly on 2.7.x (thanks to Jean-Paul Calderone's pyopenssl). But do "you"
think this is a "feature" and not a "bug"? -- And do you think debating on
this, killing time on the debate, and letting all python 2.x users suffer
sooner or later is right --. Something as basic as urlopen!
Thanks for your time and I wish good luck to most python users.
___
Python-Dev mailing list
[email protected]
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 2.7 + https + urlopen = ?
On Mon, Aug 13, 2012 at 11:28 AM, Python Urlopen wrote: > which shows you that 2.6 has a patch. Then you wonder, why wasn't it included > in 2.7 -- and you read -- AP : "No, Python 2 only receives bug fixes.". You > instantly hate the guy. Sorry AP, nothing personal, but please do not reply > to this post. I think I know what your reply will be. It's not merely Antoine that will give that reply. Yes, there are many features that Python 2 is lacking relative to the Python 3 series. That's what "maintenance mode" means. It's incredibly frustrating when you hit one of them (for myself, I feel the pain every time an error in an exception handler conceals the original exception). The available solutions are: 1. Use a third party PyPI package which offers that feature (in this case, the requirement seems to be to use PyOpenSSL) 2. Upgrade to Python 3 3. Fork Python 2 to create a Python 2.8 which adds new backported features from the Python 3 series That last option has indeed been discussed by a few people at various times, but the first option generally ends up being the preferred choice if the second isn't yet viable due to missing dependencies. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 2.7 + https + urlopen = ?
On 13/08/2012 02:39, Python Urlopen wrote: [snip] After a lot of pain, I got myself out of this trouble, and my code now works correctly on 2.7.x (thanks to Jean-Paul Calderone's pyopenssl). But do "you" think this is a "feature" and not a "bug"? -- And do you think debating on this, killing time on the debate, and letting all python 2.x users suffer sooner or later is right --. Something as basic as urlopen! It doesn't sound like a bug to me, more a missing feature, added in a later version of Python. That's what upgrading is all about. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
