Re: Python 3 is killing Python
On 15/07/2014 05:40, Chris Angelico wrote: On Tue, Jul 15, 2014 at 2:18 PM, Rick Johnson wrote: Yeah, because nobody managed to do anything during all that time, the Royal Air Force was nowhere to be seen, and the various Resistances in occupied countries were completely ineffectual. Some might like to know that some US guys gave up their passports to fight with the RAF. The most successful squadron during the Battle of Britain was 303 which was Polish flyers. Apparently they were brilliant having learnt their trade flying biplanes against Messerschmitt BF109s. 1940 invasion of Britain? No chance, we took years building the moat we call the English Channel. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 04:58, Michael Torrie wrote: On 06/03/2014 12:12 AM, wxjmfa...@gmail.com wrote: I was myself really suprised to fall on such a case and after thinking no, such cases may logically happen. Putting in this comment not for JMF but for poor souls who find this thread on a search and are led astray by jmf's trolling. Either it was your code or an issue with the Windows console that caused the exception. When you try to print out unicode strings, Python must convert them to the character encoding of the terminal in order to print them out. On sane systems this is UTF-8. On Windows it could be anything. Do you want Python to fail silently or do you want to fail with a useful message, with the option of specifying the exact behavior you want (replace unrepresentable characters with spaces, question marks, etc)? Sorry if I'm repeating myself but this is relevant http://bugs.python.org/issue21927 specifically msg222761. Seems like jmf, though being a self-proclaimed unicode expert, continually confusing unicode with encoding schemes. He's been spouting his bile on this subject on this list for IIRC nearly two years. Still he gets away with it. Is he sleeping with the right people I ask myself? It's not important. I'm no more writing Py apps, only considering software through an unicode eye. Please just stop posting to this list. thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
xslt with python
I am trying to merge two xmls using xslt in python but the content of first xml is not getting copied. The rules written in xsl file created are correct because if I am executing it without python (directly from eclipse as I have xslt plugin installed) it is getting merged fine. Can anybody help me? I am pasting my code snippet below: *import lxml.etree as ET* *dom = ET.parse(r'test_file_2.xml')* *xslt = ET.parse(r'TestMergeRules.xsl')* *transform = ET.XSLT(xslt)* *print transform* *newdom = transform(dom)* *print(ET.tostring(newdom, pretty_print=True))* I am opening other xml file (test_file_1.xml) in xsl file using "document()" function. Once this code is executed I can see only the content of test_file_2.xml. Am I doing something wrong? Is there any other way to do this because my xslt rules are working fine without python. Thanks, BR, Varun -- https://mail.python.org/mailman/listinfo/python-list
networkx plot random graph Error
I am trying to read a file with 3 columns with col 1 and 2 as nodes/edges and
column 3 as weight (value with decimal)
I am trying to execute this code
import networkx as nx
G = nx.read_edgelist('file.txt', data=[("weight")])
G.edges(data=True)
edge_labels = dict(((u, v), d["weight"]) for u, v, d in G.edges(data=True))
pos = nx.random_layout(G)
nx.draw(G, pos)
nx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels)
import matplotlib.pyplot as plt; plt.show()
Error:
File "graph_one.py", line 4, in
G = nx.read_edgelist('File.txt', data=[("weight")])
File "", line 2, in read_edgelist
File
"/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/utils/decorators.py",
line 241, in _open_file
fobj = _dispatch_dict[ext](path, mode=mode)
IOError: [Errno 2] No such file or directory: 'contactUSC_nodes_diff_small.txt'
lavanya@peerformance:~/Desktop/INRIA_Papers/Python$ python graph_one.py
Traceback (most recent call last):
File "graph_one.py", line 4, in
G = nx.read_edgelist('contactUSC_node_diff_small.txt', data=[("weight")])
File "", line 2, in read_edgelist
File
"/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/utils/decorators.py",
line 263, in _open_file
result = func(*new_args, **kwargs)
File
"/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/readwrite/edgelist.py",
line 367, in read_edgelist
data=data)
File
"/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/readwrite/edgelist.py",
line 286, in parse_edgelist
for (edge_key,edge_type),edge_value in zip(data,d):
ValueError: too many values to unpack
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
My two cents as a new pythonista and a scientist: isn't python2 killing python? This old stuff is everywhere in the tutorials, docs, etc. and this is quite annoying. When I download a python notebook, the first thing I have to do is to translate it to py3. Which is not an easy task, given the fact that I am the tutorial *user* and am supposed to learn ;) Side note: Debian/Ubuntu/Mint announced the total migration to python3, which is good but still work in progress: https://wiki.ubuntu.com/Python/3 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
> > Image, for a moment, a world WITHOUT the great USA! Yes, i know you > little commies love to curse the USA, and yes, > there are many dark sins committed within AND beyond her borders, but > try to tell me you bass-turds, what nation in modern history has > contributed more technological achievements [1] The one you revolted from. The Same one that is your first port of call for assistance whenever you get yourselves involved in conflict. I think you will find that more inventions have originated on this desolate windswept island of the north coast of Europe than the USA. We are called Great Britain, the clue is in the name. -- Charm is a way of getting the answer "Yes" -- without having asked any clear question. -- https://mail.python.org/mailman/listinfo/python-list
Anything better than asyncio.as_completed() and asyncio.wait() to manage execution of large amount of tasks?
Hi, both asyncio.as_completed() and asyncio.wait() work with lists only. No generators are accepted. Are there anything similar to those functions that pulls Tasks/Futures/coroutines one-by-one and processes them in a limited task pool? I have gazillion of Tasks, and do not want to instantiate them all at once, but to instantiate and to address them one by one as the running tasks are completed. best regards -- Valery -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Steven D'Aprano: I'll give you the benefit of the doubt, and assume that when you first posted you hadn't realised that the audience here does not have the relevant experience, but by refusing to ask the question elsewhere, and by making snide comments that "they don't like beer", that pretty much gives the game away that you're looking to have your opinion confirmed rather than looking for an honest answer. I really did run out of time when I said I did: I spent the last 5 days running a chess tournament with 137 participants, with the tournament management software written in Python by yours truly. Which worked beautifully, Python is a great language. And I'm going to Iceland on vacation tomorrow, so I'm not going to start a new discussion of a different mailing list just now, maybe later. Not everyone is as prolific a writer as you are, Steven. The talk about "the wrong list" would have carried more weight if you had started out by saying "wrong list", instead of going through every other argument first, before punting like that. By the way, which list is the appropriate one? The numpy and SciPy mailing lists are first and foremost about numpy and SciPy, I presume. Is there a general numerics-list somewhere also? I don't see any on https://mail.python.org/mailman/listinfo. By the way, you guys seem to have overlooked the opportunity for arbitrage: *Anyone* can go to a numerical list, poll for examples, and come back and earn some beer :) regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Mon, 14 Jul 2014 21:18:05 -0700, Rick Johnson wrote: > On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote: >> I dunno. It's not like Great Britain, Australia, or New Zealand did >> anything significant in either war, is it. > > Most of Europe occupied, London bombed into the stone age; things were > looking grim Chris! Maybe you should read up on some WW2 history, it's > quite humbling to think what *could* have happened. Perhaps you should read history more thoroughly. Great Britain had successfully fended off German plans to invade BEFORE the USA joined the war (Google Battle of Britain). Had we failed there would have been nowhere available to launch the 'D' Day landings & the USSR would almost certainly have rolled over the whole of Europe. so contrary to the much held belief by Americans that they saved or bottoms in WWII the opposite is in fact the case. > >> Some people in Australia are still racist, but racism is nothing like >> the problem it is in America, where you boast so much of equality. > > Where do you get your info about America, from CNN? And for someone who > is a self-described "Aussie" you sure seem to know more about Americans > than Americans know about themselves... hmm, another enigma! I guarantee he knows more about he USA than the average Ammerican knows about Australia or anywhere outside their own border, I once had an American ask what state London was in (& we are quite a big part of your history)! > > Chris, one thing you need to understand about America is that a whole > grievance industry exists to perpetuate hate. > And sadly, most Americans are too stupid to realize this. Now that is the 1st thing you have read that I agree with 100% -- You'll never see all the places, or read all the books, but fortunately, they're not all recommended. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, Jul 15, 2014 at 10:17 PM, Fabien wrote: > My two cents as a new pythonista and a scientist: isn't python2 killing > python? You're new to Python, and so you correctly want to work with Python 3. That's fine. That's excellent, in fact. You're starting out the right way, and avoiding all the problems that Py3 specifically set out to solve. However, people-new-to-Python is not the only audience that the language supports. Everyone who *already has code*, written for (say) Python 2.5, wants some sort of assurance that it will still be runnable. It's a matter of trust; python.org implicitly promises that it's not a waste of time writing code in Python, and that's a promise that would be broken by cutting off Py2 support. The problem isn't Python 2, nor Python 3, nor even the fact that there are two Pythons. The problem is that a lot of people don't understand when to choose one or the other, don't understand what the promises of support are, and (perhaps worst of all) keep hearing FUD about how Python 3 is killing Python. And so the confusion perpetuates. Eventually the world will get past that, but in the meantime, we have to deal with these sorts of storms-in-teacups from people who simply cannot comprehend what's going on. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: xslt with python
On Tuesday, July 15, 2014 4:10:57 AM UTC-4, varun bhatnagar wrote: > I am trying to merge two xmls using xslt in python but the content of first > xml is not getting copied. The rules written in xsl file created are correct > because if I am executing it without python (directly from eclipse as I have > xslt plugin installed) it is getting merged fine. Can anybody help me? I am > pasting my code snippet below: > > import lxml.etree as ET > dom = ET.parse(r'test_file_2.xml') > xslt = ET.parse(r'TestMergeRules.xsl') > transform = ET.XSLT(xslt) > print transform > > newdom = transform(dom) > print(ET.tostring(newdom, pretty_print=True)) > > I am opening other xml file (test_file_1.xml) in xsl file using "document()" > function. > > Once this code is executed I can see only the content of test_file_2.xml. > Am I doing something wrong? Is there any other way to do this because my xslt > rules are working fine without python. > Hi BR, Your code looks very close but not exactly equal to the tutorial here: http://lxml.de/xpathxslt.html#xslt Can you try the example on that page and report the results? Plus your platform, python version and lxml details as described here: http://lxml.de/FAQ.html#i-think-i-have-found-a-bug-in-lxml-what-should-i-do thanks, --Tim Arnold -- https://mail.python.org/mailman/listinfo/python-list
Re: xslt with python
Hi Tim, Thanks a lot for the reply. I think I got the root cause of the problem. Before merging I am creating one dummy xml file on the fly and I am copying the content of first xml into that. This dummy file I am mentioning in xsl file and the URI is changing because of which it is not getting merged. I have to see how can I resolve the URI problem. //Varun On Tue, Jul 15, 2014 at 3:12 PM, Tim wrote: > On Tuesday, July 15, 2014 4:10:57 AM UTC-4, varun bhatnagar wrote: > > I am trying to merge two xmls using xslt in python but the content of > first xml is not getting copied. The rules written in xsl file created are > correct because if I am executing it without python (directly from eclipse > as I have xslt plugin installed) it is getting merged fine. Can anybody > help me? I am pasting my code snippet below: > > > > import lxml.etree as ET > > dom = ET.parse(r'test_file_2.xml') > > xslt = ET.parse(r'TestMergeRules.xsl') > > transform = ET.XSLT(xslt) > > print transform > > > > newdom = transform(dom) > > print(ET.tostring(newdom, pretty_print=True)) > > > > I am opening other xml file (test_file_1.xml) in xsl file using > "document()" function. > > > > Once this code is executed I can see only the content of test_file_2.xml. > > Am I doing something wrong? Is there any other way to do this because my > xslt rules are working fine without python. > > > Hi BR, > Your code looks very close but not exactly equal to the tutorial here: > http://lxml.de/xpathxslt.html#xslt > > Can you try the example on that page and report the results? > Plus your platform, python version and lxml details as described here: > http://lxml.de/FAQ.html#i-think-i-have-found-a-bug-in-lxml-what-should-i-do > > thanks, > --Tim Arnold > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/15/14, 9:00 AM, Chris Angelico wrote: The problem isn't Python 2, nor Python 3, nor even the fact that there are two Pythons. The problem is that a lot of people don't understand when to choose one or the other, don't understand what the promises of support are, and (perhaps worst of all) keep hearing FUD about how Python 3 is killing Python. And so the confusion perpetuates. Eventually the world will get past that, but in the meantime, we have to deal with these sorts of storms-in-teacups from people who simply cannot comprehend what's going on. I think it's more than a tempest in a teacup. The number of language revisions that result in deliberate, code-level incompatibility out there is pretty small. People rightly expect that code written for version 2.x of a language will continue to work with version 3.x, even if 3.x is designed to go in another direction. I can only think of two widely used languages in the last decade where there was this type of major break in binary compatibility: Perl and Visual Basic. Perl 6 is kind of a moot point because it's never shipped (insert reference to Duke Nukem or GNU HURD here, as appropriate), and Perl 5 has not just seen continued development, but invigorated development in recent years. But the example of VB is instructive. VB.NET is similar, but not identical, to classic VB, and as far as I am aware its uptake has not been nearly as wide as classic VB. Microsoft was able to force what limited migration we've seen mainly because VB is not open source and they can simply drop support for it from Windows. I've stayed with Python 2.7 because I've seen no benefit in 3.x that outweighs the hassle of going through my code line by line to make it compatible. As a Mac developer I deal with this kind of code/API churn with each release of Mac OS X, and I have no desire to increase my headaches. Though I expect I will eventually update to 3.x, however, like many other developers I am also annoyed by the decision to break backwards compatibility in Python. The decision strikes me as arrogant. Cruft and backwards compatibility are an inevitable part of any mature programming language, and maintaining compatibility is important--more important than bolting on shiny new features, in my view. If shiny new features must be added, they should be added side-by-side with older API's. I think the Python developers have undervalued the conservator part of their role. Yes, they have provided tools to help application and library developers migrate their code, but it should not be incumbent on third-party developers to re-architect stable, working code simply because the language has broken binary compatibility. Defenders of the 3.x migration portray such developers as laggards, but I see Python 3.x's failure to silently and successfully import 2.x code as a failure on the language's end. I won't go so far as to say that Python 3 is killing Python. Python will survive. But the headaches of migration are substantial, and should not be necessary. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, Jul 15, 2014 at 11:57 PM, Kevin Walzer wrote: > The number of language revisions that result in deliberate, code-level > incompatibility out there is pretty small. People rightly expect that code > written for version 2.x of a language will continue to work with version > 3.x, even if 3.x is designed to go in another direction. That's not strictly true. I would generally expect some concept of version numbering along the lines of semver.org's recommendations, or the Debian packaging guidelines (I think), or, or, or, or, or. You know the sort of thing: major.minor.revision, where "revision" changes shouldn't break anything unless you were, perhaps unwittingly, depending on a bug; "minor" changes add features, and might break code that was, say, using a new language keyword as an identifier (eg you can use "with" as a function name in Python 2.4, but in Python 2.6 that won't work); and "major" changes can cause backward incompatibility. That's not absolutely strictly true of all Python versions, but it's certainly very close. You would expect Python version 3.x to be broadly the same language as Python 2.x, but you cannot expect code to automatically run unmodified. That's the whole point of a major version number change. And that's exactly what we see; the similarities between Python 2.7 and 3.4 are pretty huge compared to the differences. They are definitely the same language. > I can only think of two widely used languages in the last decade where there > was this type of major break in binary compatibility: Perl and Visual Basic. ANSI C broke quite a bit compared to previous C implementations. Doesn't have quite a "version number", but it's the same concept. Object REXX (OREXX) breaks several things in Classic REXX (REXX). Both of those precede "the last decade", but I'd say the same thing applies: if the name or major version number changes, you can expect differences. (For this reason, I have never actually released a RosMud version 2.0; once I went stable with 1.0, I never needed to make backward-incompatible changes. The latest - and probably last - version is 1.7.0, and the project has been succeeded by Gypsum, which is a brand new project... new name, incompatible APIs.) > I've stayed with Python 2.7 because I've seen no benefit in 3.x that > outweighs the hassle of going through my code line by line to make it > compatible. And that's fine! The python-dev team has promised that 2.7 will continue to be supported; that means some headaches, especially on Windows (the Python 2.7 support will long outlast upstream Microsoft support for the compiler it's built on), but it's a promise that you can continue to run your 2.7 code. That said, though, I would advise you to give 2to3 a shot. You never know, it might do exactly what you need right out-of-the-box and give you a 3.x-compatible codebase in one hit. > Though I expect I will eventually update to 3.x, however, like many other > developers I am also annoyed by the decision to break backwards > compatibility in Python. The decision strikes me as arrogant. Cruft and > backwards compatibility are an inevitable part of any mature programming > language, and maintaining compatibility is important--more important than > bolting on shiny new features, in my view. If shiny new features must be > added, they should be added side-by-side with older API's. Big problem with that: it means that everyone who learns the language has to wrestle with *both* APIs. It's impossible to fix bugs. So how about this as a compromise: We'll have this special flag at the top of the program that says whether it should be in "compatibility mode" or "shiny new features mode". And hey, let's write it like this: #!/usr/local/bin/python2 # This program runs in compatibility mode. #!/usr/local/bin/python3 # This program gets all the new features. Python *is* maintaining backward compatibility. It's fundamentally not possible to add some of Python 3's features without some pretty big changes (look at, for instance, the str/bytes changes - essential to proper i18n, but impossible to do to a Py2-compatible interpreter), so the only way to do it is to continue to support Py2 while doing new development on Py3. > I think the Python developers have undervalued the conservator part of their > role. No, they haven't. That's exactly why Python 2.7 is to be supported for so long (2020 according to current plans), and why PEP 466 and such are so important. There's a lot of Python 2 code out there, and python-dev's taking the responsibility very seriously. > ... I see Python 3.x's failure to silently and > successfully import 2.x code as a failure on the language's end. Fine. Tell me how you would go about adding true Unicode support to Python 2.7, while still having it able to import an unchanged program. Trick question - it's fundamentally impossible, because an unchanged program will not distinguish between bytes and text, but true Unicode support requires that they
Re: Python 3 is killing Python
Kevin Walzer writes: > I can only think of two widely used languages in the last decade where > there was this type of major break in binary compatibility: Perl and > Visual Basic. Lua 5.1, 5.2 and 5.3 are all incompatible to some extent. It's debatable how widely used Lua is as a stand-alone language, but the usage is pretty widespread; it's just mostly concealed inside another application. -- /Wegge Leder efter redundant peering af dk.*,linux.debian.* -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 2014-07-15 13:19, alister wrote: Image, for a moment, a world WITHOUT the great USA! Yes, i know you little commies love to curse the USA, and yes, there are many dark sins committed within AND beyond her borders, but try to tell me you bass-turds, what nation in modern history has contributed more technological achievements [1] The one you revolted from. The Same one that is your first port of call for assistance whenever you get yourselves involved in conflict. I think you will find that more inventions have originated on this desolate windswept island of the north coast of Europe than the USA. I'd say it's more north-west than north. We are called Great Britain, the clue is in the name. "Great Britain" is the name of the largest island in the "British Isles". -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 15/07/2014 13:32, Anders J. Munch wrote: By the way, which list is the appropriate one? The numpy and SciPy mailing lists are first and foremost about numpy and SciPy, I presume. Is there a general numerics-list somewhere also? I don't see any on https://mail.python.org/mailman/listinfo. Try here http://news.gmane.org/index.php?prefix=gmane.comp.python -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 13:19, alister wrote: Image, for a moment, a world WITHOUT the great USA! Yes, i know you little commies love to curse the USA, and yes, there are many dark sins committed within AND beyond her borders, but try to tell me you bass-turds, what nation in modern history has contributed more technological achievements [1] I think you will find that more inventions have originated on this desolate windswept island of the north coast of Europe than the USA. Like the technology that was used to break the sound barrier? Handed to the Yanks in a deal that they promptly broke but refused to hand the technology back. Special relationship, yep, they were kind enough to give us 60 years to pay off the loans we took out during WWII. As Aurthur Daley used to say "nice little earner". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 15:31, Chris Angelico wrote: On Tue, Jul 15, 2014 at 11:57 PM, Kevin Walzer wrote: I've stayed with Python 2.7 because I've seen no benefit in 3.x that outweighs the hassle of going through my code line by line to make it compatible. And that's fine! The python-dev team has promised that 2.7 will continue to be supported; that means some headaches, especially on Windows (the Python 2.7 support will long outlast upstream Microsoft support for the compiler it's built on), but it's a promise that you can continue to run your 2.7 code. That said, though, I would advise you to give 2to3 a shot. You never know, it might do exactly what you need right out-of-the-box and give you a 3.x-compatible codebase in one hit. Or any one of https://pypi.python.org/pypi/six/1.7.3 https://github.com/mitsuhiko/python-modernize http://python-future.org/ https://github.com/nandoflorestan/nine -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 2014-07-15, Kevin Walzer wrote: > I think it's more than a tempest in a teacup. > > The number of language revisions that result in deliberate, code-level > incompatibility out there is pretty small. People rightly expect that > code written for version 2.x of a language will continue to work with > version 3.x, even if 3.x is designed to go in another direction. I disagree. I don't expect backwards compatability across major version number changes. I've been doing software development for 30 years, and that has always been a pretty common rule for the projects I've worked on. -- Grant Edwards grant.b.edwardsYow! I feel partially at hydrogenated! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 1:44 AM, Mark Lawrence wrote: > Or any one of > > https://pypi.python.org/pypi/six/1.7.3 > https://github.com/mitsuhiko/python-modernize > http://python-future.org/ > https://github.com/nandoflorestan/nine AIUI most of those sorts of things are designed for people maintaining a dual-version codebase, not for making a one-time switch. But yes, there are a variety of tools to help make the changes necessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, 15 Jul 2014 15:50:46 +0100, MRAB wrote: > On 2014-07-15 13:19, alister wrote: >>> >>> Image, for a moment, a world WITHOUT the great USA! Yes, i know you >>> little commies love to curse the USA, and yes, there are many dark >>> sins committed within AND beyond her borders, but try to tell me you >>> bass-turds, what nation in modern history has contributed more >>> technological achievements [1] >> >> The one you revolted from. The Same one that is your first port of call >> for assistance whenever you get yourselves involved in conflict. >> >> I think you will find that more inventions have originated on this >> desolate windswept island of the north coast of Europe than the USA. >> > I'd say it's more north-west than north. Doesn't roll of the tongue as well though > >> We are called Great Britain, the clue is in the name. >> > "Great Britain" is the name of the largest island in the "British > Isles". Never let the facts get in the way of a good punchline :-) -- The one day you'd sell your soul for something, souls are a glut. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Chris Angelico : > Fine. Tell me how you would go about adding true Unicode support to > Python 2.7, while still having it able to import an unchanged program. > Trick question - it's fundamentally impossible, because an unchanged > program will not distinguish between bytes and text, but true Unicode > support requires that they be distinguished. Python 2 has always had unicode strings and [byte] strings. They were always clearly distinguished. You really didn't have to change anything for "true Unicode support". > you may as well go straight to Py3 and take advantage of its features. The first real new feature in Python 3 is asyncio. I've been perfectly happy with select.epoll myself and written my own 50-line asyncio equivalents so it remains to be seen how much traction asyncio will have. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tuesday, July 15, 2014 9:31:31 AM UTC-5, Chris Angelico wrote: > [...] That said, though, I would advise you to give 2to3 a > shot. You never know, it might do exactly what you need > right out-of-the-box and give you a 3.x-compatible > codebase in one hit. Ha! Are you so foolish as to believe that if code runs cleanly *immediately* after translating via "2to3", that the code is now completely free from translation bugs? You act as if 2to3 is some "magical" code that can root out every bug no matter how subtle. No, for those of us who care about our reputation, we are not about to release code that could blow chunks and leave egg all over our face, or worse, cause us to loose a contract! > Ultimately, the solution is simply to keep Python 2.7 > around for a good long time, until the carrot of new Py3 > features becomes attractive enough for it to be worth > switching. And if that's not before 2020, no problem. Even > if it's after 2020, there's a fair chance that you'll > still be able to run your 2.7 code - So in other words, "we're" know now we made a bad decision by creating this Python3000 thing, because nobody seems to be jumping on the bandwagon, but instead of admitting we were wrong, we'll just cling to our new shiny *THING* and hope *EVENTUALLY*, if we brow-beat *ENOUGH* people, that well, *MAYBE* most of them will embrace this *ABORTION* and join us. > it's just that there's no promise (at the moment) of > patches, even security patches, from python.org. Oh yes, i see... when brow-beating does not work, we adopt the malevolent tactics of $MS and $OS by allowing security holes and virus infections to riddle the code base obsolete. COME AND GET THE NEXT NEW SHINY RATTLE YOU INFANTS! MEET THE NEW RATTLE... SAME AS THE OLD RATTLE... i pray we don't get fooled again! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Rick Johnson : > So in other words, "we're" know now we made a bad decision by creating > this Python3000 thing, because nobody seems to be jumping on the > bandwagon, but instead of admitting we were wrong, we'll just cling to > our new shiny *THING* and hope *EVENTUALLY*, if we brow-beat *ENOUGH* > people, that well, *MAYBE* most of them will embrace this *ABORTION* > and join us. I agree it was a grave mistake. However, what's done is done. Instead of fighting it or defending it, just cope with it and move on. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 2014-07-15, alister wrote: > Never let the facts get in the way of a good punchline :-) Ah! That explains it! The Iraq war must have been a _joke_. It sure went over my head... -- Grant Edwards grant.b.edwardsYow! My Aunt MAUREEN was a at military advisor to IKE & gmail.comTINA TURNER!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, Jul 15, 2014 at 12:01 PM, Rick Johnson wrote: > On Tuesday, July 15, 2014 9:31:31 AM UTC-5, Chris Angelico wrote: >> [...] That said, though, I would advise you to give 2to3 a >> shot. You never know, it might do exactly what you need >> right out-of-the-box and give you a 3.x-compatible >> codebase in one hit. > > Ha! > > Are you so foolish as to believe that if code runs cleanly > *immediately* after translating via "2to3", that the code is > now completely free from translation bugs? > > You act as if 2to3 is some "magical" code that can root out > every bug no matter how subtle. No, for those of us who care > about our reputation, we are not about to release code that > could blow chunks and leave egg all over our face, or worse, > cause us to loose a contract! This is what tests are for: so you know whether your code is working or not. 1) Run 2to3. 2) Run your test suite. 3) If there's a UI, exercise it manually. At that point you should know how many things you need to fix. If that number is 0, then you're basically ready to release (depending on your test coverage and your release cycle and your overall level of comfort with releasing the result). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, 15 Jul 2014 11:01:53 -0700, Rick Johnson wrote: > Are you so foolish as to believe that if code runs cleanly *immediately* > after translating via "2to3", that the code is now completely free from > translation bugs? If your code has a thorough set of unittests that continue to pass, then changes are better than excellent that it is free of translation bugs. > You act as if 2to3 is some "magical" code that can root out every bug no > matter how subtle. Of course not. 2to3 certainly won't remove bugs that already exist in your code. It will happily translate them to version 3 dialect for you, so you can have the fun of fixing them yourself. [...snip foolish grandstanding...] >> Ultimately, the solution is simply to keep Python 2.7 around for a good >> long time, until the carrot of new Py3 features becomes attractive >> enough for it to be worth switching. And if that's not before 2020, no >> problem. Even if it's after 2020, there's a fair chance that you'll >> still be able to run your 2.7 code - > > So in other words, "we're" know now we made a bad decision by creating > this Python3000 thing, because nobody seems to be jumping on the > bandwagon, Don't be childish. There are still people using Python 2.3. There are even a few people -- just a handful -- happily using Python 1.5, which is probably older than you. People have all sorts of reasons for sticking to what works, instead of jumping from version to version and having to deal with code churn every 18 months. And they have the right to do so. No adult expect them to upgrade just because there is a new version out. Redhat still offers commercial support for Python 2.4. I believe that Python 2.3 has only *just* come out of commercial support a few months ago. Some people will upgrade, some are happy to keep using a product that works, and require no support. The choice is theirs. The same will apply to Python 2.7. The Python developers have promised to give 2.7 extended support until 2020, and Red Hat has committed to extended commercial support until 2023. Capitalism at work: Red Hat expects to be able to make money from supporting this for nearly another decade, and good on them. [...snip childish insults...] >> it's just that there's no promise (at the moment) of patches, even >> security patches, from python.org. > > Oh yes, i see... when brow-beating does not work, we adopt the > malevolent tactics of $MS and $OS by allowing security holes and virus > infections to riddle the code base obsolete. No software developer is obliged to support their software forever, especially if they are giving it away for free, and writing it out of love. Nobody but nobody is supporting Python 1.1 any more, no matter how many security holes it has. So what? Who cares? Python 2.7 is open source software, if you think that there is a market for providing support for it for the next twenty years, go right ahead. You can even charge money for it. But of course you won't. Because it's much easier to bitch and moan and pretend to be oh-so-superior than to actually write code, fix bugs, and provide support. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, 15 Jul 2014 21:08:03 +0300, Marko Rauhamaa wrote: > I agree it was a grave mistake. On what basis do you believe it was a mistake? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, 15 Jul 2014 20:38:40 +0300, Marko Rauhamaa wrote: > Python 2 has always had unicode strings and [byte] strings. They were > always clearly distinguished. You really didn't have to change anything > for "true Unicode support". If that were true, then migrating from Python 2 to 3 would be much simpler than it is. Unicode strings in Python 2 are second class entities. It's not just that people will, in general, take the lazy way and write "foo" instead of u"foo" for their strings. But it is that the whole Python virtual machine is based on byte-strings, not Unicode strings, and u"" strings are bolted on top. [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" 4.141 [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)" File "", line 1 π = 3.14; print(π+1) ^ SyntaxError: invalid syntax Python 2 "helpfully" tries to guess what you want when you work with bytes-pretending-to-be-strings, and when it guesses right, it's nice, but when it guesses wrongly, you'll left with mysterious encoding and decoding errors from code that don't appear to involve either. The whole thing is a mess. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Steven D'Aprano : > On Tue, 15 Jul 2014 21:08:03 +0300, Marko Rauhamaa wrote: > >> I agree it was a grave mistake. > > On what basis do you believe it was a mistake? The supposed flaws in Python 2 weren't a good enough reason to break backward-compatibility. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Steven D'Aprano : > Unicode strings in Python 2 are second class entities. I don't see that. They form a type just like, say, complex. > It's not just that people will, in general, take the lazy way and > write "foo" instead of u"foo" for their strings. People live with their choices, and I don't see the consequences of that lazy way as very bad. In fact, I find the lazy use of Unicode strings at least as scary as the lazy use of byte strings, especially since Python 3 sneaks Unicode to the outer interfaces of the program (files, IPC). > But it is that the whole Python virtual machine is based on > byte-strings, not Unicode strings, and u"" strings are bolted on top. The internal implementation of the VM is free to change as long as the external semantics stay the same. > [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" > 4.141 > [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)" > File "", line 1 > π = 3.14; print(π+1) > ^ > SyntaxError: invalid syntax My native language uses ä and ö, but I don't see any pressing need to embed those characters in identifiers. > Python 2 "helpfully" tries to guess what you want when you work with > bytes-pretending-to-be-strings, and when it guesses right, it's nice, but > when it guesses wrongly, you'll left with mysterious encoding and > decoding errors from code that don't appear to involve either. The whole > thing is a mess. I can't think of a matching example. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 18:38, Marko Rauhamaa wrote: Chris Angelico : Fine. Tell me how you would go about adding true Unicode support to Python 2.7, while still having it able to import an unchanged program. Trick question - it's fundamentally impossible, because an unchanged program will not distinguish between bytes and text, but true Unicode support requires that they be distinguished. Python 2 has always had unicode strings and [byte] strings. They were always clearly distinguished. You really didn't have to change anything for "true Unicode support". That is the funniest tongue in cheek comment I've read in the 10+ years I''ve been hanging around here. It was tongue in cheek, wasn't it? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tuesday, July 15, 2014 1:53:27 PM UTC-5, Steven D'Aprano wrote:
> No software developer is obliged to support their software
> forever, especially if they are giving it away for free
> [...] Nobody but nobody is supporting Python 1.1 any more,
> no matter how many security holes it has.
Of course not, Python 1.1 is pre-1999, heck, it's so old i
cannot find a release date for it, and it's probably
completely useless in today's world
BUT THAT IS NOT MY POINT!
What you fail to realize is that the *MAJORITY* of Python
programmers cut their teeth on the Python 2.x line, and as
such, the majority of today's Python programmers are still
using the Python 2.x line -- anything to with Python 1.1
might as well be ancient history, it's irrelevant due to age
and it's abysmal utilization.
Python's popularity started increasing significantly only
*AFTER* Python 2 was rolled out. If you look at the TIOBE
stats (2003-2013), Python made the *MOST* improvements in
the years of 2007 and 2013
PYTHON-2.0.1 WAS RELEASED ON JUNE 22, 2001
But nothing *significant* happened until Python-2.5
PYTHON-2.5.0 WAS RELEASED ON SEPT. 19, 2006
Which coincides with the spike of 2007!
Now begs the question, what caused the 2013 spike? Simple,
the 2013 spike was a result of all the *BUZZ* of Python-3000,
NOT *BECAUSE* OF PYTHON-3000, but, because of the *BUZZ*.
Remember, GvR went on an extensive campaign to sale this
"new and improved" snake oil, with all his Google speeches
and evangelizing and whatnot. But very quickly the
"curiosity" and "excitement" turned into the "summer of
discontent".
I remember watching some speeches where the audience was not
at all pleased with the breaks and "great new
functionality".
The blogisphere has been set ablaze with bemoaning of
breaking code over such "miniscule" things as lazy
iterators, print, input,etc... and the misguided attempts to
"sanitize" Python of functional programming!
SHOULD I DRAW YOU A "MAP"?
I think we can all agree that the roll out of Python3 was
not as "smooth" as the dictator has expected
Also, keep in mind that most of the tutorials and books out
there are written for Python 2.x, whereas Python 3.x is very
limited[1]. Too many noobs have downloaded Python3 and
whilst unwittingly following a "Googled tutorial" or book,
get hammered with esoteric exception messages and then
quickly give up and move on to another language, unaware
that the versions are incompatible in many respects.
Kind of sad when you realize that most of the functions that
were broken are the same functions a noob is using during "day
one" (print, input, etc...)
2.x also has years and years of *MATURE* third party modules
for the taking, whereas Python 3.x is quite disappointing[1].
> Python 2.7 is open source software, if you think that
> there is a market for providing support for it for the
> next twenty years, go right ahead
There *WILL* be a market for Python for the next ten or so
years no matter what happens to Python3! Since the vast
majority of Python code (in the wild) is written in the 2.x
line (most likely written using Python-2.5), python-3000 was
a lame duck before it was even released!
print("QUACK!")
[1]: yes, yes, i know there are 3.x resources but no where even
close to 2.x!
--
https://mail.python.org/mailman/listinfo/python-list
multiprocessing problem: queue.get() not finding pushed values
I don't think I can reduce it much beyond this. I'm trying to run
Sqlite in a separate process, but I'm running into problems.
*The code:*
from collectionsimportnamedtuple
from multiprocessing import Process, Queue, current_process
from queue import Empty, Full
Msg=namedtuple ("Msg", ['act', 'id', 'vals'])
DBW_to=Queue()
DBW_from=Queue()
class DBW (Process):
def __init__ (self, qin, qout):
self.qin=qin
self.qout=qout
super (DBW, self).__init__()
def run (self):
msg=self.qin.get(True, 3)
print ("msg = {0}".format(repr(msg) ) )
if __name__ == "__main__":
dbw=DBW(DBW_to, DBW_from)
dbw.run()
DBW_to.put(Msg("a", 1, wrd) )
DBW_to.put(Msg("b", 2, wrd) )
DBW_to.put(Msg("c", 0, None) )
*The result:*
Traceback (most recent call last):
File "test7a.py", line 23, in
dbw.run()
File "test7a.py", line 18, in run
msg=self.qin.get(True, 3)
File "/usr/lib/python3.4/multiprocessing/queues.py", line 107, in get
raise Empty
queue.Empty
*$ python3 --version*
Python 3.4.1
*The system:*
Linux 3.14-1-amd64
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence wrote: > On 15/07/2014 18:38, Marko Rauhamaa wrote: >> >> Chris Angelico : >> >>> Fine. Tell me how you would go about adding true Unicode support to >>> Python 2.7, while still having it able to import an unchanged program. >>> Trick question - it's fundamentally impossible, because an unchanged >>> program will not distinguish between bytes and text, but true Unicode >>> support requires that they be distinguished. >> >> >> Python 2 has always had unicode strings and [byte] strings. They were >> always clearly distinguished. You really didn't have to change anything >> for "true Unicode support". >> > > That is the funniest tongue in cheek comment I've read in the 10+ years > I''ve been hanging around here. It was tongue in cheek, wasn't it? What isn't "true" about Python 2.x's unicode support? The only feature I ever missed was case folding. (Not that 3.x does much better at that... :) The stdlib had poor unicode support, if that's what you mean. That could've been fixed without introducing backwards-incompatible changes, though. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, Jul 15, 2014 at 2:20 PM, Rick Johnson wrote: > On Tuesday, July 15, 2014 1:53:27 PM UTC-5, Steven D'Aprano wrote: > >> No software developer is obliged to support their software >> forever, especially if they are giving it away for free >> [...] Nobody but nobody is supporting Python 1.1 any more, >> no matter how many security holes it has. > > Of course not, Python 1.1 is pre-1999, heck, it's so old i > cannot find a release date for it, and it's probably > completely useless in today's world > > BUT THAT IS NOT MY POINT! > > What you fail to realize is that the *MAJORITY* of Python > programmers cut their teeth on the Python 2.x line, and as > such, the majority of today's Python programmers are still > using the Python 2.x line -- anything to with Python 1.1 > might as well be ancient history, it's irrelevant due to age > and it's abysmal utilization. When Python 2.0 was released, the majority of Python programmers at the time had learned on Python 1.x, and for a while the majority of them were still using 1.x. That's the same situation you're describing today. At some point in the future, Python 2.x will be "ancient history" also. > Python's popularity started increasing significantly only > *AFTER* Python 2 was rolled out. If you look at the TIOBE > stats (2003-2013), Python made the *MOST* improvements in > the years of 2007 and 2013 > > PYTHON-2.0.1 WAS RELEASED ON JUNE 22, 2001 > > But nothing *significant* happened until Python-2.5 Seriously? If you ask me, the changes introduced in 2.2 were a lot more significant than anything in 2.5. 2.2 fixed the type system by giving us new-style classes. It also added the iterator interface, introduced generators, and removed the distinction between int and long. All of those things were huge. What did Python 2.5 add? Conditional expressions and the with statement, both of which are useful but not nearly as compelling. > Now begs the question, what caused the 2013 spike? Simple, > the 2013 spike was a result of all the *BUZZ* of Python-3000, > NOT *BECAUSE* OF PYTHON-3000, but, because of the *BUZZ*. Python 3.0 was released in 2008. I don't understand why you think the buzz surrounding that would have occurred 5 years later. > Remember, GvR went on an extensive campaign to sale this > "new and improved" snake oil, with all his Google speeches > and evangelizing and whatnot. But very quickly the > "curiosity" and "excitement" turned into the "summer of > discontent". No, I have no idea what you're referring to. If Guido was talking more about Python 3 in 2012 than at any time in the six years prior, then I for one didn't notice. > [1]: yes, yes, i know there are 3.x resources but no where even > close to 2.x! Actually, the Wall of Superpowers is showing quite a lot of green these days. https://python3wos.appspot.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Annd I just saw that the lifetime has been pushed up to 2020 :) #SelfCorrected On Wed, Jul 16, 2014 at 3:05 AM, Abhiram R wrote: > Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported > only until 2015 :-| So...you know.. you have like an year before you *do *have > to migrate to 3.x . > > > On Wed, Jul 16, 2014 at 2:17 AM, Devin Jeanpierre > wrote: > >> On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence >> wrote: >> > On 15/07/2014 18:38, Marko Rauhamaa wrote: >> >> >> >> Chris Angelico : >> >> >> >>> Fine. Tell me how you would go about adding true Unicode support to >> >>> Python 2.7, while still having it able to import an unchanged program. >> >>> Trick question - it's fundamentally impossible, because an unchanged >> >>> program will not distinguish between bytes and text, but true Unicode >> >>> support requires that they be distinguished. >> >> >> >> >> >> Python 2 has always had unicode strings and [byte] strings. They were >> >> always clearly distinguished. You really didn't have to change anything >> >> for "true Unicode support". >> >> >> > >> > That is the funniest tongue in cheek comment I've read in the 10+ years >> > I''ve been hanging around here. It was tongue in cheek, wasn't it? >> >> What isn't "true" about Python 2.x's unicode support? The only feature >> I ever missed was case folding. (Not that 3.x does much better at that... >> :) >> >> The stdlib had poor unicode support, if that's what you mean. That >> could've been fixed without introducing backwards-incompatible >> changes, though. >> >> -- Devin >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > > > > -- > Abhiram.R > M.Tech CSE (Sem 3) > RVCE > Bangalore > -- Abhiram.R M.Tech CSE (Sem 3) RVCE Bangalore -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported only until 2015 :-| So...you know.. you have like an year before you *do *have to migrate to 3.x . On Wed, Jul 16, 2014 at 2:17 AM, Devin Jeanpierre wrote: > On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence > wrote: > > On 15/07/2014 18:38, Marko Rauhamaa wrote: > >> > >> Chris Angelico : > >> > >>> Fine. Tell me how you would go about adding true Unicode support to > >>> Python 2.7, while still having it able to import an unchanged program. > >>> Trick question - it's fundamentally impossible, because an unchanged > >>> program will not distinguish between bytes and text, but true Unicode > >>> support requires that they be distinguished. > >> > >> > >> Python 2 has always had unicode strings and [byte] strings. They were > >> always clearly distinguished. You really didn't have to change anything > >> for "true Unicode support". > >> > > > > That is the funniest tongue in cheek comment I've read in the 10+ years > > I''ve been hanging around here. It was tongue in cheek, wasn't it? > > What isn't "true" about Python 2.x's unicode support? The only feature > I ever missed was case folding. (Not that 3.x does much better at that... > :) > > The stdlib had poor unicode support, if that's what you mean. That > could've been fixed without introducing backwards-incompatible > changes, though. > > -- Devin > -- > https://mail.python.org/mailman/listinfo/python-list > -- Abhiram.R M.Tech CSE (Sem 3) RVCE Bangalore -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 22:35, Abhiram R wrote: Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported only until 2015 :-| So...you know.. you have like an year before you /do /have to migrate to 3.x . -- Abhiram.R M.Tech CSE (Sem 3) RVCE Bangalore a) please don't top post, this is almost as heinous a crime as using the infamous google groups b) complete nonsense, it's actually 2020 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
a) What is "top post"? b)I did correct myself in the next post. Or maybe you missed that. On Wed, Jul 16, 2014 at 3:19 AM, Mark Lawrence wrote: > On 15/07/2014 22:35, Abhiram R wrote: > >> Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported >> only until 2015 :-| So...you know.. you have like an year before you /do >> /have to migrate to 3.x . >> >> -- >> Abhiram.R >> M.Tech CSE (Sem 3) >> RVCE >> Bangalore >> >> >> > a) please don't top post, this is almost as heinous a crime as using the > infamous google groups > b) complete nonsense, it's actually 2020 > > > -- > My fellow Pythonistas, ask not what our language can do for you, ask what > you can do for our language. > > Mark Lawrence > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Abhiram.R -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
"Top posting" is the practice of responding to an e-mail thread by putting your response at the top of the text you are quoting. It's standard practice in the corporate world... On 7/15/14, 6:13 PM, Abhiram R wrote: a) What is "top post"? ...but Unix/newsgroup ettiquette says that it's gauche to do this, because it presents an unacceptable cognitive burden to the user trying to catch the context of the thread by forcing them to read your reply first, before they read the preceding quoted comments. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15/07/2014 23:13, Abhiram R wrote: a) What is "top post"? b)I did correct myself in the next post. Or maybe you missed that. On Wed, Jul 16, 2014 at 3:19 AM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote: On 15/07/2014 22:35, Abhiram R wrote: Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported only until 2015 :-| So...you know.. you have like an year before you /do /have to migrate to 3.x . -- Abhiram.R M.Tech CSE (Sem 3) RVCE Bangalore a) please don't top post, this is almost as heinous a crime as using the infamous google groups b) complete nonsense, it's actually 2020 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- Top posting is the extremely annoying habit of replying to a message at the top instead of at the bottom as I'm doing here, or interspersing your answers in with the related paragraphs. I did see your correction but it gave me an opportunity to mention google groups, something that just can't be missed :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 4:00 AM, Kevin Walzer wrote: > "Top posting" is the practice of responding to an e-mail thread by putting > your response at the top of the text you are quoting. It's standard > practice in the corporate world... > > On 7/15/14, 6:13 PM, Abhiram R wrote: > >> a) What is "top post"? >> > > ...but Unix/newsgroup ettiquette says that it's gauche to do this, > because it presents an unacceptable cognitive burden to the user trying to > catch the context of the thread by forcing them to read your reply first, > before they read the preceding quoted comments. > > > --Kevin > -- > Kevin Walzer > Code by Kevin/Mobile Code by Kevin > http://www.codebykevin.com > http://www.wtmobilesoftware.com > -- > https://mail.python.org/mailman/listinfo/python-list > Aah. Understood. Apologies for the "noobishness" :) - Abhiram.R -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 15 July 2014 23:40, Abhiram R wrote: > On Wed, Jul 16, 2014 at 4:00 AM, Kevin Walzer wrote: >> >> ...but Unix/newsgroup ettiquette says that it's gauche to [top post], >> because it presents an unacceptable cognitive burden to the user trying to >> catch the context of the thread by forcing them to read your reply first, >> before they read the preceding quoted comments. > > Aah. Understood. Apologies for the "noobishness" :) Also heinous is the crime of not trimming. A post should contain all of the context needed to understand the reply, in order, and nothing more. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote: > [snip excessive quotations] > Aah. Understood. Apologies for the "noobishness" :) Noobishness can be tolerated for a "reasonable" time, especially when the "noob" actively seeks to improve his skills, as you are doing, so kudos to you. The next skill to learn, after NOT top posting, is the art of trimming quotations to the most relevant bits. You'll have to use your own judgment for most quoted text, however, if nothing else, be sure to remove any links to the quoted persons web site or blog, and any "famous quotes". Some folks even have software that "blabs" about how great a job it is doing protecting the posters computer (like we really care!), so if you see any taglines that mention "this is a virus free message" (oh thanks, now i can sleep at night!), or some pretentious line about "this was sent from my i-phone" -- send that crap to the bitbucket! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/15/14, 6:38 PM, Mark Lawrence wrote: I did see your correction but it gave me an opportunity to mention google groups, something that just can't be missed If the newgroup had a filter to trim out complaints about Google groups, half the traffic would be gone. :-) -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 2014-07-16 00:53, Rick Johnson wrote: On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote: [snip excessive quotations] Aah. Understood. Apologies for the "noobishness" :) Noobishness can be tolerated for a "reasonable" time, especially when the "noob" actively seeks to improve his skills, as you are doing, so kudos to you. The next skill to learn, after NOT top posting, is the art of trimming quotations to the most relevant bits. You'll have to use your own judgment for most quoted text, however, if nothing else, be sure to remove any links to the quoted persons web site or blog, and any "famous quotes". Some folks even have software that "blabs" about how great a job it is doing protecting the posters computer (like we really care!), so if you see any taglines that mention "this is a virus free message" (oh thanks, now i can sleep at night!), or some pretentious line about "this was sent from my i-phone" -- send that crap to the bitbucket! "This was sent from my iPhone" == "I have an iPhone!" Also annoying is some footnote that says that the email contains confidential information and that if you're not the intended recipient you should delete it, etc. That's somewhat pointless if it's being sent to a public forum! -- https://mail.python.org/mailman/listinfo/python-list
Mac python py2app problem
Hey i have made an app and i have made a .msi for windows with py2exe and i have also exported it with py2app on mac. No problems here they all work fine. I then put the .msi on sourceforge and it works great but when i put the .app on there and download it it says something like i can open this on old architecture or something so i have to put it through google drive and i dont like this like i share the link and folder and people can download it there but it is dodgy. Could someone please help me out like if there is a .msi type thing for mac with py2exe? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, 16 Jul 2014 03:07:23 +0530, Abhiram R wrote about Python 2.7: > Annd I just saw that the lifetime has been pushed up to 2020 :) > #SelfCorrected Even when free support runs out, commercial support will be available. Red Hat is already committed to supporting Python 2.7 until 2023, and if there really is demand, nothing stops people or companies supporting it for the next 30 years. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac python py2app problem
On 7/15/14, 9:56 PM, Nicholas Cannon wrote: Hey i have made an app and i have made a .msi for windows with py2exe and i have also exported it with py2app on mac. No problems here they all work fine. I then put the .msi on sourceforge and it works great but when i put the .app on there and download it it says something like i can open this on old architecture or something so i have to put it through google drive and i dont like this like i share the link and folder and people can download it there but it is dodgy. Could someone please help me out like if there is a .msi type thing for mac with py2exe? It's hard to make sense of what you are asking for. Can you just zip up the app bundle that py2app produces and upload it that way? That works for many developers. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Twitter Client on Terminal by Python
On Tuesday, July 15, 2014 5:36:40 AM UTC+9, Terry Reedy wrote: > On 7/13/2014 11:51 PM, Chris Angelico wrote: > > > On Mon, Jul 14, 2014 at 12:18 PM, Orakaro wrote: > > >> I use README.md for Github and README.rst for PyPi. Is there a way to use > >> only one file for both sites ? > > > > > > Ah. I don't know; check the docs for one or the other and see what they'll > > do. > > > > > >> I tested my package on Python 2.7 and Python 3.4 But do I have to install > >> all Python 2.6, Python 3.* in my system and test in all environment for > >> sure ? > > > > You don't *have* do anything for free. However, if your package works on > > 2.7 and 3.4, it *probably* works as is for 3.2 and 3.3. On Windows at > > least, installing multiple versions is trivial (5 minutes for each). > > > > The more important issue, I think, is what system you have tested on. Up > > to 3.2, including all 2.x, Python had 'wide' and 'narrow' unicode > > builds. On narrow builds (Windows, some *nix), astral (non-BMP) chars > > count as 2. Given Twitter's 140 char limitation, this bug (solved in > > 3.3) could affect a Twitter client by giving the length of a 140 char > > tweet as more than 140 chars. > > > > > You can state that it supports 2.7 and 3.4, without testing on any > > > other versions. Those are the two current versions - my example was > > > showing support for more than just the one latest, but that was just > > > an example, nothing more. When Python 3.5 comes out, you'll probably > > > want to test on that (and then say "supports 2.7 and 3.4+"), but at > > > the moment, "2.7 and 3.4" is fine. If people want to use this with, > > > say, 3.3, then they're welcome to try, but they'll know not to presume > > > that it'll work. > > > > Even if you test on, say, 2.6, it is up to you whether you want to > > 'support' 2.6 with bugfixes, in case a patch for 2.7 does not work on 2.6. > > > > -- > > Terry Jan Reedy Hi Terry. Thanks so much for pointing all this out. I didn't know anything about the unicode builds problem. Will try to reproduce this bug even for self-learning purpose. By the way, I tested this app on Mac OSX and only one Linux distro (CentOS 5). Maybe Window is next. Regards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Twitter Client on Terminal by Python
On Tuesday, July 15, 2014 3:27:15 PM UTC+9, Omar Abou Mrad wrote: > Dear Orakaro, > > > Cool app you have there. Please consider the following comments as feedback > in the most positive sense possible: > > > - I didn't care for the figlet, it's noise beyond anything else, if you drop > it, you would drop the pyfiglet dependency as well > > - What's with the SQLAlchemy dependency? I checked your table definitions and > if I'm not mistaken all you're using is Theme, Message, Tweet. My first > question on that front is why are message and tweet stored locally? Are you > doing local caching to speed things up? What about theme? > > > > Good job and take care! > > > Regards, > > > Omar > > > > On Sun, Jul 13, 2014 at 9:00 PM, Orakaro wrote: > > Hello! > > > > I'm @dtvd88 on Twitter and very new here. > > I read from python.org that anything Python-related can be discussed, and not > sure if I can share my OSS package here to get feedback or not ? > > > > I just wrote a Twitter Client on Terminal by Python, it has very beautiful > display and even can display image on terminal. Check it out and maybe you > guys will love it :) > > > > Homepage: http://www.rainbowstream.org/ > > Github: https://github.com/DTVD/rainbowstream > > > > Thanks for any feedback and sorry if this kind of topics is not tolerated > here. > > -- > > https://mail.python.org/mailman/listinfo/python-list Hi Omar. Thanks about the feedback. - The ascii art character... seems interesting to some people and not to others. Maybe I should add a config option for ignoring it. - I used 2 python process, ones handle the streaming API, ones listens to user's input as well as executes REST API and they need to share some variables. After tried ctypes, SyncManage or Queue, I found out that a database solution is easier and less buggy. So SQLAlchemy exists. - I only store Tweet and Message ID (not the content) locally and delete all when program exit. The reason is Twitter API's Tweet/Message ID is too long for user to type a command like "rep 489242568104095234 also like it!". In DB Tweet/Message ID is a small number which map 1-by-1 to the "real" Tweet/Message ID. - 2 process need to know the new theme when user type a command to change their current theme. So Theme exists in DB. Sorry for the long reply. Hope that there is a smarter solution and thanks very much again Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 5:23 AM, Rick Johnson wrote: > On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote: > > [snip excessive quotations] > > Aah. Understood. Apologies for the "noobishness" :) > > Noobishness can be tolerated for a "reasonable" time, > especially when the "noob" actively seeks to improve his > skills, as you are doing, so kudos to you. Thank you Rick :) > The next skill to learn, after NOT top posting, is the art > of trimming quotations to the most relevant bits. You'll > have to use your own judgment for most quoted text, however, > if nothing else, be sure to remove any links to the quoted > persons web site or blog, and any "famous quotes". > > > Added to my TIL-list :D > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Abhiram.R -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : > >> Unicode strings in Python 2 are second class entities. > > I don't see that. They form a type just like, say, complex. I didn't say they were a second class type. I choose my words carefully, although I guess what I was trying to get across may have been a bit subtle, sorry about that. But if you read on, where I explain some of the consequences, it should be clear: Python 2.x has the assumption that strings are 8-bit deeply embedded in the compiler. >> It's not just that people will, in general, take the lazy way and write >> "foo" instead of u"foo" for their strings. > > People live with their choices, and I don't see the consequences of that > lazy way as very bad. The consequences are that it is too hard to write correct text handling code in Python 2, and too many programs which assume that text=ASCII as if it were 1965. In the same way that a language like Python is supposed to make it hard for programmers (good, lazy or careless programmers) to write code with (say) buffer overflow bugs, so a language like Python is supposed to make it hard for programmers to write code that assumes that text is 8-bit. It is disgraceful that in 2014 there are still languages like PHP that don't know how to handle text, and Python fortunately is not one of them. > In fact, I find the lazy use of Unicode strings at least as scary as the > lazy use of byte strings, especially since Python 3 sneaks Unicode to > the outer interfaces of the program (files, IPC). I'm not entirely sure I understand what you mean by "lazy use of Unicode strings". And I especially don't understand what you mean by "sneak". The fact that strings are Unicode is *the* biggest and most obvious new feature of Python 3. >> But it is that the whole Python virtual machine is based on >> byte-strings, not Unicode strings, and u"" strings are bolted on top. > > The internal implementation of the VM is free to change as long as the > external semantics stay the same. Which is the whole point. *They cannot*, or at least not without a level of effort far beyond what is reasonable for an all-volunteer effort. And even if they could, why bother when most developers will then ignore that and use "" byte strings because it saves one character typing? The Python devs aren't slaves, they get to choose what features they work on and which they don't. They don't owe *anybody* any feature they don't want to build, or care to support, and that includes continuing the 2.x series. That leaves you with choices: - You can follow the lead of the core developers and migrate to 3.x in your own time, when it works for you. - You can get enough people on the PSF board, and enough trusted, core developers, that the old guard get pushed out and you can take over and set the direction of Python development. - You can hunker down and stick with Python 2 forever, and do without free support after 2020. - You can stick with Python 2 until 2020, or pay for support until 2023, then reconsider the decision not to migrate. - You can fork Python and take over support of MyPython 2.7. - Or you can port your code to another language. Perhaps the *stupidest* thing the author of the "Python 3 is killing Python" blog post wrote was that it's easier to port Python code to a *completely different language*. I cannot fathom the idiocy of somebody who bitches and moans that having to re-write or redesign, oh, let's conservatively say 5% of your Python 2 code is harder than writing your code *completely from scratch* in a completely different language, with completely different third party libraries. And you can make that choice on a project-by-project basis. As of right now, *new* projects ought to be written in Python 3.3 or better, unless you have a compelling reason not to. You don't have to port old projects in order to take advantage of Python 3 for new projects. >> [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" 4.141 >> [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)" >> File "", line 1 >> π = 3.14; print(π+1) >> ^ >> SyntaxError: invalid syntax > > My native language uses ä and ö, but I don't see any pressing need to > embed those characters in identifiers. And good for you that you don't. I mean it. But there are 7 billion people in the world, and they're not all Python programmers, but most people are keen to program in their native tongues rather than English. >> Python 2 "helpfully" tries to guess what you want when you work with >> bytes-pretending-to-be-strings, and when it guesses right, it's nice, >> but when it guesses wrongly, you'll left with mysterious encoding and >> decoding errors from code that don't appear to involve either. The >> whole thing is a mess. > > I can't think of a matching example. [steve@ando ~]$ python2.7 -c "print u'π' + 'p'" Ïp Where did the Ï come from? [steve@ando ~]$
ISO8583
Hi,
I'm very new to python programming.
I would like to ask how come when I send ISO8583 to the server, I didn't get
any response back.
If I send it incorrect parameter, the server will reply but if I send it
correctly, the server didn't response.
The original client is in java using ISOMUX, I have been trying to use the
pyMux.py that on the ISO8583 module but didn't succeed also.
Right now i'm just using normal python socket and ISO8583 module.
The original java ISOMUX code:
ISOMUX isoMux = new ISOMUX(channel)
{
protected String getKey(ISOMsg m)
throws ISOException
{
return m.getMTI().substring(0, 2) + m.getString(32) + m.getString(12);
}
};
Could someone give me example whether python have other method similar to
ISOMUX?
Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano wrote: > Perhaps the *stupidest* thing the author of the "Python 3 is killing > Python" blog post wrote was that it's easier to port Python code to a > *completely different language*. I cannot fathom the idiocy of somebody > who bitches and moans that having to re-write or redesign, oh, let's > conservatively say 5% of your Python 2 code is harder than writing your > code *completely from scratch* in a completely different language, with > completely different third party libraries. There's only one way that it's easier to port to a completely new language. Pick another language where string handling is as naive as my last boss (who told me to make sure that my code was "eight-bit clean, that is to say, Unicode safe", and used the words "Unicode" and "UTF-8" as synonymous), and then you can continue to stick your head in the sand and pretend that ASCII is what matters, that "special characters" work because of the magic of UTF-8, and that oh, yeah, I guess we'd better occasionally test our code with a few of those annoyingly different characters, but ehh, it doesn't really matter much. Having been guilty of something like that (actually, in one program I assumed all the incoming text was CP-1252, so it really *was* byte==char), I am extremely aware of the problems that it causes. But it does make initial coding a lot easier - at the expense of debugging later, when you discover that some things don't work. The Py3 approach forces you to fix things up-front, and that's hard! But then there are no bugs. I know which one I'd rather. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing problem: queue.get() not finding pushed values
On Wed, Jul 16, 2014 at 6:32 AM, Charles Hixson
wrote:
> from queue import Empty, Full
Not sure what this is for, you never use those names (and I don't have
a 'queue' module to import from). Dropped that line. In any case, I
don't think it's your problem...
> if __name__ == "__main__":
> dbw=DBW(DBW_to, DBW_from)
> dbw.run()
> DBW_to.put(Msg("a", 1, wrd) )
> DBW_to.put(Msg("b", 2, wrd) )
> DBW_to.put(Msg("c", 0, None) )
... which is here. You're not starting a subprocess; you're simply
calling a method, so it runs synchronously. When you call .run(), it
runs the "subprocess" to completion, which then bombs because the
queue's empty, and then never gets to putting anything onto it. Change
that .run() to .start() and it'll do as you expect, except that as
part of cutting the example down you seem to have omitted the
definition of wrd. I changed that to a quoted string and it works:
# chomp unchanged code ...
if __name__ == "__main__":
dbw=DBW(DBW_to, DBW_from)
dbw.start()
DBW_to.put(Msg("a", 1, 'wrd') )
DBW_to.put(Msg("b", 2, 'wrd') )
DBW_to.put(Msg("c", 0, None) )
rosuav@sikorsky:~$ python test7a.py
msg = Msg(act='a', id=1, vals='wrd')
Hope that helps!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: ISO8583
On 07/15/2014 08:56 PM, barontro...@gmail.com wrote:
Hi,
I'm very new to python programming.
I would like to ask how come when I send ISO8583 to the server, I didn't get
any response back.
This is not really a Python question, but should rather be asked of
whoever created the ISO8583 module.
Do you know how to contact the developers of the ISO8583 package?
Gary Herron
If I send it incorrect parameter, the server will reply but if I send it
correctly, the server didn't response.
The original client is in java using ISOMUX, I have been trying to use the
pyMux.py that on the ISO8583 module but didn't succeed also.
Right now i'm just using normal python socket and ISO8583 module.
The original java ISOMUX code:
ISOMUX isoMux = new ISOMUX(channel)
{
protected String getKey(ISOMsg m)
throws ISOException
{
return m.getMTI().substring(0, 2) + m.getString(32) + m.getString(12);
}
};
Could someone give me example whether python have other method similar to
ISOMUX?
Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Steven D'Aprano : > On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote: >> In fact, I find the lazy use of Unicode strings at least as scary as >> the lazy use of byte strings, especially since Python 3 sneaks >> Unicode to the outer interfaces of the program (files, IPC). > > I'm not entirely sure I understand what you mean by "lazy use of > Unicode strings". And I especially don't understand what you mean by > "sneak". The fact that strings are Unicode is *the* biggest and most > obvious new feature of Python 3. I mean that sys.stdin and sys.stdout should deal with byte strings. I mean that open(path) should open a file in binary mode. Thankfully, the subprocess methods exchange bytes by default. To me, the main difference between Python 2 and Python 3 is that in the former, I use "..." everywhere, and in the latter, I use b"..." everywhere. If I should need advanced text processing features, I'll go through a decode() and encode(). > The Python devs aren't slaves, they get to choose what features they > work on and which they don't. They don't owe *anybody* any feature > they don't want to build, or care to support, and that includes > continuing the 2.x series. No need to erect straw men. Of course, the Python gods do whatever they want. And you asked me to clarify my opinion, which I did. The breakage of backward compatibility wasn't worth the new features. But as I said, what is done is done. We'll live with the reality. > As of right now, *new* projects ought to be written in Python 3.3 or > better, unless you have a compelling reason not to. You don't have to > port old projects in order to take advantage of Python 3 for new > projects. But my distro only provides Python 3.2. What's wrong with Python 3.2? Why didn't anybody tell me to put off the migration? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 3:52 PM, Marko Rauhamaa wrote: > Steven D'Aprano : > >> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote: >>> In fact, I find the lazy use of Unicode strings at least as scary as >>> the lazy use of byte strings, especially since Python 3 sneaks >>> Unicode to the outer interfaces of the program (files, IPC). >> >> I'm not entirely sure I understand what you mean by "lazy use of >> Unicode strings". And I especially don't understand what you mean by >> "sneak". The fact that strings are Unicode is *the* biggest and most >> obvious new feature of Python 3. > > I mean that sys.stdin and sys.stdout should deal with byte strings. I > mean that open(path) should open a file in binary mode. Thankfully, the > subprocess methods exchange bytes by default. Let's take a step back from the standard I/O streams and look at this one concept: Asking the user to enter his/her name. The user will have a name which consists of characters (at least, we hope so; cases where this is not true do exist, but are outside the scope of this discussion), not bytes. The program wants to use those characters, not bytes. If I create a window with tkinter and ask the user to enter a name, I'll get back a Unicode string: http://www.python-course.eu/tkinter_entry_widgets.php (By the way, this suffers from the common flaw of asking for separate first and last names. That's not reliable in terms of people's names, but it's no different in terms of bytes and strings.) (Also by the way, why is a Python course advertising that its web site is written in PHP?) Whether I use Python 2 (changing the import to Tkinter) or Python 3 (running the code unchanged), I get back a Unicode string (easily proven by looking at its repr() in show_entry_fields()), because the user typed *text* into the widget. This is what everyone will expect. Now, the standard I/O streams might be connected to a console, or might be reading from a pipe. This does add a level of complexity, as it's possible to read either text or bytes from them; but Python defaults to the most common case, where they're connected to a console, and does its best to allow print() to write Unicode to any console. (With limited success on some consoles; Windows' cmd.exe has problems. That's not Python's fault.) If you want binary, you can easily switch to binary mode. Maybe it would be better to have a simple function "change standard stream(s) to binary", but the default is still correct: most of the time, you want to work with text. > To me, the main difference between Python 2 and Python 3 is that in the > former, I use "..." everywhere, and in the latter, I use b"..." > everywhere. If I should need advanced text processing features, I'll go > through a decode() and encode(). Why do you work with the underlying representation (bytes) instead of the abstraction (strings)? To be consistent, you should probably eschew Python dictionaries in favour of a manually-implemented hashtable, and studiously avoid Python source code by hand-writing CPython bytecode. >> As of right now, *new* projects ought to be written in Python 3.3 or >> better, unless you have a compelling reason not to. You don't have to >> port old projects in order to take advantage of Python 3 for new >> projects. > > But my distro only provides Python 3.2. What's wrong with Python 3.2? > Why didn't anybody tell me to put off the migration? It's pretty easy to spin up a CPython 3.4 for Debian Wheezy. Or you might be able to just grab a package from Jessie, where CPython 3.4 is standard. Debian, like Red Hat, values stability over currency, so once Wheezy went into freeze on 2012-06-30 [1], the current-at-the-time Python was locked in (Python 3.3 wasn't released until 2012-09-29 [2]), in order to allow packages to depend on it and be able to trust it. (It's possible you're not on Debian Wheezy, but on some other distro that also ships 3.2 with its current release. The policies are likely to be similar.) ChrisA [1] https://wiki.debian.org/DebianWheezy [2] https://www.python.org/download/releases/3.3.0/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Chris Angelico : > Python defaults to the most common case, where they're connected to a > console, and does its best to allow print() to write Unicode to any > console. I don't know where you pull your statistics. Be that as it may, the main purpose of sys.stdin is to receive the workload and sys.stdout to deliver the goods. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, Jul 16, 2014 at 4:44 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> Python defaults to the most common case, where they're connected to a >> console, and does its best to allow print() to write Unicode to any >> console. > > I don't know where you pull your statistics. Heaps and HEAPS of personal experience, of myself and many other people. I frequently run programs that manipulate text and work with a console that displays text, which means that a consistent encoding (usually UTF-8) can be hidden away as an implementation detail. As long as the console correctly announces the encoding it expects and the program correctly writes in that encoding, all is well, and the program can simply "write text to the console". > Be that as it may, the main purpose of sys.stdin is to receive the > workload and sys.stdout to deliver the goods. Yes, but is that workload text or bytes? To be sure, there are programs whose stdin is usually or always bytes, but most use text. The default should be the most common and most useful option, and the alternative should be available when you want it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
