Re: Python 3 is killing Python
On Thu, 17 Jul 2014 15:48:38 +1000, alex23 wrote: > On 15/07/2014 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. > > PHP regularly breaks compatibility between _minor_ version releases: > > http://php.net/manual/en/migration53.incompatible.php > > Even more so with major releases: > > http://php.net/manual/en/migration5.incompatible.php > > And yet I never see anywhere near as much angst and agony as Python 3.x > has caused. Thank you for pointing this out! I thought that was the case with PHP, but I wasn't sure. Nice to have it confirmed. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
"Chris Angelico" wrote in message news:captjjmot9q2cuyy5jc6keycxyp8_usjhr1y8e+z+t70qnc5...@mail.gmail.com... > On Thu, Jul 17, 2014 at 4:31 PM, Frank Millman wrote: >> It is worth watching this - >> https://www.youtube.com/watch?v=skYBOXE02OQ > > Not in a position to watch Youtube vids at the moment. A blog post I'd > read, but a talk is not well suited to all forms of delivery... What's > it saying, can you summarize? I an also not in a position to watch it at the moment, but from memory ... The talk is recent - the video is dated 1st July 2014. He quotes some stats from PyPi, which shows number of downloads over a period, broken down by version. Over a recent period, Python2 downloads exceed Python3 downloads by a factor of 10:1 (subject to my memory ...) He has talked to many influential pythonistas in the recent past. He particularly comments on discussions with one of the prominent Python3 dissenters - Armin [can't remenber his surname]. He senses a great inertia in the established python community towards adopting Python3. He goes through some of the familiar reasons, most, if not all, relating to bytes/unicode. He is concerned about a growing division in the community, not only between users of the two versions, but between the mainstream users many of whom are resisting the move to Python3, and the developers, who are committed to Python3 but can only improve it by getting feedback from users. His closing plea was for users to get involved with Python3, help to improve it, and thereby help to re-unite the Python community. Frank P.S. If anyone watches the video, feel free to chip in and add to/correct what I have written above. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17/07/2014 04:14, Steven D'Aprano wrote: On Wed, 16 Jul 2014 18:16:16 -0700, Rick Johnson wrote: On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote: I'm not aware of any mass exodus from core Python 3 to the fork that has consistently proposed to give the world Python 2.8. Do you know something that I don't? Well, currently at least, we don't even *need* a Python 2.8, not for the next couple of years anyway. There will never be a Python 2.8. When push comes to shove, the people bitching about Python 3 will not do the work necessary to fork Python 2.7 and make a version 2.8. Actually I like the logic behind 2.8. "We've only had eight years to port our code to Python 3. That's not been long enough. So to work around the situation we'll throw all of our miniscule resources into forking Python to solve all of the problems that Python has created for us". Where is Walter Mitty when you need him? -- 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 Thu, 17 Jul 2014 07:18:54 +0200, Frank Millman wrote: > "Steven D'Aprano" wrote in > message news:53c66ba8$0$9505$c3e8da3$54964...@news.astraweb.com... >> >> E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake, >> but there are four versions of Python 3.x that do it that way and it's >> too late to change until Python 5000. (Python 4 is unlikely to break >> backwards compatibility in a big way.) >> >> > If it was considered important enough, couldn't they just introduce a > new datatype, say B'...', with the desired behaviour. B'' would be > backported to Python 2.7 as an alternative to b'', to faciliate writing > code that works on both versions. Sure, if it were considered important enough. But such an addition would add complexity and redundancy to the language, and would add one more thing that people have to learn and decide about. People would confuse which one was which, which would lead to bugs. Since b'abcd'[0:1] takes only a tiny bit more effort than b'abcd'[0], fixing this is not considered worth the cost. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thu, Jul 17, 2014 at 5:09 PM, Frank Millman wrote: > He quotes some stats from PyPi, which shows number of downloads over a > period, broken down by version. Over a recent period, Python2 downloads > exceed Python3 downloads by a factor of 10:1 (subject to my memory ...) These kinds of stats are always flawed. In a lot of cases, they're skewed heavily by defaults, and in other cases, skewed even more heavily by long dependency trees - so, for instance, a single Django installation might involve fetching large numbers of packages from PyPI, even though no new code has been written at all. Might add quite a bit to the download stats for one version or the other. And what about upgrades? Stable installations are still likely to want to get the latest, which means downloading from PyPI, ergo it's another hit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
I need an idea for practise!
Ok I would say I am almost a intermediate python programer. I have made 2 programs(with GUI). And basically they are quite boring(a text editor and calculator). I love programming but i am lost of ideas i actually suck at finding good creative ideas. Now i am not looking to use these ideas make them and then try get money for it. I am only a kid and would love some like real world project ideas to learn more about python. Yeah so if any one would like to give me some ideas to train my self on that would be so cool! -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac python py2app problem
On Wednesday, July 16, 2014 9:56:56 AM UTC+8, 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? Yeah i have zipped it up and put it on sourceforge and then when you download the zip it says it is incomplete. I do like the idea of making a .dmg file because i have used them downloading other apps and it works great but i dont know how to make them! would be great if you guys could give me a link to how to do this! -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thu, 17 Jul 2014 02:59:11 -0700, Nicholas Cannon wrote: > Ok I would say I am almost a intermediate python programer. I have made > 2 programs(with GUI). And basically they are quite boring(a text editor > and calculator). I love programming but i am lost of ideas i actually > suck at finding good creative ideas. Now i am not looking to use these > ideas make them and then try get money for it. I am only a kid and would > love some like real world project ideas to learn more about python. Yeah > so if any one would like to give me some ideas to train my self on that > would be so cool! How about creating an app. that interfaces with google groups so that it automatically cleans up the mess it makes before posting ;-) (single line paragraphs & double spacing ) heck i don't use google groups but would happily pay others to use such an app (not much though i am no Mark Shuttleworth) -- Make it myself? But I'm a physical organic chemist! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17.07.2014 06:47, Rick Johnson wrote:> Even though i will freely admit that Python is the easiest > language to learn (IMHO) For non-informatic students (i.e the vast majority of science/engineering students) I don't think that's true. Less general languages like Matlab appear much easier to me: unified doc, unified IDE, unified debugger, you can spend years without being confronted to what an "object" is, etc. > You and i don't use "print", and especially not "input" all > that much, but both of these (types of) functions are > *VITAL* lifelines for the noob when learning a language! Some argue that making print() working like all other python functions make it more consistent. Here for example: http://tinyurl.com/o2oxp9m > Not to mention the issues of looking at the wrong "version" > of a tutorial when using the "other" version of Python. > Again, you and i won't make these mistakes, but a noob will! It happened to me quite often that interesting tutorials where available in py2 only, despite the fact that all the concerned libraries were ported to py3 long ago. But on the other hand, this is not python specific. Forums keep track of all questions/answers and some very old threads remain highly visible in the search results, making new users reinvent the wheel all the time. Everyone should be able to decide if the information found on blogs, forums or even newspapers is up-to-date or not. Fab -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thu, Jul 17, 2014 at 8:12 PM, Fabien wrote: > On 17.07.2014 06:47, Rick Johnson wrote:> Even though i will freely admit > that Python is the easiest >> language to learn (IMHO) > > For non-informatic students (i.e the vast majority of science/engineering > students) I don't think that's true. Less general languages like Matlab > appear much easier to me: unified doc, unified IDE, unified debugger, you > can spend years without being confronted to what an "object" is, etc. That's always going to be true. If you have mathematical experience, you'll be much more comfortable with a math-specific setup than with a general programming environment. But for general programming, the IDE isn't that much help, and the math-specific language is going to get in the way. This is why there are so many different environments to choose from; if you want something that makes it really easy to put a Windows GUI program together, you probably grab one of the Microsoft tools, but if you want something that lets you run your program on any platform and still have a usable GUI, you want something cross-platform (tkinter, GTK, wx, Qt). This is not a problem with Python; it's simply how the world works. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 2014-07-17 04:15, Chris Angelico wrote: On Thu, Jul 17, 2014 at 12:51 PM, Steven D'Aprano wrote: Most programming languages are written for J. Random Hacker, not Jランダムハッカー. I had to paste that into Google Translate to be able to understand what you meant (although I could guess just fine)... but to actually see the characters, I had to paste it into my MUD client. Yeah. Figure that out. A MUD client had better font support for other languages than a web browser with a dedicated translation tool. I can see the characters in both Thunderbird and Firefox. -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac python py2app problem
Nicholas Cannon wrote: I do like the idea of making a .dmg file because i have used them downloading other apps and it works great but i dont know how to make them! In Disk Utility, use File>New>Disk Image from Folder. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Python3+Vim dev environment
Hi. Anyone with working experience on setting up Python3 dev with vim? functionalities needed: code completion and jump to defintion YCM suffices but only with py2. Any vim (plugin) for py3? Or do you have any experience both running YCM and jedi-vim(for py3) ? How's that going? Regards -- 吾輩は猫である。ホームーページはhttp://introo.me。 -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thu, Jul 17, 2014 at 3:29 PM, Nicholas Cannon wrote: I have made 2 programs(with GUI). And basically they are quite boring(a > text editor and calculator). > -- > https://mail.python.org/mailman/listinfo/python-list > What library did you use for the GUI? -- Abhiram.R -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thu, Jul 17, 2014 at 7:59 PM, Nicholas Cannon wrote: > I have made 2 programs(with GUI). And basically they are quite boring(a text > editor and calculator). Just for reference, those may be simple concepts, but they're anything but boring. Most of us use text editors all the time, and I have a habit of incorporating calculators into basically everything I write (if it has a command-line input system of any kind). It's worth knowing how to write both programs, because some day you'll be doing something where you want the program to just quickly pop up a little editor and let you change something on the fly, or just quickly fire up a calculator that drops the result into some part of the program's core functionality. It can be EXTREMELY handy, and useful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Iterating through set
Am 15.07.2014 02:10 schrieb LJ: Hi All. I'm coding a Dynamic Programming algorithm to solve a network flow problem. At some point in the algorithm I have to iterate through a set of nodes, while adding and/or removing elements, until the set is empty. I know a regular set() object does not work in a case like this, so I wonder if anyone knows of an efficient pythonic way to handle this. Thanks in advance! This sounds like you want to avoid processing of an item as soon as it is removed. Then I'd suggest the following: add = set() remove = set() while myset or add: for item in myset: if item not in remove: # process myset -= remove myset += add remove.clear() add.clear() Adding happens via add.add(item), removing via remove.add(item). If there is additionally the need to take care in which order to apply add/remove, or if it can happen that item X is added and removed in the same loop run, it gets a bit more complicated. Then adding would be like if item in remove: remove.remove(item) elif item not in myset and item not in add: add.add(item) and removing like if item in add: add.remove(item) elif item in myset: remove.add(item) HTH, Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
"Anders J. Munch" <2...@jmunch.dk> writes:
> So far I received exactly the answer I was expecting. 0 examples of
> NaN!=NaN being beneficial.
> I wasn't asking for help, I was making a point. Whether that will
> lead to improvement of Python, well, I'm not too optimistic, but I
> feel the point was worth making regardless.
Well, I just spotted this thread. An easy example is, well, pretty much
any case where SQL NULL would be useful. Say I have lists of borrowers,
the amount owed, and the amount they paid so far.
nan = float("nan")
borrowers = ["Alice", "Bob", "Clem", "Dan"]
amount_owed = [100.0, nan, 200.0, 300.0]
amount_paid = [100.0, nan, nan, 200.0]
who_paid_off = [b for (b, ao, ap) in
zip(borrowers, amount_owed, amount_paid)
if ao == ap]
I want to just get Alice from that list, not Bob. I don't know how much
Bow owes or how much he's paid, so I certainly don't know that he's paid
off his loan.
Cheers,
Johann
--
https://mail.python.org/mailman/listinfo/python-list
Multiple python versions, one dev environment???
Hello! The condensed version of the question would probably be: How does one deal with multiple interpreters and one package where you want to try some changes? The background: I made a trivial change to some package (docutils) to scratch a personal itch, and I want to offer this back to the community (whether it will be accepted or not). Because of this, I ran into some issues. Some facts: 1. Python3 is my main interpreter. 2. The tests of docutils only run under python2. 3. I desire not to touch my distribution's version of site-packagesX-Y. 4. I prefer to have one and only one development directory of my target package. My confusions: 1. Is it possible to have one source control managed directory of some package, which is used by two versions of python? 2. I assume that the *.pyc-files generated while using some python source are version dependent. What is the recommended way to have 'em both installed? 3. The way I have stumped a wall over here, is the puzzle of how to make python2 have a different $PYTHONPATH as python3. I hope to hear how this strategy is silly :) 4. I have contemplated the way of linking the source files from my development directory into user specified site-packages directories. Problem 3. still is valid. 5. Should venv and friends/foes com into play? If so: How? Appreciate any light shed on these issues. Thanks! Joep -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Fri, Jul 18, 2014 at 1:12 AM, Johann Hibschman wrote:
> Well, I just spotted this thread. An easy example is, well, pretty much
> any case where SQL NULL would be useful. Say I have lists of borrowers,
> the amount owed, and the amount they paid so far.
>
> nan = float("nan")
> borrowers = ["Alice", "Bob", "Clem", "Dan"]
> amount_owed = [100.0, nan, 200.0, 300.0]
> amount_paid = [100.0, nan, nan, 200.0]
> who_paid_off = [b for (b, ao, ap) in
> zip(borrowers, amount_owed, amount_paid)
> if ao == ap]
>
> I want to just get Alice from that list, not Bob. I don't know how much
> Bow owes or how much he's paid, so I certainly don't know that he's paid
> off his loan.
>
But you also don't know that he hasn't. NaN doesn't mean "unknown", it
means "Not a Number". You need a more sophisticated system that allows
for uncertainty in your data. I would advise using either None or a
dedicated singleton (something like `unknown = object()` would work,
or you could make a custom type with a more useful repr), and probably
checking for it explicitly. It's entirely possible that you do
virtually identical (or virtually converse) checks but with different
handling of unknowns - for instance, you might have one check for "who
should be sent a loan reminder letter" in which you leave out all
unknowns, and another check for "which accounts should be flagged for
human checking" in which you keep the unknowns (and maybe ignore every
loan <100.0). You have a special business case here (the need to
record information with a "maybe" state), and you need to cope with
it, which means dedicated logic and planning and design and code.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
New to Python and Python mail List
Hello Everyone
I am very much new to python scripting and i am here for knowledge
exchange.
I am trying to read a file with node pairs and weight.
I have to find the neighbours of each pair individual and combined
both also count them.
Later find the ratio of the neighbours that each node has. I am stuck
with finding nodes.
infile.txt
0_node1 0_node2 0w
1_node1 1_node2 1w
2_node1 2_node2 2w
3_node1 3_node2 3w
4_node1 4_node2 4w
import networkx as nx
import matplotlib.pyplot as plt
G=nx.Graph()
G = nx.read_edgelist('infile.txt', data=[("weight", float)])
def get_triangle(G):
for n1 in G.nodes:
neighbors1 = set(G[n1])
for n2 in filter(lambda x: x>n1, nodes):
neighbors2 = set(G[n2])
common = neighbors1 & neighbors2
for n3 in filter(lambda x: x>n2, common):
print n1
print n2
print n3
Any suggestion will be appreciated. Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
Are you using arch linux. I deal with multiple interpreters putting fake executables in /usr/local/bin for everything: (python, sphinx, virtualenv, pydoc, idle, python-config...) selecting 2 or 3. You can do the same for selecting 2.3, 2.5, 2.7. What the scripts do is to detect whether it is a system script whose prefix starts with /usr/bin, or whether it is a user script. Being in /usr/local/bin they will override executables in /usr/bin. Remember to chmod a+x the files in /usr/local/bin http://sindhus.bitbucket.org/manage-python-2-3.html http://stackoverflow.com/questions/15400985/how-to-completely- replace-python-3-with-python-2-in-arch-linux https://wiki.archlinux.org/index.php/Python#Dealing_with_ version_problem_in_build_scripts I use these scripts, but there is more than one way to do it /usr/local/bin/python=== #!/bin/bash script=`readlink -f -- "$1"` case "$script" in /usr/bin*) exec python3 "$@" ;; esac exec python2 "$@" /usr/local/bin/virtualenv=== #!/bin/bash script=`readlink -f -- "$1"` case "$script" in /usr/bin*) exec virtualenv3 "$@" ;; esac exec virtualenv2 "$@" Joep van Delft wrote: > Hello! > > The condensed version of the question would probably be: How does one > deal with multiple interpreters and one package where you want to try > some changes? > > The background: > I made a trivial change to some package (docutils) to scratch a > personal itch, and I want to offer this back to the community > (whether it will be accepted or not). Because of this, I ran into > some issues. > > Some facts: > 1. Python3 is my main interpreter. > 2. The tests of docutils only run under python2. > 3. I desire not to touch my distribution's version of > site-packagesX-Y. > 4. I prefer to have one and only one development directory of > my target package. > > My confusions: > 1. Is it possible to have one source control managed directory of > some package, which is used by two versions of python? > 2. I assume that the *.pyc-files generated while using some python > source are version dependent. What is the recommended way to have > 'em both installed? > 3. The way I have stumped a wall over here, is the puzzle of how to > make python2 have a different $PYTHONPATH as python3. I hope to > hear how this strategy is silly :) > 4. I have contemplated the way of linking the source files from my > development directory into user specified site-packages > directories. Problem 3. still is valid. > 5. Should venv and friends/foes com into play? If so: How? > > Appreciate any light shed on these issues. > > Thanks! > > >Joep > > > -- https://mail.python.org/mailman/listinfo/python-list
Blocked thread
I have a python cx_Oracle script that does a delete from a table. Usually this takes well under 1 second. But sometimes it takes 1 to 2 minutes. I wanted to monitor that delete and if it's taking too long I want to see what is blocking it. I run the delete sql in a thread and I do this: while self.isAlive(): self.join(5) if self.isAlive(): # run query to see who is blocking Looking at the timing on this, at 13:45:11.780 I called join and at 13:46:20.118 I was running the query to check for blocking. That query does not show that the delete is running and the next time through the loop isAlive() is False. My WAG is that when the delete query is blocked the join does not return and I am 'blocked' in the join() - does that seem like what would happen? It's not what I would expect. Can anyone think of a better way to do this? I could have a second script that does it, but that's kinda messy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
Joep van Delft wrote: > Hello! > > The condensed version of the question would probably be: How does one > deal with multiple interpreters and one package where you want to try > some changes? You could use tox to test a package using different Python versions. -- Akira -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thursday, July 17, 2014 4:59:11 AM UTC-5, Nicholas Cannon wrote: > Ok I would say I am almost a intermediate python > programer. I have made 2 programs(with GUI). And basically > they are quite boring(a text editor and calculator). I > love programming but i am lost of ideas i actually suck at > finding good creative ideas. Now i am not looking to use > these ideas make them and then try get money for it. I am > only a kid and would love some like real world project > ideas to learn more about python. Yeah so if any one would > like to give me some ideas to train my self on that would > be so cool! Hmm, unfortunately, if you do not already posses strong imaginative and creative skills, you "may" never become proficient at writing code, although your post does indicate a "deep desire" to write code, so maybe there is yet hope! First of all, you failed to explain the *extent* of the two GUI applications you wrote, and as such, i do not know where to start with my suggestions, so i will be forced to assume that both of these apps are very "simplistic". If the text editor is simply an app that allows: opening raw text files, editing them, and then saving the changes, you have a *whole* universe of functionality you could add to that. How about writing a colorizer for source code, and why stop with *only* a Python colorizer? You can learn about regexs by doing this, AND about other languages also. How about source code analyzers or debuggers, or smart indent/dedent features and such... How about any number of text editing tools that an average user would want: like wrapping tools, searching and replacing tools, etc... Heck, how about extending a raw text editor to handle rich text! Look, i know software already exists for all these functionalities, however, in order to learn you must re- invent the wheel, because you must know what is going on "under the hood" if you expect to become proficient at anything. When someone wants to learn, say, the piano, they do not just sit down and start hammering out Rachmaninoffs "prelude in g minor" with the "key-chord-Staccatissimo-precision" of a classically trained concert pianist, NO, they start out with simple little pieces, and gradually work up towards more difficult pieces, building a wealth of knowledge along the way. If your intention is to skip over the "little pieces" and go strait to the "masterpieces", then you are doomed to failure and might as well go watch a football game or join one of the political parties, this is where the feeble minded people aggregate to perpetuate their lack of intelligence! The *true* student of any discipline will *relish* each and every opportunity (no matter how miniscule) to learn something new, because, it is the vast database of "little ideas" which the masters *PILLAGE*, and then forge together within the "roid-raging" fires of *PASSION*, the greatest *MASTERPIECES* of human ingenuity that this decrepit lot of human *FILTH* hardly deserves! -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Fri, Jul 18, 2014 at 2:34 AM, Rick Johnson wrote: > If the text editor is simply an app that allows: opening raw > text files, editing them, and then saving the changes, you > have a *whole* universe of functionality you could add to > that. > > How about writing a colorizer for source code, and why > stop with *only* a Python colorizer? You can learn about > regexs by doing this, AND about other languages also. > > How about source code analyzers or debuggers, or smart > indent/dedent features and such... > > How about any number of text editing tools that an average > user would want: like wrapping tools, searching and > replacing tools, etc... > > Heck, how about extending a raw text editor to handle > rich text! To the OP: Ranting Rick's words shouldn't be taken to heart, although it's plenty possible to learn from him. My recommendation is: Scratch your own itch. Don't add features for the sake of adding features - that's a recipe for useless piles of mess. Instead, add exactly the feature that you need right now (even if adding that feature means it's no longer "right now" when you get a chance to use it), and then you know it's being useful. For instance, I have a mini-editor built into my MUD client [1] which is inferior to most decent code editors, but it has a few special features that make it useful *to me* and *in specific circumstances*; for most of my real work, I still use SciTE, because it's a much better editor. But the pop-out editor lets me: * Work with my server via a TELNET-like connection, and simply pop up an editor * Send the contents of the edit box back to the server. Since the server controls what's edited, it'll begin with an appropriate command that says "Hey server, here's that file I was editing". * Place the initial cursor position, again under server control - handy when I pop up a "git commit" message editor * Explicitly hard-wrap text to a specific column width, or auto-wrap on send * Integrate editing of text into any server-side command - it might not be a file that's being edited All this makes it distinctly superior to either ssh'ing to the server and editing a file (possible only for actual files, possible only for people with ssh logins to the server, etc, etc, etc), or explicitly copying and pasting to another editor window (much easier to let the program do it). And since it's a feature I use on a regular basis, there's a guarantee that it's actually useful, and therefore will be developed as it has need. In contrast, features that I added to a program only because someone said they'd use it (and then probably never even used it themselves) tend to languish, left as an artifact of a previous era rather than constantly improved. By the way, one specific point about RR's advice: A colorizer should *not* be written using regexps. It'd make for an absolute nightmare of impossible-to-debug regexp strings, plus there are fundamental limitations on what you can accomplish with them. You need to use a lexer - a lexical analyzer. Basically, to correctly colorize code, you need to have something equivalent to the first part of the language interpreter, but with a lot more tolerance for errors. That's a pretty big thing to write as regexps. ChrisA [1] Code here: https://github.com/Rosuav/Gypsum/blob/master/plugins/editor.pike -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 2:26 AM, Larry Martell wrote: > I have a python cx_Oracle script that does a delete from a table. > Usually this takes well under 1 second. But sometimes it takes 1 to 2 > minutes. I wanted to monitor that delete and if it's taking too long I > want to see what is blocking it. I run the delete sql in a thread... I don't know Oracle specifically, but if it's anything like PostgreSQL, you'll probably do better with a completely separate connection to the server, which might need to be a separate process. In PostgreSQL, I can query currently-active transactions thus: rosuav=> select state,query from pg_stat_activity; state| query -+--- idle in transaction | select * from pg_stat_activity; active | select state,query from pg_stat_activity; active | drop table test; (3 rows) (Better than that: Add "where pid=..." to that, using the backend PID provided by the thread you're monitoring, by "SELECT pg_backend_pid()". But that's even more PostgreSQL-specific.) With info like that, you can see what's happening, and whether it's stalled out or in a query or whatever. You should also be able to get some timestamps (Postgres can do that, I would be highly surprised if Oracle can't), such as when the transaction started, so you can see how long it's been stalled. Thing is, this requires a quite separate connection, which means you're monitoring the far end rather than the local thread. I suspect this will give you better results; Oracle's bound to have facilities for doing this, whereas your local thread may or may not be usefully monitorable. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thursday, July 17, 2014 12:48:38 AM UTC-5, alex23 wrote: > PHP regularly breaks compatibility between _minor_ version > releases: [...] more so with major releases: [...] yet I > never see anywhere near as much angst and agony as Python > 3.x has caused. Because you *IGNORE* the fact that people *ACTIVELY* choose to use languages like Python, however, people *MOSTLY* use languages like PHP and Javascript because they are *FORCED* Of course, nature always contains "abnormalities" so i'm sure there are few instances of people "seeking out" those languages, but they *ARE* in the minority. So, keeping those facts in mind, you can now understand why people are so passionate about Python code breaks, and so un-passionate about PHP and Javascript code breaks -- they're already loathing in agony, so why would they seek to acerbate it? POOR PITIFUL FOOLS! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Fri, Jul 18, 2014 at 3:36 AM, Rick Johnson wrote: > they're already loathing in agony, so why would they seek to > acerbate it? This is a truly amazing demonstration. You have outdone Gaelmaen for comprehensibly incorrect use of English. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 12:32 PM, Chris Angelico wrote: > I don't know Oracle specifically, but if it's anything like > PostgreSQL, you'll probably do better with a completely separate > connection to the server > Agreed. We use Sybase, and our DBA uses their tools extensively to identify problematic clients. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 1:32 PM, Chris Angelico wrote: > On Fri, Jul 18, 2014 at 2:26 AM, Larry Martell > wrote: >> I have a python cx_Oracle script that does a delete from a table. >> Usually this takes well under 1 second. But sometimes it takes 1 to 2 >> minutes. I wanted to monitor that delete and if it's taking too long I >> want to see what is blocking it. I run the delete sql in a thread... > > I don't know Oracle specifically, but if it's anything like > PostgreSQL, you'll probably do better with a completely separate > connection to the server, which might need to be a separate process. > In PostgreSQL, I can query currently-active transactions thus: > > rosuav=> select state,query from pg_stat_activity; > state| query > -+--- > idle in transaction | select * from pg_stat_activity; > active | select state,query from pg_stat_activity; > active | drop table test; > (3 rows) > > (Better than that: Add "where pid=..." to that, using the backend PID > provided by the thread you're monitoring, by "SELECT > pg_backend_pid()". But that's even more PostgreSQL-specific.) > > With info like that, you can see what's happening, and whether it's > stalled out or in a query or whatever. You should also be able to get > some timestamps (Postgres can do that, I would be highly surprised if > Oracle can't), such as when the transaction started, so you can see > how long it's been stalled. > > Thing is, this requires a quite separate connection, which means > you're monitoring the far end rather than the local thread. I suspect > this will give you better results; Oracle's bound to have facilities > for doing this, whereas your local thread may or may not be usefully > monitorable. I can have as many connections to the db server as I want, that's not the issue. The issue is that my main thread seems to be blocked in the join(), so I guess I'm going to need a separate script. I was trying to avoid that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 1:46 PM, Skip Montanaro wrote: > > On Thu, Jul 17, 2014 at 12:32 PM, Chris Angelico wrote: >> >> I don't know Oracle specifically, but if it's anything like >> PostgreSQL, you'll probably do better with a completely separate >> connection to the server > > > Agreed. We use Sybase, and our DBA uses their tools extensively to identify > problematic clients. I did ask my DBA - he said "Blocking is a normal part of database operations. It's only a problem when it's a deadlock, in which case the server will detect that, kill one of the processes and log it." My situation is not a deadlock - there's just multiple scripts hitting the same tables at the same time. When one gets done the next one proceeds. I just want to find out what are the other processes causing this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 3:55 AM, Larry Martell wrote: > I can have as many connections to the db server as I want, that's not > the issue. The issue is that my main thread seems to be blocked in the > join(), so I guess I'm going to need a separate script. I was trying > to avoid that. Right, but what you're trying to do is monitor the local thread, by spinning off a thread to do the deletion and then keeping an eye on it by attempting a timed join. I'm saying it'd probably be easier to do the monitoring on the server end, via a second connection. (It most likely doesn't need special database privileges, even; at least in PostgreSQL, any user can see pg_stat_activity entries for the same user.) That's usually going to be more reliable, plus the server can tell you whether the deletion is blocked waiting for a lock or busy writing to the disk or something else. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 2:01 PM, Chris Angelico wrote: > On Fri, Jul 18, 2014 at 3:55 AM, Larry Martell > wrote: >> I can have as many connections to the db server as I want, that's not >> the issue. The issue is that my main thread seems to be blocked in the >> join(), so I guess I'm going to need a separate script. I was trying >> to avoid that. > > Right, but what you're trying to do is monitor the local thread, by > spinning off a thread to do the deletion and then keeping an eye on it > by attempting a timed join. I'm saying it'd probably be easier to do > the monitoring on the server end, via a second connection. (It most > likely doesn't need special database privileges, even; at least in > PostgreSQL, any user can see pg_stat_activity entries for the same > user.) That's usually going to be more reliable, plus the server can > tell you whether the deletion is blocked waiting for a lock or busy > writing to the disk or something else. Yes, I agree, but the second connection will have to be in a second script, not the main thread of the script I have. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 4:00 AM, Larry Martell wrote: > I did ask my DBA - he said "Blocking is a normal part of database > operations. It's only a problem when it's a deadlock, in which case > the server will detect that, kill one of the processes and log it." > > My situation is not a deadlock - there's just multiple scripts hitting > the same tables at the same time. When one gets done the next one > proceeds. I just want to find out what are the other processes causing > this. Then you definitely want server-side info. The DB server's the one who knows who's waiting on whom. See if your DBA can help you with the specifics; this will be bread-and-butter monitoring work for him. Automating it might require some tweaking, but if he's at all competent at his job, he'll know how to figure out (if manually) what's blocking an important query. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 4:03 AM, Larry Martell wrote: > On Thu, Jul 17, 2014 at 2:01 PM, Chris Angelico wrote: >> On Fri, Jul 18, 2014 at 3:55 AM, Larry Martell >> wrote: >>> I can have as many connections to the db server as I want, that's not >>> the issue. The issue is that my main thread seems to be blocked in the >>> join(), so I guess I'm going to need a separate script. I was trying >>> to avoid that. >> >> Right, but what you're trying to do is monitor the local thread, by >> spinning off a thread to do the deletion and then keeping an eye on it >> by attempting a timed join. I'm saying it'd probably be easier to do >> the monitoring on the server end, via a second connection. (It most >> likely doesn't need special database privileges, even; at least in >> PostgreSQL, any user can see pg_stat_activity entries for the same >> user.) That's usually going to be more reliable, plus the server can >> tell you whether the deletion is blocked waiting for a lock or busy >> writing to the disk or something else. > > Yes, I agree, but the second connection will have to be in a second > script, not the main thread of the script I have. Maybe. I don't know what facilities Oracle gives you; it might be possible to start a query asynchronously, with either a callback when it's done or a poll for completion. Then another connection could be used to keep an eye on the first one. But yes, doing it with a completely separate script would be simpler in many ways. Or you might be able to do the job with two threads. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
Brother,I had same views and after creating some small projects I directly tried to jump over large projects (went for data mining using neural network) and FAILED. I realized small things really matter. So I suggest just couple of GUI projects are not enough go for more. start with anything. here are couple of links I am staring with: 1. http://www.reddit.com/r/beginnerprojects 2. http://www.openbookproject.net/py4fun/ and there are many more you can go for "learnstreet.com" I am too a Intermediate but I prefer to say Beginner and if you want we can make projects together. I am Currently working on a small chat application. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 2:04 PM, Chris Angelico wrote: > On Fri, Jul 18, 2014 at 4:00 AM, Larry Martell > wrote: >> I did ask my DBA - he said "Blocking is a normal part of database >> operations. It's only a problem when it's a deadlock, in which case >> the server will detect that, kill one of the processes and log it." >> >> My situation is not a deadlock - there's just multiple scripts hitting >> the same tables at the same time. When one gets done the next one >> proceeds. I just want to find out what are the other processes causing >> this. > > Then you definitely want server-side info. The DB server's the one who > knows who's waiting on whom. See if your DBA can help you with the > specifics; this will be bread-and-butter monitoring work for him. > Automating it might require some tweaking, but if he's at all > competent at his job, he'll know how to figure out (if manually) > what's blocking an important query. I know what SQL to run to see who is blocking whom. The issue is that the scripts that are hitting this table run every 5 minutes 24/7 from 5 different locations (Chicago, New Jersey, London, Tokyo, and Sydney). 99% of the time it's fine and the query takes under 1 second. But every once it a while it takes 2 minutes. It will be hard to detect that manually. What I was trying to do in my threaded code was detect when it was taking more than 5 seconds, and then start monitoring it. I think I just need a second script that is always running and when it finds blocking, log it to a file. I was trying to avoid that and deal with it from within. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 4:13 AM, Larry Martell wrote: > But every once it a while it takes 2 minutes. It will be hard > to detect that manually. What I was trying to do in my threaded code > was detect when it was taking more than 5 seconds, and then start > monitoring it. Fair enough. In that case, I'd just do it the simple way: get the backend PID (or whatever other connection identification is appropriate), spin off a thread/process to do the monitoring. It sleeps five seconds, then does its first query. If the server says that connection's done its work, easy! Disconnect, job done. Otherwise, do whatever monitoring you can. But if your main goal is diagnosis, rather than monitoring, here's a really really naughty idea that might help: Refrain from committing if it's taken too long. Something like this: start = time.time() # do the actual work, but don't commit if time.time() > start + 5: # raise an alarm, tell a human being that something's wrong else: commit() Obviously you run this "dangeroussed-up version" of the script only when there's a person there to react to the alarm, otherwise you go for the normal one. But this could give you a massive insight into what's happening, because until you commit, you have all your locks and things. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Thu, Jul 17, 2014 at 2:09 PM, Chris Angelico wrote: > On Fri, Jul 18, 2014 at 4:03 AM, Larry Martell > wrote: >> On Thu, Jul 17, 2014 at 2:01 PM, Chris Angelico wrote: >>> On Fri, Jul 18, 2014 at 3:55 AM, Larry Martell >>> wrote: I can have as many connections to the db server as I want, that's not the issue. The issue is that my main thread seems to be blocked in the join(), so I guess I'm going to need a separate script. I was trying to avoid that. >>> >>> Right, but what you're trying to do is monitor the local thread, by >>> spinning off a thread to do the deletion and then keeping an eye on it >>> by attempting a timed join. I'm saying it'd probably be easier to do >>> the monitoring on the server end, via a second connection. (It most >>> likely doesn't need special database privileges, even; at least in >>> PostgreSQL, any user can see pg_stat_activity entries for the same >>> user.) That's usually going to be more reliable, plus the server can >>> tell you whether the deletion is blocked waiting for a lock or busy >>> writing to the disk or something else. >> >> Yes, I agree, but the second connection will have to be in a second >> script, not the main thread of the script I have. > > Maybe. I don't know what facilities Oracle gives you; it might be > possible to start a query asynchronously, with either a callback when > it's done or a poll for completion. Then another connection could be > used to keep an eye on the first one. But yes, doing it with a > completely separate script would be simpler in many ways. Or you might > be able to do the job with two threads. I do not think Oracle support async or non-blocking queries as Postgres does. But what I think I can do is not call join(), and just start monitoring the server when I kick off the thread with the mail sql it in. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 4:19 AM, Larry Martell wrote: > I do not think Oracle support async or non-blocking queries as > Postgres does. But what I think I can do is not call join(), and just > start monitoring the server when I kick off the thread with the mail > sql it in. It's more what the client library supports, rather than the server, but sure. If it doesn't do async queries, that settles it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote: > For non-informatic students [...] I don't think that's true. > Less general languages like Matlab appear much easier to > me: unified doc, unified IDE, unified debugger I'll agree that the lack of a "quality" IDE in Python is a point of inadequacy. Sure, IDLE is not *useless*, however, it is in fact woefully inadequate and should be embarrassing to the whole community, both in it's buggy-ness and it's poorly written source code. I would love to see IDLE become a bit more "polished", because, i believe that even though the software is outdated and poorly structured , a simplistic *INTEGRATED* IDE can be very helpful for new Python programmers who have no prior programming experience. Sadly, all of my calls to improve IDLE have been meet with rebukes about me "whining". The "powers that be" would wise to *UTILIZE* and *ENCOURAGE* my participation instead of *IGNORING* valuable talent and *IMPEDING* the expansion of this "private boys club". > you can spend years without being confronted to what an > "object" is, etc. I believe one could eaisly ignore the OOP aspects of Pyhton for as long as they wished, maybe even forever? Python is a multi-paridigm language, and i'm quite happy with that fact > Some argue that making print() work like all other > python functions made it more consistent. Yes, and i agree! Print should have been a function from day one, however, i am not lamenting the "evolution" of "print", i am merely lamenting the confusion induced from backwards incompatibility between "new print" and "old print". > It happened to me quite often that interesting tutorials > where available in py2 only, despite the fact that all the > concerned libraries were ported to py3 long ago. But on > the other hand, this is not python specific. Forums keep > track of all questions/answers and some very old threads > remain highly visible in the search results, making new > users reinvent the wheel all the time. Everyone should be > able to decide if the information found on blogs, forums > or even newspapers is up-to-date or not. Really? Even noobies? The internet is a double edged sword (when used to learn any language) because although there is a vast wealth of information out there for just about any question a noob might have, if he does not phrase his google queries "just so", he is doomed to read information that is at beast confusing, and at worse just flat out lies. I wish "we", as members of internet communities, had some control over the vast amount of information lying around in the darkest corners of the web. Because, we cannot rely *solely* on our "official" tutorials to answer every question a noob may have. And since we cannot control the content of private sites, blogs, groups, etc..., our only remedy is some sort of "official filtered search engine" that will hide the outdated information, and expose only the most relevant and updated information for the version requested. A database where pythonistas can categorize and "up vote" or "down vote" the value of each piece of information. A sort of "Stack Overflow" of the entire set of Python related information violable on the web. Of course it would need to utilize some heavy crowd sourcing, but i believe something like this would be both beneficial and feasible. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Fri, Jul 18, 2014 at 4:15 AM, Rick Johnson wrote: > Sadly, all of my calls to improve IDLE have been meet with > rebukes about me "whining". The "powers that be" would wise > to *UTILIZE* and *ENCOURAGE* my participation instead of > *IGNORING* valuable talent and *IMPEDING* the expansion of > this "private boys club". Do you write patches, or just say "This is terrible. Aorta do summing about it."? [1] If you want something done, the best way is to do it. Simply telling someone else what to do is not "participation" which should be "encourage[d]", but is indeed likely to be whining. Oh, and when you talk about it like this, you make everyone absolutely sure that it really IS just whining. ChrisA [1] http://www.textfiles.com/humor/strine.txt -- https://mail.python.org/mailman/listinfo/python-list
patch request for os.urandom()
Could os.urandom() be patched to use the new Linux getrandom() system call on systems where it is available? Further info: http://lists.openwall.net/linux-kernel/2014/07/17/235 I've stopped posting to the Python bug tracker because the password management issues became too annoying. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
> On Fri, Jul 18, 2014 at 3:36 AM, Rick Johnson > This is a truly amazing demonstration. You have outdone > Gaelmaen for comprehensibly incorrect use of English. Of all my impassioned pleas, astute logical reasoning, and empathetic motivational speeches, of all of that "gold", all you can muster is to harp about a few misspellings? ARE YOU SERIOUS? Okay, i admit it. My spell checker is broken -- maybe it was written in Python3 and it's fuzzy logic is a little too fuzzy for it's own good? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Rick Johnson : > Sure, IDLE is not *useless*, however, it is in fact woefully > inadequate and should be embarrassing to the whole community, both in > it's buggy-ness and it's poorly written source code. This is beneath trolling. Redeem yourself by apologizing. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: patch request for os.urandom()
On Fri, Jul 18, 2014 at 4:34 AM, Paul Rubin wrote: > Could os.urandom() be patched to use the new Linux getrandom() system > call on systems where it is available? Further info: > > http://lists.openwall.net/linux-kernel/2014/07/17/235 Uhm... does that even exist in kernel trunk yet? That's pretty amazingly new. I would guess Python doesn't want to start using something like that until it's *at least* appeared in a released kernel; although of course you're welcome to run a patched Python on a patched Linux to make use of this. Trouble with that seems to be that it's reducing code paths from two to... two. Instead of having a seldom-used code path for the fall-back when there's no fd available, you instead have an alternate code path for the fall-back when getrandom() doesn't exist. But if the Linux guys decide to implement this, then you can take it to python-dev with "This is supported by Linux 3.x.y" (or probably "Linux 3.x"), and preferably a patch that includes something in ./configure to probe for availability. Patches speak louder than words :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Fri, Jul 18, 2014 at 4:38 AM, Rick Johnson wrote: >> This is a truly amazing demonstration. You have outdone >> Gaelmaen for comprehensibly incorrect use of English. > > Of all my impassioned pleas, astute logical reasoning, and > empathetic motivational speeches, of all of that "gold", all > you can muster is to harp about a few misspellings? > > ARE YOU SERIOUS? > > Okay, i admit it. My spell checker is broken -- maybe it > was written in Python3 and it's fuzzy logic is a little too > fuzzy for it's own good? Yeah, sure. That was absolute gold there, totally amazing stuff. I was so absolutely astonished by the sheer ... uh, amazingness of it, that I couldn't find anything to say. Either that, or it was a load of drivel. Kinda hard to tell one from the other, face like yours. But I imagine if if it were fear, your eyes would be wider. Or something like that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Chris Angelico writes: > But you also don't know that he hasn't. NaN doesn't mean "unknown", it > means "Not a Number". You need a more sophisticated system that allows > for uncertainty in your data. Regardless of whether this is the right design, it's still an example of use. As to the design, using NaN to implement NA is a hack with a long history, see http://www.numpy.org/NA-overview.html for some color. Using NaN gets us a hardware-accelerated implementation with just about the right semantics. In a real example, these lists are numpy arrays with tens of millions of elements, so this isn't a trivial benefit. (Technically, that's what's in the database; a given analysis may look at a sample of 100k or so.) > You have a special business case here (the need to > record information with a "maybe" state), and you need to cope with > it, which means dedicated logic and planning and design and code. Yes, in principle. In practice, everyone is used to the semantics of R-style missing data, which are reasonably well-matched by nan. In principle, (NA == 1.0) should be a NA (missing) truth value, as should (NA == NA), but in practice having it be False is more useful. As an example, indexing R vectors by a boolean vector containing NA yields NA results, which is a feature that I never want. Cheers, Johann -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
Chris Angelico : > It's more what the client library supports, rather than the server, > but sure. If it doesn't do async queries, that settles it. The server can't control that. At the networking/OS level, it's all asynchronous. I would recommend a process pool for blocking DB queries. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman wrote: > Chris Angelico writes: > >> But you also don't know that he hasn't. NaN doesn't mean "unknown", it >> means "Not a Number". You need a more sophisticated system that allows >> for uncertainty in your data. > > Regardless of whether this is the right design, it's still an example of > use. Sure it is. And you may well have earned yourself that beer. But I don't put too much stock in hacks, at least as regards design decisions elsewhere. It's a little dubious when you grant special meaning to things and then use that meaning to justify the things' semantics. I'd much rather find an example where, for instance, numerical calculations might overflow to +inf or -inf, and then further calculations can result in a nan, etc, etc. Those are the sorts of examples that you'd find among SciPy users and such. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman wrote: > In > principle, (NA == 1.0) should be a NA (missing) truth value, as should > (NA == NA), but in practice having it be False is more useful. This is actually fairly easily implemented, if you ever want it. class NAType: def __repr__(self): return "NA" def __eq__(self, other): return self __lt__ = __gt__ = __le__ = __ge__ = __ne__ = __eq__ NA = NAType() ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blocked thread
On Fri, Jul 18, 2014 at 4:50 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> It's more what the client library supports, rather than the server, >> but sure. If it doesn't do async queries, that settles it. > > The server can't control that. At the networking/OS level, it's all > asynchronous. That's what I mean. But if your client library doesn't support async queries, it's not worth trying to hack it in. The "it" in the second sentence was referring to "client library", not "server", though I admit the grammar was a little unclear. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17/07/2014 19:15, Rick Johnson wrote: On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote: Sadly, all of my calls to improve IDLE have been meet with rebukes about me "whining". The "powers that be" would wise to *UTILIZE* and *ENCOURAGE* my participation instead of *IGNORING* valuable talent and *IMPEDING* the expansion of this "private boys club". Terry Reedy and Co have been pouring improvements into IDLE via the bug tracker for months if not years. How many times have you logged on there to help out? The background that allows this to happen http://legacy.python.org/dev/peps/pep-0434/. How strongly this contrasts with '*IGNORING* valuable talent and *IMPEDING* the expansion of this "private boys club"'. -- 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: NaN comparisons - Call For Anecdotes
Chris Angelico : > numerical calculations might overflow to +inf or -inf, and then > further calculations can result in a nan, etc, etc. Those are the > sorts of examples that you'd find among SciPy users and such. There is some inconsistency. Mathematically, there are undefined operations, for a good reason. That's because the limits are not unambiguous and that's why 0/0, 0**0, 1/0 and inf-inf are undefined. Why 0/0 results in an exception but inf-inf = nan, I don't see a justification. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/17/2014 11:15 AM, Rick Johnson wrote: Sadly, all of my calls to improve IDLE have been meet with rebukes about me "whining". The "powers that be" would wise to *UTILIZE* and *ENCOURAGE* my participation instead of *IGNORING* valuable talent and *IMPEDING* the expansion of this "private boys club". I imagine those that would be in a position to improve idle don't see the point of it. IMO, idle was never intended as a production development editor but more as an extensive example of gui programming with python. Yes, you _can_ use it to edit, and there are nice python hooks, but I doubt that anyone with the skills to enhance idle actually uses idle. You-can-also-program-using-notepad-eeew-ly y'rs, Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thursday, July 17, 2014 12:20:13 PM UTC-5, Chris Angelico wrote: > By the way, one specific point about RR's advice: A > colorizer should *not* be written using regexps. It'd make > for an absolute nightmare of impossible-to-debug regexp > strings Just because *YOU* harbor irrational fears of regexp pattern syntax, does mean the rest of us should propagate your religious beliefs and worship your "shrines of fear-mongering". Q: Is using regexps to create a colorizer the *ONLY* method to create a colorizer? A: Uh, no! Q: Is using regexps the *BEST* method to create a colorizer? A: Depends on who you ask and what the specific details are. Remember, this is "academic exercise", and i believe a damn *good* exercise because *even* a noob can understand the basic problems that need to be solved to create a colorizer: 1. I have a finite set of keywords and lexical structures that need to be located within a text. 2. I need to map colors to patterns so i can paint the keywords and lexical structures appropriately when i find them. 3. I need to institute events that will cause the colorizer to search for the patterns at appropriate times (for instance: when text is loaded, when text is edited, etc) 3a. Furthermore, i need to refine the breadth of my search area depending on the current context of the edit -- Should i search *only* the current line being edited, or, is the editing occurring inside a larger "multi-line lexical structure" that will need to be considered, OR, should i search the entire text??? > plus there are fundamental limitations on what you can > accomplish with them. Of course, *REMEMBER*, this is an "academic exercise", intended to familiarize the student with regexps and doing so in the context of a *real* world problem, who's scope is within the grasp of a noob, not some rechid flatulence pulled from the anus of a "so-called" teacher. But don't tell me for a *SECOND* that a colorizer, and a damn good one, can not be written utilizing regexps, because you're either wrong, or you're scared, or you're ignorant, or you're all of the above! > You need to use a lexer - a lexical analyzer. Basically, > to correctly colorize code, you need to have something > equivalent to the first part of the language interpreter, > but with a lot more tolerance for errors. That's a pretty > big thing to write as regexps. Great Chris, so as a "lesson" for learning *regexps* you propose that your students write a *lexer* instead. What's next? Do you propose they drive an auto whilst protruding their head from the vehicle like a canine, and observing the plant life on the side of the road to earn a degree in botany? You know, you would fit in nicely in the American public school system, since American teachers are not only free of the requirement of "teaching", they are actually *COMPELLED* not to do so by the greedy unions. I SURMISE YOUR DESK WILL BE DEVOID OF ANY "TREE BEARING" FRUITS! -- https://mail.python.org/mailman/listinfo/python-list
Re: patch request for os.urandom()
In article <7xlhrrkf6h@ruckus.brouhaha.com>, Paul Rubin wrote: > I've stopped posting to the Python bug tracker because the password > management issues became too annoying. Can you elaborate on the problems you are having? -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
On 7/17/14 11:32 AM, Joep van Delft wrote: Hello! The condensed version of the question would probably be: How does one deal with multiple interpreters and one package where you want to try some changes? The background: I made a trivial change to some package (docutils) to scratch a personal itch, and I want to offer this back to the community (whether it will be accepted or not). Because of this, I ran into some issues. Some facts: 1. Python3 is my main interpreter. 2. The tests of docutils only run under python2. 3. I desire not to touch my distribution's version of site-packagesX-Y. 4. I prefer to have one and only one development directory of my target package. My confusions: 1. Is it possible to have one source control managed directory of some package, which is used by two versions of python? 2. I assume that the *.pyc-files generated while using some python source are version dependent. What is the recommended way to have 'em both installed? 3. The way I have stumped a wall over here, is the puzzle of how to make python2 have a different $PYTHONPATH as python3. I hope to hear how this strategy is silly :) 4. I have contemplated the way of linking the source files from my development directory into user specified site-packages directories. Problem 3. still is valid. 5. Should venv and friends/foes com into play? If so: How? Appreciate any light shed on these issues. Virtualenv is definitely the right way to isolate different Python environments from each other. Each one has its own PYTHONPATH, so each project of yours can have different packages installed. For testing one project on multiple versions of Python, use tox. Its entire reason for being is to test Python code against multiple environments, generally for different Python versions, but possibly for other reasons, like different versions of dependencies. Tox will manage the virtualenvs for you, it makes multi-version testing very simple. Thanks! Joep -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
Hello Javier!
Thanks, those links are helping a bit. And: yes, I am using Archlinux.
But still those links assume that there are totally separate
site-packages* directories installed for both. I am not sure how I
would surpass this distinction between py-X.P and py-Y.Q.
Should I really create a massive amount of symlinks like this?:
| #!/usr/bin/zsh
| for d in ~/src/mypackage/**/*(/); do
|# matches all directories
|mkdir -p "~/src/py-2.7/mypackage/${d#*src/mypackage}"
|mkdir -p "~/src/py-3.4/mypackage/${d#*src/mypackage}"
| done
| for f in ~/src/mypackage/**/^*.pyc(.); do
|# matches all files except for *.pyc
|ln -s "$f" "~/src/py-2.7/mypackage${f#*src/mypackage}"
|ln -s "$f" "~/src/py-3.4/mypackage${f#*src/mypackage}"
| done
...and then set $PYTHONPATH according to the target version in a
#!/usr/local/bin-script?
I can work with this (have not tried though), but there must be a
more elegant solution than symlinking my way forward...
Cheers!
Joep
On Thu, 17 Jul 2014 16:05:27 + (UTC)
Javier wrote:
> Are you using arch linux.
>
>
> I deal with multiple interpreters putting fake executables in
> /usr/local/bin for everything: (python, sphinx, virtualenv, pydoc,
> idle, python-config...) selecting 2 or 3. You can do the same for
> selecting 2.3, 2.5, 2.7. What the scripts do is to detect whether
> it is a system script whose prefix starts with /usr/bin, or whether
> it is a user script. Being in /usr/local/bin they will override
> executables in /usr/bin. Remember to chmod a+x the files
> in /usr/local/bin
>
> http://sindhus.bitbucket.org/manage-python-2-3.html
> http://stackoverflow.com/questions/15400985/how-to-completely-replace-python-3-with-python-2-in-arch-linux
> https://wiki.archlinux.org/index.php/Python#Dealing_with_version_problem_in_build_scripts
>
> I use these scripts, but there is more than one way to do it
>
> /usr/local/bin/python===
> #!/bin/bash
> script=`readlink -f -- "$1"`
> case "$script" in
> /usr/bin*)
> exec python3 "$@"
> ;;
> esac
> exec python2 "$@"
>
> /usr/local/bin/virtualenv===
> #!/bin/bash
> script=`readlink -f -- "$1"`
> case "$script" in
> /usr/bin*)
> exec virtualenv3 "$@"
> ;;
> esac
>
> exec virtualenv2 "$@"
>
>
>
>
>
>
>
>
> Joep van Delft wrote:
> > Hello!
> >
> > The condensed version of the question would probably be: How does
> > one deal with multiple interpreters and one package where you
> > want to try some changes?
> >
> > The background:
> > I made a trivial change to some package (docutils) to scratch a
> > personal itch, and I want to offer this back to the community
> > (whether it will be accepted or not). Because of this, I ran into
> > some issues.
> >
> > Some facts:
> > 1. Python3 is my main interpreter.
> > 2. The tests of docutils only run under python2.
> > 3. I desire not to touch my distribution's version of
> > site-packagesX-Y.
> > 4. I prefer to have one and only one development directory of
> > my target package.
> >
> > My confusions:
> > 1. Is it possible to have one source control managed directory of
> > some package, which is used by two versions of python?
> > 2. I assume that the *.pyc-files generated while using some python
> > source are version dependent. What is the recommended way to
> > have 'em both installed?
> > 3. The way I have stumped a wall over here, is the puzzle of how
> > to make python2 have a different $PYTHONPATH as python3. I hope to
> > hear how this strategy is silly :)
> > 4. I have contemplated the way of linking the source files from my
> > development directory into user specified site-packages
> > directories. Problem 3. still is valid.
> > 5. Should venv and friends/foes com into play? If so: How?
> >
> > Appreciate any light shed on these issues.
> >
> > Thanks!
> >
> >
> >Joep
> >
> >
> >
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
On Thu, 17 Jul 2014 15:41:44 -0400 Ned Batchelder wrote: > > For testing one project on multiple versions of Python, use tox. > Its entire reason for being is to test Python code against multiple > environments, generally for different Python versions, but possibly > for other reasons, like different versions of dependencies. > > Tox will manage the virtualenvs for you, it makes multi-version > testing very simple. > Excellent, Ned and Akira, I will look into it! Cheers, Joep -- https://mail.python.org/mailman/listinfo/python-list
Re: patch request for os.urandom()
On 17/07/14 20:34, Paul Rubin wrote: Could os.urandom() be patched to use the new Linux getrandom() system call on systems where it is available? /dev/urandom exists on other Unix-like systems as well. Right now os.urandom only uses special system calls on Windows. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac python py2app problem
In article , Gregory Ewing wrote: > Nicholas Cannon wrote: > > I do like the idea of making a .dmg file > > because i have used them downloading other apps and it works great but i > > dont > > know how to make them! > > In Disk Utility, use File>New>Disk Image from Folder. Or...open Disk Utility and drop the app onto its dock icon. -- Russell -- https://mail.python.org/mailman/listinfo/python-list
Re: patch request for os.urandom()
On 17.07.2014 20:34, Paul Rubin wrote: > Could os.urandom() be patched to use the new Linux getrandom() system > call on systems where it is available? Further info: > > http://lists.openwall.net/linux-kernel/2014/07/17/235 > > I've stopped posting to the Python bug tracker because the password > management issues became too annoying. > The feature will be implemented as soon as the first Linux distribution comes with a kernel version that supports the new syscall. By the way Python 3.4 is not vulnerable to fd exhaustion attack. The interpreter keeps an open file descriptor on /dev/urandom. The wrapper code ensures that the fd is not replaced. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17/07/2014 20:22, Emile van Sebille wrote: On 7/17/2014 11:15 AM, Rick Johnson wrote: Sadly, all of my calls to improve IDLE have been meet with rebukes about me "whining". The "powers that be" would wise to *UTILIZE* and *ENCOURAGE* my participation instead of *IGNORING* valuable talent and *IMPEDING* the expansion of this "private boys club". I imagine those that would be in a position to improve idle don't see the point of it. IMO, idle was never intended as a production development editor but more as an extensive example of gui programming with python. Yes, you _can_ use it to edit, and there are nice python hooks, but I doubt that anyone with the skills to enhance idle actually uses idle. You-can-also-program-using-notepad-eeew-ly y'rs, Emile Some of the top core developers teach classes using IDLE as it's the only tool guaranteed to be available on all the major platforms. You might also like to view this https://www.youtube.com/watch?v=d1a4Jbjc-vU -- 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: NaN comparisons - Call For Anecdotes
On Thu, Jul 17, 2014 at 1:10 PM, Marko Rauhamaa wrote: > Mathematically, there are undefined operations, for a good reason. > That's because the limits are not unambiguous and that's why 0/0, 0**0, > 1/0 and inf-inf are undefined. Well, 0**0 is usually defined as 1, despite the limits being ambiguous. Also, 1/0 in IEEE 754 is defined as inf. > Why 0/0 results in an exception but inf-inf = nan, I don't see a > justification. I expect that float division by zero was made to raise an exception for consistency with integer division by zero, where it might be considered inappropriate to switch types and return inf or nan. Granted that nowadays integer division returns a float anyway, but there is still floor division to think about. Maybe this should have been fixed in Python 3, but it wasn't. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Ian Kelly : > Well, 0**0 is usually defined as 1, despite the limits being > ambiguous. https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml> But if it could be defined, what "should" it be? 0 or 1? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/17/2014 3:22 PM, Emile van Sebille wrote: I imagine those that would be in a position to improve idle don't see the point of it. IMO, idle was never intended as a production development editor but more as an extensive example of gui programming with python. Yes, you _can_ use it to edit, and there are nice python hooks, but I doubt that anyone with the skills to enhance idle actually uses idle. That is something of a problem as people 'graduate' to multi-language environments. However, while I have programmed in about 20 languages during my lifetime, I have now 'contracted' to using only Python (except for the occasional .bat file). So I use Idle to work on both my own stuff and on fixing Idle. When I notice an issue while working on an issue, I file a new issue. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On 7/17/2014 1:20 PM, Chris Angelico wrote:
By the way, one specific point about RR's advice: A colorizer should
*not* be written using regexps. It'd make for an absolute nightmare of
impossible-to-debug regexp strings, plus there are fundamental
limitations on what you can accomplish with them. You need to use a
lexer - a lexical analyzer. Basically, to correctly colorize code, you
need to have something equivalent to the first part of the language
interpreter, but with a lot more tolerance for errors. That's a pretty
big thing to write as regexps.
It depends on how deeply one wants to colorize. idlelib.ColorDelegator
colors comments, strings, keywords, builtin names, and names following
'def' and 'class' with the following regexes.
def any(name, alternates):
"Return a named group pattern matching list of alternates."
return "(?P<%s>" % name + "|".join(alternates) + ")"
def make_pat():
kw = r"\b" + any("KEYWORD", keyword.kwlist) + r"\b"
builtinlist = [str(name) for name in dir(builtins)
if not name.startswith('_') and \
name not in keyword.kwlist]
# self.file = open("file") :
# 1st 'file' colorized normal, 2nd as builtin, 3rd as string
builtin = r"([^.'\"\\#]\b|^)" + any("BUILTIN", builtinlist) + r"\b"
comment = any("COMMENT", [r"#[^\n]*"])
stringprefix = r"(\br|u|ur|R|U|UR|Ur|uR|b|B|br|Br|bR|BR|rb|rB|Rb|RB)?"
sqstring = stringprefix + r"'[^'\\\n]*(\\.[^'\\\n]*)*'?"
dqstring = stringprefix + r'"[^"\\\n]*(\\.[^"\\\n]*)*"?'
sq3string = stringprefix + r"'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
dq3string = stringprefix + r'"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
string = any("STRING", [sq3string, dq3string, sqstring, dqstring])
return kw + "|" + builtin + "|" + comment + "|" + string +\
"|" + any("SYNC", [r"\n"])
prog = re.compile(make_pat(), re.S)
idrog = re.compile(r"\s+(\w+)", re.S)
asprog = re.compile(r".*?\b(as)\b")
I am not sure if the separate definition for as is still needed, or is a
holdover from when 'as' was not a keyword except in certain contexts.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
> I can work with this (have not tried though), but there must be a
> more elegant solution than symlinking my way forward...
I don't really understand what you are trying to do, but I would advise
to use environment variables to control the behaviour of the fake scripts
in /usr/local/bin
In bash you can do
export PYVERSION=2.5
And from that time onwards everything defaults to python2.5.
note the ${PYVERSION} that I have included now in the sample scripts
below to select the python version.
I don't think you need to, but if you want to change the environment
variable inside python you can set environment variables with something like
os.environ.? Look at the docs.
Caveat1: I have not tested this, but it should work ok. The setup I use is
much simpler: just default to python2.7
Caveat2: Arch linux packagers dont use a consistent naming of things:
There exists /usr/bin/virtualenv3, but there does not exist
/usr/bin/sphinx-build3 (it is /usr/bin/sphinx-build)
Somebody should send a bug to the package maintainer.
PS: Once you setup a workaround to bypass all the python=python3 nonsense,
Arch Linux is a nice linux distro, the best out there. I will stick
to it.
HTH
/usr/local/bin/python===
#!/bin/bash
script=`readlink -f -- "$1"`
case "$script" in
/usr/bin*)
exec python3 "$@"
;;
esac
exec python${PYVERSION} "$@"
/usr/local/bin/virtualenv===
#!/bin/bash
script=`readlink -f -- "$1"`
case "$script" in
/usr/bin*)
exec virtualenv3 "$@"
;;
esac
exec virtualenv${PYVERSION} "$@"
Joep van Delft wrote:
> Hello Javier!
>
> Thanks, those links are helping a bit. And: yes, I am using Archlinux.
>
> But still those links assume that there are totally separate
> site-packages* directories installed for both. I am not sure how I
> would surpass this distinction between py-X.P and py-Y.Q.
>
> Should I really create a massive amount of symlinks like this?:
>
> | #!/usr/bin/zsh
> | for d in ~/src/mypackage/**/*(/); do
> |# matches all directories
> |mkdir -p "~/src/py-2.7/mypackage/${d#*src/mypackage}"
> |mkdir -p "~/src/py-3.4/mypackage/${d#*src/mypackage}"
> | done
> | for f in ~/src/mypackage/**/^*.pyc(.); do
> |# matches all files except for *.pyc
> |ln -s "$f" "~/src/py-2.7/mypackage${f#*src/mypackage}"
> |ln -s "$f" "~/src/py-3.4/mypackage${f#*src/mypackage}"
> | done
>
> ...and then set $PYTHONPATH according to the target version in a
> #!/usr/local/bin-script?
>
> I can work with this (have not tried though), but there must be a
> more elegant solution than symlinking my way forward...
>
> Cheers!
>
>
>Joep
>
--
https://mail.python.org/mailman/listinfo/python-list
Python package index in elasticsearch
Hi Being frustrated with speed and inflexibility of pip search, I played with elasticsearch and set up my own index. Maybe someone will find it useful too. Site:http://pypisearch.linuxcoder.co.uk Code: https://github.com/Fiedzia/pypisearch Full lucene syntax is allowed. Note: indexing is in progress, but over 60% of pypi packages are there, it should get to 100% within max few hours. Having the basics working, I hope to polish it soon. Maciej Dziardziel fied...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python package index in elasticsearch
On 18.7.2014 0:01, Maciej Dziardziel wrote: Hi Being frustrated with speed and inflexibility of pip search, I played with elasticsearch and set up my own index. Maybe someone will find it useful too. Site:http://pypisearch.linuxcoder.co.uk Code: https://github.com/Fiedzia/pypisearch Full lucene syntax is allowed. Note: indexing is in progress, but over 60% of pypi packages are there, it should get to 100% within max few hours. Having the basics working, I hope to polish it soon. Maciej Dziardziel fied...@gmail.com Looks great! -- https://mail.python.org/mailman/listinfo/python-list
L-system equations drawing tool
Hi, I wrote a small program to draw L-system equations using tkinter. You can find it on https://github.com/yasar11732/tklsystem It is still under development, but seems to be working nice so far. I could only try it on windows, but it should work on Linux too. You will need Python 3.x to run it. PIL/Pillow is optional but highly recommended. It allows faster rendering and ability to save images. You can also save your equations and load them later. Try it and comment it if you are interested. Bug reports and contributions are also welcome. -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17/07/2014 02:16, Rick Johnson wrote: On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote: Further the number of people assisting on the bug tracker at the moment appears to me to be going up, not down. It therefore strikes me that Python is extremely tenable, thus indicating that people are not falling for the FUD about Python 2 versus Python 3. Again, your "metrics", are tainted. I believe the spike in bug reports has less to do with: Where did I say anything about a spike in bug reports? There are a large number of open reports, but a backlog built up as the core developers were at one point having to commit changes to five different versions. Design work is being done to simplify this process and hence free up core developers' time. It will take time but in a year or three I expect to see the number of open bugs dropping considerably. "New community members jumping in to help" The above is true, greatly helped by the core mentorship mailing list. And more to do with: "Damn, this Python3 is buggy and i need to tell someone so i can get my customers off my back and this egg off my face, lest my feet move faster than Fred Flintstone!" Wrong, e.g. there were far more bug reports about encode or decode errors in Python 2 than we (the Python community) see for Python 3. -- 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: NaN comparisons - Call For Anecdotes
On Thu, Jul 17, 2014 at 3:08 PM, Marko Rauhamaa wrote: > Ian Kelly : > >> Well, 0**0 is usually defined as 1, despite the limits being >> ambiguous. > > https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml> > > But if it could be defined, what "should" it be? 0 or 1? I did say "usually". There's not one single Holy Keeper of the Definitions for mathematics. Wikipedia lists some differing opinions on the subject: http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero I note that mathworld.wolfram.com also lists it as undefined, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Thu, Jul 17, 2014 at 5:00 PM, Ian Kelly wrote: > On Thu, Jul 17, 2014 at 3:08 PM, Marko Rauhamaa wrote: >> Ian Kelly : >> >>> Well, 0**0 is usually defined as 1, despite the limits being >>> ambiguous. >> >> https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml> >> >> But if it could be defined, what "should" it be? 0 or 1? > > I did say "usually". There's not one single Holy Keeper of the > Definitions for mathematics. Wikipedia lists some differing opinions > on the subject: > > http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero > > I note that mathworld.wolfram.com also lists it as undefined, though. Incidentally, as noted in the Wikipedia article you left out some options -- it's not just between 0 or 1. It's also possible to derive a limit of positive infinity or any nonnegative real. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
In article , Ned Batchelder wrote: > On 7/17/14 11:32 AM, Joep van Delft wrote: > > Hello! > > > > The condensed version of the question would probably be: How does one > > deal with multiple interpreters and one package where you want to try > > some changes? > Virtualenv is definitely the right way to isolate different Python > environments from each other. Each one has its own PYTHONPATH, so each > project of yours can have different packages installed. Absolutely. Don't even consider any other alternative. Just do it. Our deployment process builds a new virtualenv for every release. Then you don't even have to think about what got added and what got deleted. We have a requirements file which we feed to pip and it creates exactly what we need for that release. We use wheel to speed things up, that's just an optimization. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/17/2014 2:15 PM, Rick Johnson wrote: a partial disinformation rant again Idle that repeats things said before, more than once. In general, your rants seem to serve the social purpose of providing cover to other people to join in loose, off-topic discussions. In this one, you align yourself with the 'private boys club' idle haters you profess to disdain. Some facts. Idlelib has about 60 modules. The tracker has, as I write, 133 open issues (behavior and enhancements, with the boundary sometimes fuzzy) marked Component: Idle. That is about two issues per module. It is definitely less than 1 bug per 100 lines. There is only 1 bug, Windows-specific, that routinely gets in my way. The stdlib has, I believe, less than 1000 modules. There are right now 4545 open issues, or at least 4, maybe more, per module. Anyone who calls Idle (or anything else) 'buggy' and 'embarassing' should do some research and say 'compared to what' and 'by what standard'. Last January, I discovered that tokenize.untokenize had about 5 bugs in about 25 lines of code. The new mode was hardly usable. I think *that* could be called 'embarassing' -- compared to the rest of the stdlib and by the standard of being basically usable. I fixed all but 1 of the implementation bugs. More facts. Since 2.7 was released in July 2010, there have been 94 issues with improvements recorded in idlelib/news.txt (extracted from the 2.7 news/changelog). (Some issues have multiple patches, and some patches no recorded issue, but we can stick with the recorded issue count.) Has the patch rate gone down or up? Over half (46) of the issue patches are recorded in the last 15 months out of 48, less than a third, after the release of 2.7.5 on 2013 April 4. The reason for the uptick is PEP 434, which ended the blockage of Idle patches by useless debates over 'behavior' versus 'enhancement' and backport or not'. It also ended (most of) the Idle hate rants on pydev. Sadly, all of my calls to improve IDLE have been meet with rebukes about me "whining". Each of the 133 issues on the tracker is a specific, usually actionable, 'call' to improve Idle. They are gradually being attended to. Generic 'calls for improvement' on this list are useless. > The "powers that be" When it comes to Idle, that means me as much as anyone. would wise to *UTILIZE* and *ENCOURAGE* my participation Still more facts ;-). About three (four?) years ago, you posted a similar rant. Being wise, I encouraged your participation and utilized the patch you anonymously posted on the tracker (to maintain your Ranting Rick pose) in one of my first commits. I invite you to resume your participation, either anonymously or openly. As before, you can email me privately to discuss what would best suite you and also be helpful. I will mention that one barrier to improving Idle code, beyond making small local fixes, is the need for automated tests before refactoring. I started a unittest suite in May 2013 with the help of GSOC (Google Summer of Code) students. In May 2014, this year's student and I collected together and improved the human-run tests. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On 7/17/14, 12:30 PM, Rick Johnson wrote: You know, you would fit in nicely in the American public school system, since American teachers are not only free of the requirement of "teaching", they are actually*COMPELLED* not to do so by the greedy unions. Hi Rick, I know a lot of American public school teachers, and they are among the hardest-working people I've ever encountered. I have no clue what you mean about them being free of the requirement to teach. Do you find that insulting people achieves your goals? Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 18/07/2014 01:13, Terry Reedy wrote: On 7/17/2014 2:15 PM, Rick Johnson wrote: a partial disinformation rant again Idle that repeats things said before, more than once. Still more facts ;-). About three (four?) years ago, you posted a similar rant. Being wise, I encouraged your participation and utilized the patch you anonymously posted on the tracker (to maintain your Ranting Rick pose) in one of my first commits. I invite you to resume your participation, either anonymously or openly. As before, you can email me privately to discuss what would best suite you and also be helpful. I'm looking forward to see the massive number of fixes that come from rr, assuming of course that he signs the CLA to make this possible. Or has he already done so? -- 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.17 19:26, Mark Lawrence wrote: > I'm looking forward to see the massive number of fixes that come from > rr, assuming of course that he signs the CLA to make this possible. Or > has he already done so? > Maybe he's too busy working on RickPy 4000 (or whatever it was called). -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
On 18/07/2014 9:44 AM, Roy Smith wrote: In article , Ned Batchelder wrote: Virtualenv is definitely the right way to isolate different Python environments from each other. Absolutely. Don't even consider any other alternative. Just do it. Not even buildout? :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
In article , alex23 wrote: > On 18/07/2014 9:44 AM, Roy Smith wrote: > > In article , > > Ned Batchelder wrote: > >> Virtualenv is definitely the right way to isolate different Python > >> environments from each other. > > > > Absolutely. Don't even consider any other alternative. Just do it. > > Not even buildout? :) OK, I will admit I'm not familiar with buildout. Perhaps I should have said, "Don't even consider trying to manage all this stuff manually. -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Fri, Jul 18, 2014 at 5:30 AM, Rick Johnson wrote: > But don't tell me for a *SECOND* that a colorizer, and a > damn good one, can not be written utilizing regexps, because > you're either wrong, or you're scared, or you're ignorant, > or you're all of the above! It might well be able to *utilize* regexps (as Terry showed, the one in idlelib apparently does use them), but very few modern programming languages can be fully and correctly defined within the limits of regexp syntax. For instance, how can you recognize and thus colorize assignments differently from name references, to distinguish between "foo = 1" and "foo == 1"? Can you do that with a regexp? And there's plenty more syntax that's tricky to define. I might be wrong, and I might be ignorant, but I'm not scared. I know what a regular expression can and can't do, and it's not fear to avoid using them for jobs they can't do. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Fri, Jul 18, 2014 at 7:46 AM, Terry Reedy wrote:
> # self.file = open("file") :
> # 1st 'file' colorized normal, 2nd as builtin, 3rd as string
Is this pair of comments a hold-over from when it was common to use
the file() constructor? Looks like it got searched-and-replaced.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
When I say i suck at finding good creative ideas I dont mean like I can think of anything its more like i cant think of anything that is within my scope of skill. These ideas are great guys thanks. Also the gui tool kit i used for the apps is tkinter because i am reading a book about python and it covers that tool kit. Also i like this idea of ssh'ing to a server where i could have a python program that allows files to be uploaded to a database and brought down from the data base. I am just not so good with the hardware so I dont really now how to create one. Also I wouldnt mind putting more functionality into my programs and stuff that sounds alright and also re inventing the wheel sounds like good practise. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Fri, Jul 18, 2014 at 7:30 AM, Terry Reedy wrote: > That is something of a problem as people 'graduate' to multi-language > environments. However, while I have programmed in about 20 languages during > my lifetime, I have now 'contracted' to using only Python (except for the > occasional .bat file). So I use Idle to work on both my own stuff and on > fixing Idle. When I notice an issue while working on an issue, I file a new > issue. Glad to hear it. Best way to make sure Idle stays developed is for its core developers to actively use it. For myself, though, I completely do not use the editor half of it; but it's spectacularly useful (with limitations) as my primary interactive interpreter. That's partly because, on Windows, the command-line interpreter absolutely *sucks* (because most of its UI comes from cmd.exe - my view might be different if I had a different shell, but there's no point because Idle just blows it away), and partly because command recall/editing works on entire syntactic units rather than on lines. In fact, if I were to name *one single feature* that made Idle useful rather than a mere toy, it would have to be the ability to recall an entire function/class definition from command history for further editing. That is hugely helpful to me. It's what makes Python actually 100% usable in interactive mode - go right ahead, define functions and classes just as you would in a file! (Okay, you have to watch out about blank lines. Not usually an issue, but you'll possibly notice that I seldom have any internal blanks when I post a class definition on-list - it's because I usually write them in Idle.) The only problem I have with it is that blatting ridiculous amounts of text to the console can take a very long time, esp on Windows. If I accidentally display a large object when I thought I was displaying a small one, it'll hang for quite a while, churning through something, and it's not easy to see why or to halt it. But I suspect that's more of a Windows and/or Tk issue than an Idle one. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote: > Rick Johnson : > > Sure, IDLE is not *useless*, however, it is in fact > > woefully inadequate and should be embarrassing to the > > whole community, both in it's buggy-ness and it's poorly > > written source code. > This is beneath trolling. Redeem yourself by apologizing. Apologize for what? For telling the truth? I have been using IDLE since around 2006, well at least, that is as far back as i remember. When i first learned Python, IDLE was my editor of choice, and i *STILL* use IDLE to this very day! -- although not as much as i have written my own IDE. I have logged thousands upon thousands of hours with IDLE, how many hours have *YOU* logged? I would even venture to say, and the comments on this list have supported my evidence for years, that i may be the *SOLE* heavy user of IDLE in the *ENTIRE* community. Although, i need to compare my stats with Terry because he claims to use the software quite often also. If *ANYBODY* in this damn community has a *RIGHT* to complain about IDLE, then *I* am that person. HOW DARE YOU chastise me for voicing my grievances regarding a software that *YOU* most likely have *NEVER*, or only *SLIGHTLY*, used! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Fri, Jul 18, 2014 at 12:24 PM, Rick Johnson wrote: > I would even venture to say, and the comments on this list > have supported my evidence for years, that i may be the > *SOLE* heavy user of IDLE in the *ENTIRE* community. > ... > > If *ANYBODY* in this damn community has a *RIGHT* to > complain about IDLE, then *I* am that person. HOW DARE YOU > chastise me for voicing my grievances regarding a > software that *YOU* most likely have *NEVER*, or only > *SLIGHTLY*, used! Even if it is true that you're the only *user* of IDLE (or Idle; Terry seems to spell it the latter way, I'm not sure what's the official recommendation now), that does not give you any right whatsoever to complain about it. There are two valid reasons for claiming a right to complain: 1) You are the primary *developer* of the system, and put in many hours of work actually making it happen; or 2) You have paid money to someone, paying them a reasonable hourly rate for the same sort of level of work. So I would say Terry has a right to complain. I certainly don't, even though it's my primary Windows Python interface (on Linux boxes, I usually use 'python' or 'python3' in a regular xfce4-terminal; I do use IDLE on Linux as well, but not as often and certainly not as my primary interface to Python). To me, IDLE is a gift; a freely-granted boon to my use of this language. It's a huge step up from REXXTry (or even EREXXTry, the 'extended' version that has decent command-line editing tools); due to limitations on the REXX 'INTERPRET' command, it's impossible to define functions interactively, and a few other things. (That said, though, EREXXTry was for over a decade my sole interactive interpreter for any language. It was either that or save something to a file and run it.) Do I whine and complain because my gift isn't absolutely perfect? No. I might *humbly* open a discussion, but it's with the attitude of "these people have given hugely of their time" rather than "these people have done something which is WRONG". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiple python versions, one dev environment???
On Fri, Jul 18, 2014 at 11:29 AM, Roy Smith wrote: > In article , alex23 > wrote: > >> On 18/07/2014 9:44 AM, Roy Smith wrote: >> > In article , >> > Ned Batchelder wrote: >> >> Virtualenv is definitely the right way to isolate different Python >> >> environments from each other. >> > >> > Absolutely. Don't even consider any other alternative. Just do it. >> >> Not even buildout? :) > > OK, I will admit I'm not familiar with buildout. > > Perhaps I should have said, "Don't even consider trying to manage all > this stuff manually. I'd put this on par with source control. You'll see arguments about whether git or hg is the better option, but frankly, either of them (or bzr, or any of a bunch of others) is just so far ahead of *not* using source control that it's less important to distinguish than to say "Don't even consider trying to do this manually". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 17/07/2014 1:14 PM, Steven D'Aprano wrote: There will never be a Python 2.8. When push comes to shove, the people bitching about Python 3 will not do the work necessary to fork Python 2.7 and make a version 2.8. +1 The idea that forking and maintaining Python 2.8 is somehow _less effort_ than porting code to Python 3.x is batshit crazy. The Py2.8 claims seem to me to be nothing more than a shallow attempt to blackmail the core devs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 18/07/2014 10:26 AM, Mark Lawrence wrote: I'm looking forward to see the massive number of fixes that come from rr I'm still waiting for RickPython, the One True Python. Remember when he used to rant as if he was actually working on it and not just pissing in the wind? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 18/07/2014 10:45 AM, Andrew Berg wrote: Maybe he's too busy working on RickPy 4000 (or whatever it was called). I believe the new working name is PypeDream. -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thursday, July 17, 2014 9:03:40 PM UTC-5, Chris Angelico wrote: > [colorizers] might well be able to *utilize* regexps [...] > but very few modern programming languages can be fully and > correctly defined within the limits of regexp syntax. We're not talking about "defining" or "interpreting" languages Chris, we're simply talking about "colorizers" -- which simply search for lexical patterns and apply *COLOR* to the resulting matches! PAY ATTENTION! > For instance, how can you recognize and thus colorize > assignments differently from name references, to > distinguish between "foo = 1" and "foo == 1"? First of all, why the heck would want to colorize something like that? And if your intention is "highlight" cases where a programmer uses "==" in a condition, then you need to use a "source code analyzer", like Pylint! Secondly, as the number of colorizer targets increases, the effectiveness of colored text decreases -- from a "human comprehension" perspective that is. For me, only the following targets need colorizing: Keywords Built-ins Terminated Strings Un-terminated Strings Comments Annotations That's it! Anymore color and your code starts to resemble a Pollock drip painting. Now, finally, if you cannot write a regexp that matches: 1. One or more alphanumeric chars(or the US) followed by zero or more spaces followed by two equals chars followed by zero or more spaces followed by one or more alphanumeric chars(or the US) or 2. One or more alphanumeric_chars(or the US) followed by zero or more spaces followed by one equals char followed by zero or more spaces, followed by one or more alphanumeric chars(or the US) Then you are either joking or trolling or you need to read the Python re docs. https://docs.python.org/2/library/re.html#module-re -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Fri, Jul 18, 2014 at 1:07 PM, Rick Johnson wrote: > For me, only the following targets need colorizing: > > Keywords > Built-ins And be sure *not* to colorize built-ins (but *do* colorize keywords) in contexts where the tokens are actually identifiers, like "x.open = 1". Plus, if you want this to be truly general, you need to have it understand that some keywords aren't keywords if the shebang is different, although with 2.7 vs 3.4 that only really applies to nonlocal (if True/False/None are colored as keywords even though they're technically builtins, that's not a big deal); if you want to support Python 2.5, you'd also have to cope with a __future__ directive adding a keyword, but that's quite optional. It's not as simple as you might think. I've worked with plenty of syntax highlighters that get something wrong in some context, and it's extremely annoying; in some cases it makes the colorization actually harmful, rather than helpful. And it's absolutely *essential* that the lexer and the language agree on, for instance, what characters constitute identifiers; if I have a partially non-ASCII variable name and only the ASCII half of it gets highlighted, that can be highly distracting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thu, Jul 17, 2014 at 7:49 PM, alex23 wrote: > On 17/07/2014 1:14 PM, Steven D'Aprano wrote: >> >> There will never be a Python 2.8. When push comes to shove, the people >> bitching about Python 3 will not do the work necessary to fork Python 2.7 >> and make a version 2.8. > > > +1 > > The idea that forking and maintaining Python 2.8 is somehow _less effort_ > than porting code to Python 3.x is batshit crazy. Probably. I'd say that if anything kills Python, it'll be the people who are afraid of a small dose of positive change. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote: > For myself, though, I completely do not use the editor half of [IDLE]; but > it's spectacularly useful (with limitations) as my primary interactive > interpreter. Yes Chris, i also think that the IDLE shell is "spectacular" when i'm using it, especially when i press "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND* the start of the interactive command marker " >>>", an area where key presses are not allowed, so *NOW* I must press "CONTROL+RIGHT_ARROW" three times to get to my destination! I'm also just "gushing with exuberance" when i open a new block and i get *EIGHT SPACE INDENTION*! And I get a raging semi each time IDLE hangs between run sessions when i'm editing Tkinter code, yes Chris, I GET A BIG FAT ERECTION! Sometimes, when it does not go away after four hours, i have to visit the local emergency room and take some pills. THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS! I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER! MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE? > [...] The only problem I have with it is that blatting > ridiculous amounts of text to the console can take a very > long time, esp on Windows. If I accidentally display a > large object when I thought I was displaying a small one, > it'll hang for quite a while, churning through something, > and it's not easy to see why or to halt it. But I suspect > that's more of a Windows and/or Tk issue than an Idle one. The *PROBLEM* is that user has no method of "undo-ing" an accidental display of huge amounts of data , forcing the user to close and then re-open the entire software -- can you understand now *WHY* i complain about this software? This is *EMBARRASSING*, and you should *ALL* be ashamed that, not only does Python include such an amateurish piece of crap software, but it has been there for years! UNCHANGED FOR YEARS!!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 07/17/2014 08:24 PM, Rick Johnson wrote: > i *STILL* use IDLE > to this very day! -- although not as much as i have written > my own IDE. Maybe you should release it so we can make demands of you without bothering to contribute to it's development, either in code, or in bug reports. -- https://mail.python.org/mailman/listinfo/python-list
Re: I need an idea for practise!
On Thursday, July 17, 2014 10:23:50 PM UTC-5, Chris Angelico wrote: > And be sure *not* to colorize built-ins (but *do* colorize > keywords) in contexts where the tokens are actually > identifiers, like "x.open = 1". Just check for word boundaries on all your keywords and built-ins and you're *DONE*! > Plus, if you want this to be truly general, you need to > have it understand that some keywords aren't keywords if > the shebang is different, although with 2.7 vs 3.4 that > only really applies to nonlocal (if True/False/None are > colored as keywords even though they're technically > builtins, that's not a big deal); if you want to support > Python 2.5, you'd also have to cope with a __future__ > directive adding a keyword, but that's quite optional. > It's not as simple as you might think. Stop it, you're embarrassing yourself with all this rambling! You should have shut up a long time ago. Just like the thread where you embarrassed yourself with your limited knowledge of IDLE[1] and Tkinter, you're now really loosing all respect as a competent programmer if you cannot even write these "simple" regexps. > I've worked with plenty of syntax highlighters that get > something wrong in some context, and it's extremely > annoying; in some cases it makes the colorization actually > harmful, rather than helpful. And it's absolutely > *essential* that the lexer and the language agree on, for > instance, what characters constitute identifiers; if I > have a partially non-ASCII variable name and only the > ASCII half of it gets highlighted, that can be highly > distracting. Oh i get it now, your confusing Python with REXX again... *face palm* [1] Heck, you don't even realize that IDLE and an "acronym". -- https://mail.python.org/mailman/listinfo/python-list
OT - information theory thing...
I'm trying to remember something I read one night to do with information theory to vague for Google to help much. If anyone could help me remember that would be wonderful! It had something to do with the fact that, given a transmission medium, you can control whether information flows or not, but it is impossible to control *what* information flows. (Due to the possibility of nested encoding, stenography, etc.) Was this a Claude Shannon thing or Alan Turing or... I really don't recall. Thoughts? Cheers! -Modulok- -- https://mail.python.org/mailman/listinfo/python-list
Re: Python package index in elasticsearch
In article , Maciej Dziardziel wrote: > Being frustrated with speed and inflexibility of pip search, I played with > elasticsearch and set up my own index. > Maybe someone will find it useful too. > > Site:http://pypisearch.linuxcoder.co.uk > > Code: https://github.com/Fiedzia/pypisearch > > Full lucene syntax is allowed. > > Note: indexing is in progress, but over 60% of pypi packages are there, > it should get to 100% within max few hours. Nice. But you should take a look at Warehouse, which is the anticipated replacement for PyPI. Perhaps you can give Donald a hand. https://warehouse.python.org https://pypi.python.org/pypi/warehouse -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
