Re: Python Front-end to GCC
On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle wrote: > On 10/20/2013 3:10 PM, [email protected] wrote: > > > On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote: > > >> I've been working on GCCPY since roughly november 2009 at least in its > > >> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 > > >> project. I was mentored by Ian Taylor who has been an extremely big > > >> influence on my software development carrer. > > > > > > Cool! > > > > > >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. > > >> (Although this is sparse partialy on purpose since i do not wan't > > >> people thinking this is by any means ready to compile real python > > >> applications) > > > > > > Is there any document describing what it can already compile and, if > > possible, showing some benchmarks? > > > > After reading through a vast amount of drivel below on irrelevant > > topics, looking at the nonexistent documentation, and finally reading > > some of the code, I think I see what's going on here. Here's > > the run-time code for integers: > > > > http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c > > > >The implementation approach seems to be that, at runtime, > > everything is a struct which represents a general Python object. > > The compiler is, I think, just cranking out general subroutine > > calls that know nothing about type information. All the > > type handling is at run time. That's basically what CPython does, > > by interpreting a pseudo-instruction set to decide which > > subroutines to call. > > > >It looks like integers and lists have been implemented, but > > not much else. Haven't found source code for strings yet. > > Memory management seems to rely on the Boehm garbage collector. > > Much code seems to have been copied over from the GCC library > > for Go. Go, though, is strongly typed at compile time. > > > >There's no inherent reason this "compiled" approach couldn't work, > > but I don't know if it actually does. The performance has to be > > very low. Each integer add involves a lot of code, including two calls > > of "strcmp (x->identifier, "Int")". A performance win over CPython > > is unlikely. > > > >Compare Shed Skin, which tries to infer the type of Python > > objects so it can generate efficient type-specific C++ code. That's > > much harder to do, and has trouble with very dynamic code, but > > what comes out is fast. > > > > John Nagle I think your analysis is probably grossly unfair for many reasons. But your entitled to your opinion. Current i do not use Bohem-GC (I dont have one yet), i re-use principles from gccgo in the _compiler_ not the runtime. At runtime everything is a gpy_object_t, everything does this. Yeah you could do a little of dataflow analysis for some really really specific code and very specific cases and get some performance gains. But the problem is that the libpython.so it was designed for an interpreter. So first off your comparing a project done on my own to something like cPython loads of developers 20 years on my project or something PyPy has funding loads of developers. Where i speed up is absolutely no runtime lookups on data access. Look at cPython its loads of little dictionaries. All references are on the Stack at a much lower level than C. All constructs are compiled in i can reuse C++ native exceptions in the whole thing. I can hear you shouting at the email already but the middle crap that a VM and interpreter have to do and fast lookup is _NOT_ one of them. If you truely understand how an interpreter works you know you cant do this Plus your referencing really old code on sourceforge is another thing. And i dont want to put out bench marks (I would get so much shit from people its really not worth it) but it i can say it is faster than everything in the stuff i compile so far. So yeah... not only that but your referncing a strncmp to say no its slow yeah it isn't 100% ideal but in my current git tree i have changed that. So i think its completely unfair to reference tiny things and pretend you know everything about my project. One thing people might find interesting is class i do data flow anaylsis to generate a complete type for that class and each member function is a compiled function like C++ but at a much lower level than C++. The whole project has been about stripping out the crap needed to run user code and i have been successful so far but your comparing a in my spare time project to people who work on their stuff full time. With loads of people etc. Anyways i am just going to stay out of this from now but your email made me want to reply and rage. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Tue, 22 Oct 2013 09:38:16 +0200, Lele Gaifax wrote: > Roy Smith writes: > >> You missed the ever-so-special Objective C syntax: [...] > The actual syntax would be > > [object method: arg1 withSomething: arg2 withSomethingElse: arg3] I don't get how to map that to Python's syntax. object.method(arg1, arg2, arg3) What are "withSomething" and "withSomethingElse"? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 23/10/2013 08:25, Philip Herron wrote: Personally I have no interest in your project but do wish you the best of luck with your endeavours. However I do have a personnal interest in my eyesite, which gets strained by reading posts such as yours. In order to assist me in looking after my health, would you please be kind enough to read, digest and action this https://wiki.python.org/moin/GoogleGroupsPython. TIA. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On 10/23/13 4:16 AM, Steven D'Aprano wrote: On Tue, 22 Oct 2013 09:38:16 +0200, Lele Gaifax wrote: Roy Smith writes: You missed the ever-so-special Objective C syntax: [...] The actual syntax would be [object method: arg1 withSomething: arg2 withSomethingElse: arg3] I don't get how to map that to Python's syntax. object.method(arg1, arg2, arg3) What are "withSomething" and "withSomethingElse"? The Python would be: object.method(arg1, withSomething=arg2, withSomethingElse=arg3) --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
Steven D'Aprano wrote: On Tue, 22 Oct 2013 09:38:16 +0200, Lele Gaifax wrote: The actual syntax would be [object method: arg1 withSomething: arg2 withSomethingElse: arg3] I don't get how to map that to Python's syntax. It's roughly morally equivalent to object.method(arg1, withSomething = arg2, withSomethingElse = arg3) But there are several reasons why it's not really equivalent to that. PyObjC actually maps it to object.method_withSomething_withSomethingElse_(arg1, arg2, arg3) which is very close to what Objective C is doing under the hood. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Will Python 3.x ever become the actual standard?
I am starting to have doubts as to whether Python 3.x will ever be actually adopted by the Python community at large as their standard. Years have passed, and a LARGE number of Python programmers has not even bothered learning version 3.x. Why am I bothered by this? Because of lot of good libraries are still only for version 2.x, and there is no sign of their being updated for v3.x. I get the impression as if 3.x, despite being better and more advanced than 2.x from the technical point of view, is a bit of a letdown in terms of adoption. -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing the terminal title bar with Python
[email protected] writes: > On Friday, October 18, 2013 12:46:19 PM UTC-4, Steven D'Aprano wrote: > >> xterms used to have a feature where they would write the title back to >> standard input. Unfortunately, it has been disabled for security reasons, >> so I haven't been able to get this to work (not that I tried very >> hard...), but you might like to experiment with this: > > Actually in "xterm" it is configurable (the allowWindowOps resource). > xterm "emulators" lack that (and most of xterm's) configurability. Curious. I was able to do the title store and restore after allowing WindowOps in xterm version 278 (from the ctrl-rightclick menu) but reading the title didn't work any better. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23 October 2013 22:57, wrote: > > a LARGE number of Python programmers has not even bothered learning version > 3.x. OMG. Please provide their names. We'll send Doug & Dinsdale. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 12:57, [email protected] wrote: Years have passed, and a LARGE number of Python programmers has not even bothered learning version 3.x. The changes aren't large enough to worry a Python programmer so effectively there's nothing to learn, other than how to run 2to3. ...there is no sign of their being updated for v3.x. Could have fooled me. The number is growing all the time. The biggest problem is likely (IMHO) to be the sheer size of the code base and limitations on manpower. I get the impression as if 3.x, despite being better and more advanced than 2.x from the technical point of view, is a bit of a letdown in terms of adoption. I agree with this technical aspect, other than the disastrous flexible string representation, which has been repeatedly shot to pieces by, er, one idiot :) As for adaption we'll get there so please don't do a Captain Mainwearing[1] and panic. People should also be pursuaded by watching this from Brett Cannon http://www.youtube.com/watch?v=Ebyz66jPyJg Just my 2 pence worth. [1] From the extremely popular BBC TV series "Dad's Army" of the late 60s and 70s. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 2013-10-23, David wrote: > On 23 October 2013 22:57, wrote: >> >> a LARGE number of Python programmers has not even bothered learning version >> 3.x. > > OMG. Please provide their names. We'll send Doug & Dinsdale. I can send Mr. Wendt and Mr. Kidd. Or are those guys dead? -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wed, Oct 23, 2013 at 11:16 PM, David wrote: > On 23 October 2013 22:57, wrote: >> >> a LARGE number of Python programmers has not even bothered learning version >> 3.x. > > OMG. Please provide their names. We'll send Doug & Dinsdale. Who and who? Re the subject line: As far as I'm concerned, it already is. Just use it, now it's standard. That's what it takes... and that's all it takes. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 13:16, David wrote: On 23 October 2013 22:57, wrote: a LARGE number of Python programmers has not even bothered learning version 3.x. OMG. Please provide their names. We'll send Doug & Dinsdale. Please ensure that they're accompanied by the chief constable carrying the tactical thermonuclear missile just in case of trouble as sometimes the combination of nailing heads to coffee tables and sarcasm just isn't enough. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
In article <[email protected]>, [email protected] wrote: > I am starting to have doubts as to whether Python 3.x will ever be actually > adopted by the Python community at large as their standard. Years have > passed, and a LARGE number of Python programmers has not even bothered > learning version 3.x. Why am I bothered by this? Because of lot of good > libraries are still only for version 2.x, and there is no sign of their being > updated for v3.x. It's a chicken-and-egg thing. People aren't moving because the libraries they depend on don't yet support P3, so there's not a lot of people using P3, so there's not a lot of pressure for libraries to support it, etc. Here's our list of external Python dependencies (mostly installed with pip, a few of the harder to build ones we install as binaries with apt-get). I'll annotate them with what P3 support is available. I'm doing this quickly, so may not be 100% accurate (and I ran out of time, so I started just looking at the major ones): argparse==1.2.1 # included in P3 beanstalkc==0.3.0 # no support blinker==1.2 # P3 supported boto==2.5.1 # no support dateglob==0.1 # no support, probably not critical decorator==3.3.3 # P3 supported django==1.4.5 # P3 support in 1.6 (RC just released) django-multi-sessions==0.1.0# no support, probably not critical django-timedeltafield==0.7.0# no support, probably not critical dnspython==1.11.0 # P3 supported elasticsearch==0.4.2 # no support (unclear) Fabric==1.7.0 # "eventual Python 3.x compatibility" gevent==0.13.8# no support grequests==0.2.0 # no support gunicorn==0.17.4 # P3 supported jellyfish==0.2.0 # no support Jinja2==2.7.1 # "upcoming" support for P3 leveldb==0.19 # no support lxml==2.2.4 # P3 supported markdown==2.3.1 MarkupSafe==0.18 mongoengine==0.7.10 # P3 support on the roadmap for 0.9 release mrjob==0.4 msgpack-python==0.3.0 nose==1.3.0 numpy==1.6.1 # "some [...] packages still only work on Python 2" pandas==0.9.1 paramiko==1.11.0 Paste==1.7.2 PIL==1.1.7 prettytable==0.7 psycopg2==2.5 pyasn1==0.1.7 pymongo==2.5.2 # P3 supported pyparsing==1.5.2 pysnmp==4.2.3 python-cjson==1.0.5 python-dateutil==1.4.1 python-memcached==1.53 pytz==2010b pyzmq==13.1.0 requests==1.2.0 # P3 supported rpclib==2.7.0-beta scipy==0.9.0 setproctitle==1.1.6 statsd==2.0.3 suds==0.4 tornado==3.1 ujson==1.23 Unidecode==0.04.5 unittest2==0.5.1 > I get the impression as if 3.x, despite being better and > more advanced than 2.x from the technical point of view, is a bit of a > letdown in terms of adoption. I would agree. I think the handwriting is on the wall that we'll get there eventually, but it's taking a lot longer than I would have expected. I think we're at the point where most major projects either already support P3, or at least have it on their roadmaps, and people learning Python in school are starting to be taught P3 instead of P2. But I think we're not going to see P3 be the predominant version for several more years. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 8:35 AM, Mark Lawrence wrote: On 23/10/2013 12:57, [email protected] wrote: Years have passed, and a LARGE number of Python programmers has not even bothered learning version 3.x. The changes aren't large enough to worry a Python programmer so effectively there's nothing to learn, other than how to run 2to3. ...there is no sign of their being updated for v3.x. Could have fooled me. The number is growing all the time. The biggest problem is likely (IMHO) to be the sheer size of the code base and limitations on manpower. I get the impression as if 3.x, despite being better and more advanced than 2.x from the technical point of view, is a bit of a letdown in terms of adoption. I agree with this technical aspect, other than the disastrous flexible string representation, which has been repeatedly shot to pieces by, er, one idiot :) As for adaption we'll get there so please don't do a Captain Mainwearing[1] and panic. People should also be pursuaded by watching this from Brett Cannon http://www.youtube.com/watch?v=Ebyz66jPyJg Just my 2 pence worth. [1] From the extremely popular BBC TV series "Dad's Army" of the late 60s and 70s. It would be good if more of the packages were available, for Python 3.3, in binary for the Windows user. I am currently wrestling with Pandas, lxml etc. Colin W. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 14:05, Colin J. Williams wrote: > On 23/10/2013 8:35 AM, Mark Lawrence wrote: >> On 23/10/2013 12:57, [email protected] wrote: >>> Years have passed, and a LARGE number of Python programmers has not >>> even bothered learning version 3.x. >> >> The changes aren't large enough to worry a Python programmer so >> effectively there's nothing to learn, other than how to run 2to3. >> >>> ...there is no sign of their being updated for v3.x. >> >> Could have fooled me. The number is growing all the time. The biggest >> problem is likely (IMHO) to be the sheer size of the code base and >> limitations on manpower. >> >>> I get the impression as if 3.x, despite being better and more advanced >>> than 2.x from the technical point of view, is a bit of a letdown in >>> terms of adoption. >> >> I agree with this technical aspect, other than the disastrous flexible >> string representation, which has been repeatedly shot to pieces by, er, >> one idiot :) As for adaption we'll get there so please don't do a >> Captain Mainwearing[1] and panic. People should also be pursuaded by >> watching this from Brett Cannon >> http://www.youtube.com/watch?v=Ebyz66jPyJg >> >> Just my 2 pence worth. >> >> [1] From the extremely popular BBC TV series "Dad's Army" of the late >> 60s and 70s. >> > It would be good if more of the packages were available, for Python 3.3, > in binary for the Windows user. > > I am currently wrestling with Pandas, lxml etc. Can I assume you're aware of the industrious Christopher Gohlke? http://www.lfd.uci.edu/~gohlke/pythonlibs/ TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Skybuck Flying schrieb: This hereby indicates problems with the while loop: it makes little sense to put the exiting conditions at the top. Why? ... dec rcx jbe 1f 0:some code to perform ... jmp 0b p2align 5,,31 1:continue with something else ... This code triggers one penalty if RCX was zero or negative (it jumps directly to label 1 after the penalty for the wrong assumption "not taken" passed by), or two penalties if RCX was positive - one for the 2nd assumption is "taken", one for the finally taken conditional jump. The same applies if you moved the condition check to the end of the loop, but you could not catch negative numbers / zero without executing the code in the loop at least once. There is no general rule which construct should be preferred. In the end, the one suiting your needs might be the best choice. On the other hand, no one is able to predict which code might be generated by a specific HLL-compiler. Greetings from Augsburg Bernhard Schornak -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 14:13, Tim Golden wrote: On 23/10/2013 14:05, Colin J. Williams wrote: It would be good if more of the packages were available, for Python 3.3, in binary for the Windows user. I am currently wrestling with Pandas, lxml etc. Can I assume you're aware of the industrious Christopher Gohlke? http://www.lfd.uci.edu/~gohlke/pythonlibs/ TJG Thankfully I am. I confess I don't understand how *nix people endure having to compile code instead of having a binary install. To me it's like going to the garage to buy a new car, being shown the parts and the tool kit and being told to get on with it. Perhaps it's a case of second class treatment for users of a second class OS? Ducks and runs for cover :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 14:52, Skip Montanaro wrote: >> Thankfully I am. I confess I don't understand how *nix people endure having >> to compile code instead of having a binary install. To me it's like going >> to the garage to buy a new car, being shown the parts and the tool kit and >> being told to get on with it. Perhaps it's a case of second class treatment >> for users of a second class OS? Ducks and runs for cover :) > > And we can't understand how you can put up without source. :-) Also, > Unix isn't one platform like Windows, ABI incompatibility and all. > > Really, for most things these days it's just > > pip install foo Disregarding Mark's tongue-in-cheek rhetoric for now... perhaps you didn't realise that, on Windows, you can't pip install a binary (that's a problem the new wheel format is solving). And, even if you have the correct compiler toolchain, building more complex packages from source can be daunting, essentially because of the lack of standard source layout on Windows. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 14:52, Skip Montanaro wrote: Thankfully I am. I confess I don't understand how *nix people endure having to compile code instead of having a binary install. To me it's like going to the garage to buy a new car, being shown the parts and the tool kit and being told to get on with it. Perhaps it's a case of second class treatment for users of a second class OS? Ducks and runs for cover :) And we can't understand how you can put up without source. :-) Also, Unix isn't one platform like Windows, ABI incompatibility and all. Really, for most things these days it's just pip install foo Skip Which on Windows often ends up telling you that it can't find vcvarsall.bat, i.e. you don't have the appropriate version (if any) of the compiler installed. You then realise your mistake, go to the bookmarked link Tim Golden referred to earlier, and a minute or two later job done. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On 2013-10-23, Ned Batchelder wrote: > On 10/23/13 4:16 AM, Steven D'Aprano wrote: >> On Tue, 22 Oct 2013 09:38:16 +0200, Lele Gaifax wrote: >> >>> Roy Smith writes: >>> You missed the ever-so-special Objective C syntax: >> [...] >>> The actual syntax would be >>> >>>[object method: arg1 withSomething: arg2 withSomethingElse: arg3] >> I don't get how to map that to Python's syntax. >> >> object.method(arg1, arg2, arg3) >> >> What are "withSomething" and "withSomethingElse"? > > The Python would be: > > object.method(arg1, withSomething=arg2, withSomethingElse=arg3) FWIW, the Objective C syntax and semantics are both based on Smalltalk (which, IMO, is a somewhat easier to understand than OC). -- Grant Edwards grant.b.edwardsYow! He is the MELBA-BEING at ... the ANGEL CAKE gmail.com... XEROX him ... XEROX him -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 15:01, Tim Golden wrote: On 23/10/2013 14:52, Skip Montanaro wrote: Thankfully I am. I confess I don't understand how *nix people endure having to compile code instead of having a binary install. To me it's like going to the garage to buy a new car, being shown the parts and the tool kit and being told to get on with it. Perhaps it's a case of second class treatment for users of a second class OS? Ducks and runs for cover :) And we can't understand how you can put up without source. :-) Also, Unix isn't one platform like Windows, ABI incompatibility and all. Really, for most things these days it's just pip install foo Disregarding Mark's tongue-in-cheek rhetoric for now... Never :) perhaps you didn't realise that, on Windows, you can't pip install a binary (that's a problem the new wheel format is solving). And, even if you have the correct compiler toolchain, building more complex packages from source can be daunting, essentially because of the lack of standard source layout on Windows. TJG Thanks for the heads up. I didn't realise that wheel solved this problem. From my viewpoint thats the bee's knees. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
Tim: > Disregarding Mark's tongue-in-cheek rhetoric for now... perhaps you > didn't realise that, on Windows, you can't pip install a binary Mark: > Which on Windows often ends up telling you that it can't find vcvarsall.bat I am well aware that Windows users rarely have compilers available. Perhaps neither of you realized that I was responding to Mark's comment that, "I confess I don't understand how *nix people endure having to compile code instead of having a binary install." On Unix systems most of the time people never invoke a compiler directly to install from source. Heck, they often don't need to download directly, as "pip install " takes care of all that drudgery. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
> Thankfully I am. I confess I don't understand how *nix people endure having > to compile code instead of having a binary install. To me it's like going > to the garage to buy a new car, being shown the parts and the tool kit and > being told to get on with it. Perhaps it's a case of second class treatment > for users of a second class OS? Ducks and runs for cover :) And we can't understand how you can put up without source. :-) Also, Unix isn't one platform like Windows, ABI incompatibility and all. Really, for most things these days it's just pip install foo Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 23/10/2013 15:34, Skip Montanaro wrote: > Tim: > >> Disregarding Mark's tongue-in-cheek rhetoric for now... perhaps you >> didn't realise that, on Windows, you can't pip install a binary > > Mark: > >> Which on Windows often ends up telling you that it can't find vcvarsall.bat > > I am well aware that Windows users rarely have compilers available. > Perhaps neither of you realized that I was responding to Mark's > comment that, "I confess I don't understand how *nix people endure > having to compile code instead of having a binary install." > > On Unix systems most of the time people never invoke a compiler > directly to install from source. Heck, they often don't need to > download directly, as "pip install " takes care of all that > drudgery. Fair enough -- I thought you were implying that pip install had magically solved all problems of source or binary installation. Clearly you weren't, so my points about the problems still faced on Windows are rather moot. :) TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 10/23/13 7:57 AM, [email protected] wrote: Years have passed, and a LARGE number of Python programmers has not even bothered learning version 3.x. That's true for me. My own projects run just fine with 2.7. I have no specific issue with 3.x, nor phobia of it, but my time as a developer is limited, and I'd rather use it to add features to my apps using the stable base of 2.7 rather than go through the headaches of modifying my codebase to accommodate the differences with 3.x. This is something that's On My List to Do Someday, but right now there's no real upside to it for my apps. As long as 2.7 is supported, I'll probably continue to use it. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On 2013-10-23, Mark Lawrence wrote: > On 23/10/2013 14:13, Tim Golden wrote: >> On 23/10/2013 14:05, Colin J. Williams wrote: >>> It would be good if more of the packages were available, for Python 3.3, >>> in binary for the Windows user. >>> >>> I am currently wrestling with Pandas, lxml etc. >> >> Can I assume you're aware of the industrious Christopher Gohlke? >> >> http://www.lfd.uci.edu/~gohlke/pythonlibs/ >> >> TJG > > Thankfully I am. I confess I don't understand how *nix people > endure having to compile code instead of having a binary > install. To me it's like going to the garage to buy a new car, > being shown the parts and the tool kit and being told to get on > with it. Perhaps it's a case of second class treatment for > users of a second class OS? Ducks and runs for cover :) They usually don't. Users of most distributions have an awesome device called a package manager. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
Gregory Ewing writes: > Steven D'Aprano wrote: >> On Tue, 22 Oct 2013 09:38:16 +0200, Lele Gaifax wrote: >> >>>The actual syntax would be >>> >>> [object method: arg1 withSomething: arg2 withSomethingElse: arg3] >> >> I don't get how to map that to Python's syntax. > > It's roughly morally equivalent to > >object.method(arg1, withSomething = arg2, withSomethingElse = arg3) > > But there are several reasons why it's not really equivalent > to that. PyObjC actually maps it to > >object.method_withSomething_withSomethingElse_(arg1, arg2, arg3) > > which is very close to what Objective C is doing under the hood. Right (IIRC, I initially used a double underscore as separator), and that's because in ObjC the method [object method:arg1 withSomething:arg2 withSomethingElse:arg3] is completely unrelated to [object method:arg1 withSomethingElse:arg3 withSomething:arg2] I wish I had a way, at the time (we were in the 1.x era), to use something like OrderedDict to carry around the kwargs argument of a function/method, that could let me use a nicer syntax... I did even cook-up a quick&dirty patch, but being too biased toward the "dirty" side it did not go too far. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. [email protected] | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Confused about timezones
This isn't really a Python issue, though my problem solution will be
implemented in Python. If I have a naive datetime object for some time
in the past, it's not clear to me how the offset gets set correctly.
Consider this sequence:
>>> import datetime, pytz
>>> LOCAL_TZ = pytz.timezone(os.environ.get('TZ', "America/Chicago"))
>>> dt1 = datetime.datetime(2013, 5, 30, 0, 0) # DST in effect
>>> dt2 = datetime.datetime(2013, 1, 30, 0, 0) # no DST
>>> LOCAL_TZ.localize(dt1).utcoffset()
datetime.timedelta(-1, 68400)
>>> LOCAL_TZ.localize(dt2).utcoffset()
datetime.timedelta(-1, 64800)
Why is the UTC offset the same for both datetime objects despite the
presence/absence of Daylight Savings?
Thx,
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Reading From stdin After Command Line Redirection
I have a program that runs like this: foo.py https://mail.python.org/mailman/listinfo/python-list
Re: functools and objective usage
Dear all, I have the following code in each steps of loop: obj = partial(self.myinstance.myfunc) obj.func = self.myinstance.myfunc obj.arg = ["TWCH",self,key,val.checkState(),val] obj.keywords = self.myinstance But i get the following traceback: Traceback (most recent call last): File "./main.py", line 117, in main() File "./main.py", line 104, in main x.showFindProjects() File "/home/mohsen/codes/amlak/amlak/src/UIInterface.py", line 101, in showFindProjects self.uiProjectsFind.setupUi(self.projectsFind) File "/home/mohsen/codes/amlak/amlak/src/projectsFind.py", line 288, in setupUi obj.func = self.myinstance.myfunc TypeError: readonly attribute ### Before any help, Thank you... Yours, Mohsen On Wed, 2013-10-23 at 00:56 +0100, MRAB wrote: > On 22/10/2013 23:13, Ben Finney wrote: > > Mohsen Pahlevanzadeh writes: > > > >> Suppose i have function name, 3 arguments for it, and object of its > >> caller such as self.blahbalah > > > > This doesn't make much sense to me. I think you mean: You have an > > object, ‘self.blahblah’, which has a function attribute, ‘name’. > > > Perhaps the OP means that 'name' is a variable which is bound to the > name of the function/method, which is an attribute of self.blahbalah. > > > (Aside: Please choose better example names, these make it rather > > difficult to talk about.) > > > >> So: > >> my function is: > >> self.blahblah.name(arg1,arg2,arg3) > > > > Your *function* is ‘self.blahblah.name’. > > > > One possible way to express a *call* that function is > > ‘self.blahblah.name(arg1, arg2, arg3)’. > > > If 'name' is bound to the name, then: > > func = getattr(self.blahblah, name) > func(arg1, arg2, arg3) > > or just: > > getattr(self.blahblah, name)(arg1, arg2, arg3) > > >> I read functools documentations, may be objictive usage and > >> functionality differ, Do you have experience with objective usage ? > >> http://docs.python.org/2/library/functools.html#partial-objects > > > > I don't understand what the question is. You have shown a way to call > > your function; what do you want to do now? > > > >> I need to use it in my class, > > > > Feel free :-) > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: functools and objective usage
On 23/10/2013 17:48, Mohsen Pahlevanzadeh wrote: Dear all, I have the following code in each steps of loop: obj = partial(self.myinstance.myfunc) obj.func = self.myinstance.myfunc obj.arg = ["TWCH",self,key,val.checkState(),val] obj.keywords = self.myinstance But i get the following traceback: Traceback (most recent call last): File "./main.py", line 117, in main() File "./main.py", line 104, in main x.showFindProjects() File "/home/mohsen/codes/amlak/amlak/src/UIInterface.py", line 101, in showFindProjects self.uiProjectsFind.setupUi(self.projectsFind) File "/home/mohsen/codes/amlak/amlak/src/projectsFind.py", line 288, in setupUi obj.func = self.myinstance.myfunc TypeError: readonly attribute ### Before any help, Thank you... What are you trying to do? Why are you trying to change obj.func? That attribute was set when you created the partial function, and the other arguments should be provided at the same time. -- https://mail.python.org/mailman/listinfo/python-list
Re: functools and objective usage
Oh , i changed my code to: partial(self.myinstance.myfunc,[arg1,arg2,arg3,arg4,arg5],self.myinstance) But i got the following traceback: TypeError: myfunc() takes at least 5 arguments (4 given) ##3 myfunc() prototype is: # def myfunc(self,widget,projectFindInstance,field,data,checkBox = None,lineEdit = None) ## Note: My caller location in a class and myfunc is a method. How can i use partial for this state? Yours, Mohsen > On Wed, 2013-10-23 at 19:12 +0100, MRAB wrote:h > > Dear all, > > > > I have the following code in each steps of loop: > > > > obj = partial(self.myinstance.myfunc) > > obj.func = self.myinstance.myfunc > > obj.arg = ["TWCH",self,key,val.checkState(),val] > > obj.keywords = self.myinstance > > > > But i get the following traceback: > > > > Traceback (most recent call last): > >File "./main.py", line 117, in > > main() > >File "./main.py", line 104, in main > > x.showFindProjects() > >File "/home/mohsen/codes/amlak/amlak/src/UIInterface.py", line 101, in > > showFindProjects > > self.uiProjectsFind.setupUi(self.projectsFind) > >File "/home/mohsen/codes/amlak/amlak/src/projectsFind.py", line 288, > > in setupUi > > obj.func = self.myinstance.myfunc > > TypeError: readonly attribute > > ### > > Before any help, Thank you... > > > What are you trying to do? > > Why are you trying to change obj.func? > > That attribute was set when you created the partial function, and the > other arguments should be provided at the same time. > -- https://mail.python.org/mailman/listinfo/python-list
Re: functools and objective usage
Another Note: class of caller and myfunc to being differed. On Wed, 2013-10-23 at 21:56 +0330, Mohsen Pahlevanzadeh wrote: > Oh , i changed my code to: > > partial(self.myinstance.myfunc,[arg1,arg2,arg3,arg4,arg5],self.myinstance) > > But i got the following traceback: > TypeError: myfunc() takes at least 5 arguments (4 given) > ##3 > myfunc() prototype is: > # > def myfunc(self,widget,projectFindInstance,field,data,checkBox = > None,lineEdit = None) > ## > > Note: My caller location in a class and myfunc is a method. > > How can i use partial for this state? > > Yours, > Mohsen > > > > On Wed, 2013-10-23 at 19:12 +0100, MRAB wrote:h > > > Dear all, > > > > > > I have the following code in each steps of loop: > > > > > > obj = partial(self.myinstance.myfunc) > > > obj.func = self.myinstance.myfunc > > > obj.arg = ["TWCH",self,key,val.checkState(),val] > > > obj.keywords = self.myinstance > > > > > > But i get the following traceback: > > > > > > Traceback (most recent call last): > > >File "./main.py", line 117, in > > > main() > > >File "./main.py", line 104, in main > > > x.showFindProjects() > > >File "/home/mohsen/codes/amlak/amlak/src/UIInterface.py", line 101, in > > > showFindProjects > > > self.uiProjectsFind.setupUi(self.projectsFind) > > >File "/home/mohsen/codes/amlak/amlak/src/projectsFind.py", line 288, > > > in setupUi > > > obj.func = self.myinstance.myfunc > > > TypeError: readonly attribute > > > ### > > > Before any help, Thank you... > > > > > What are you trying to do? > > > > Why are you trying to change obj.func? > > > > That attribute was set when you created the partial function, and the > > other arguments should be provided at the same time. > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused about timezones
LOCAL_TZ.localize(dt1).utcoffset() > datetime.timedelta(-1, 68400) LOCAL_TZ.localize(dt2).utcoffset() > datetime.timedelta(-1, 64800) > > Why is the UTC offset the same for both datetime objects despite the > presence/absence of Daylight Savings? Brain freeze! A quick glance told me they were the same, when they actually are different (68400, 64800). Sorry for the needless noise. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wed, Oct 23, 2013 at 4:57 AM, wrote: > I am starting to have doubts as to whether Python 3.x will ever be > actually adopted by the Python community at large as their standard. Years > have passed, and a LARGE number of Python programmers has not even bothered > learning version 3.x. Why am I bothered by this? Because of lot of good > libraries are still only for version 2.x, and there is no sign of their > being updated for v3.x. I get the impression as if 3.x, despite being > better and more advanced than 2.x from the technical point of view, is a > bit of a letdown in terms of adoption. When 3.x came out, the python-dev folks practically commanded us to wait a while before diving in. I think things are mostly going according to plan. I think some little-used libraries will never get moved over. We've been seeing that 2to3 and 3to2 aren't really the main way of moving things to 3.x; instead, we're seeing a lot of code written to run, unmodified on both 2.x and 3.x. This was a bit of a surprise, I think. A document I wrote about how to do this is at http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/ I find the differences between 2.x and 3.x rather small, actually. If some people keep chanting "never going to happen", it probably won't - for them. Personally, I've been coding greenfield projects in 3.x only and liking it, and I wrote one ~10,000 line project to run on both: http://stromberg.dnsalias.org/~strombrg/backshift/ HTH -- https://mail.python.org/mailman/listinfo/python-list
question
Hi! Im installing the python library for the version 2.7 but Im getting the error unable to find vcvarsall.bat I was looking on line but it says is related to Visual Studio...? Can you guys please help me to fix this... Cesar -- https://mail.python.org/mailman/listinfo/python-list
Re: question
On Thu, Oct 24, 2013 at 7:24 AM, Cesar Campana wrote: > Hi! > > Im installing the python library for the version 2.7 but Im getting the > error unable to find vcvarsall.bat > > I was looking on line but it says is related to Visual Studio...? > > Can you guys please help me to fix this... Based on what has just been said in another thread, it seems that you're trying to install a library that's available in source code form and you need a C compiler. What library are you trying to install? Maybe there's a precompiled binary available somewhere. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On Thu, Oct 24, 2013 at 4:25 AM, Tim Daneliuk wrote: > I have a program that runs like this: > > foo.py > I want to reconnect stdin to the tty as usual after 'inputfile' > has been read so that things like raw_input and getpass > will work as expected. > > So, after I do = sys.stdin.readlines(), how to I reopen > stdin in its nonredirected mode? You fundamentally can't reopen "stdin", as that will just be your input file. What you want to do is open the console (TTY) itself. What platform are you on? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: question
On 23/10/2013 21:24, Cesar Campana wrote: Hi! Im installing the python library for the version 2.7 but Im getting the error unable to find vcvarsall.bat I was looking on line but it says is related to Visual Studio...? Can you guys please help me to fix this... Cesar That error occurs when you're trying to build a Python library but don't have the appropriate version of Visual Studio installed. If all you want is a standard Python 2.7 installation what is wrong with the quick link at http://www.python.org/ ? If that's not what you want, my advice is don't waste your time trying easy_install or pip, which is what I guess you're using, get a windows binary. Here's a good place if you can't find anything else http://www.lfd.uci.edu/~gohlke/pythonlibs/ :- please don't be put off by the "unofficial" tag, I've never had a problem using any download from this site. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
Tim Daneliuk writes: > I have a program that runs like this: > > foo.py I want to reconnect stdin to the tty as usual after 'inputfile' > has been read so that things like raw_input and getpass > will work as expected. Why? That's at odds with how the user has already chosen to run the program. If they wanted to run the program interactively, they wouldn't have chosen to redirect standard input. > So, after I do = sys.stdin.readlines(), how to I reopen > stdin in its nonredirected mode? There would be no point; standard input was never attached to the console in the first place, it was attached (by the person who chose the above invocation) to a different file instead. You've already read the entire file. Can you speak more about how you intend your program to be used? The above request is incoherent, and I suspect you've made a design mistake. -- \ “Philosophy is questions that may never be answered. Religion | `\ is answers that may never be questioned.” —anonymous | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On Thu, Oct 24, 2013 at 7:46 AM, Ben Finney wrote: > Can you speak more about how you intend your program to be used? The > above request is incoherent, and I suspect you've made a design mistake. There are times when this is correct behaviour - like asking for passwords (SSH and sudo work like this). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/23/2013 12:25 AM, Philip Herron wrote: > On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle wrote: >> On 10/20/2013 3:10 PM, [email protected] wrote: >> >>> On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron >>> wrote: > Nagle replies: >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. ... > > I think your analysis is probably grossly unfair for many reasons. > But your entitled to your opinion. > > Current i do not use Bohem-GC (I dont have one yet), You included it in your project: http://sourceforge.net/p/gccpy/code/ci/master/tree/boehm-gc > i re-use > principles from gccgo in the _compiler_ not the runtime. At runtime > everything is a gpy_object_t, everything does this. Yeah you could do > a little of dataflow analysis for some really really specific code > and very specific cases and get some performance gains. But the > problem is that the libpython.so it was designed for an interpreter. > > So first off your comparing a project done on my own to something > like cPython loads of developers 20 years on my project or something > PyPy has funding loads of developers. > > Where i speed up is absolutely no runtime lookups on data access. > Look at cPython its loads of little dictionaries. All references are > on the Stack at a much lower level than C. All constructs are > compiled in i can reuse C++ native exceptions in the whole thing. I > can hear you shouting at the email already but the middle crap that a > VM and interpreter have to do and fast lookup is _NOT_ one of them. > If you truely understand how an interpreter works you know you cant > do this > > Plus your referencing really old code on sourceforge is another > thing. That's where you said to look: http://gcc.gnu.org/wiki/PythonFrontEnd "To follow gccpy development see: Gccpy SourceForge https://sourceforge.net/projects/gccpy"; > And i dont want to put out bench marks (I would get so much > shit from people its really not worth it) but it i can say it is > faster than everything in the stuff i compile so far. So yeah... not > only that but your referncing a strncmp to say no its slow yeah it > isn't 100% ideal but in my current git tree i have changed that. So the real source code isn't where you wrote that it is? Where is it, then? > So i > think its completely unfair to reference tiny things and pretend you > know everything about my project. If you wrote more documentation about what you're doing, people might understand what you are doing. > One thing people might find interesting is class i do data flow > analysis to generate a complete type for that class and each member > function is a compiled function like C++ but at a much lower level > than C++. It's not clear what this means. Are you trying to determine, say, which items are integers, lists, or specific object types? Shed Skin tries to do that. It's hard to do, but very effective if you can do it. In CPython, every time "x = a + b" is executed, the interpreter has to invoke the general case for "+", which can handle integers, floats, strings, NumPy, etc. If you can infer types, and know it's a float, the run time code can be float-specific and about three machine instructions. > The whole project has been about stripping out the crap > needed to run user code and i have been successful so far but your > comparing a in my spare time project to people who work on their > stuff full time. With loads of people etc. Shed Skin is one guy. > Anyways i am just going to stay out of this from now but your email > made me want to reply and rage. You've made big claims without giving much detail. So people are trying to find out if you've done something worth paying attention to. John Nagle -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On Wed, Oct 23, 2013, at 16:52, Chris Angelico wrote: > There are times when this is correct behaviour - like asking for > passwords (SSH and sudo work like this). Less (or pagers generally, or an interactive text editor that allows creating a file from standard input) would be another example of a program where it makes sense to do this. It is an unusual thing to want 99% of the time, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused about timezones
On 10/23/2013 12:00 PM, Skip Montanaro wrote: > --> LOCAL_TZ.localize(dt1).utcoffset() datetime.timedelta(-1, 68400) --> LOCAL_TZ.localize(dt2).utcoffset() datetime.timedelta(-1, 64800) Why is the UTC offset the same for both datetime objects despite the presence/absence of Daylight Savings? Brain freeze! A quick glance told me they were the same, when they actually are different (68400, 64800). Sorry for the needless noise. Don't feel too bad, doesn't look like anybody else noticed either! ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
[email protected] writes: > On Wed, Oct 23, 2013, at 16:52, Chris Angelico wrote: > > There are times when this is correct behaviour - like asking for > > passwords (SSH and sudo work like this). > > Less (or pagers generally, or an interactive text editor that allows > creating a file from standard input) would be another example of a > program where it makes sense to do this. You're both describing programs that read the console, which is not what the OP was asking for. The OP was asking about re-opening stdin after reaching EOF, which is incoherent as far as I understand it. I'm still waiting for the OP to clarify what they want to do. -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On Thu, Oct 24, 2013 at 9:20 AM, Ben Finney wrote: > [email protected] writes: > >> On Wed, Oct 23, 2013, at 16:52, Chris Angelico wrote: >> > There are times when this is correct behaviour - like asking for >> > passwords (SSH and sudo work like this). >> >> Less (or pagers generally, or an interactive text editor that allows >> creating a file from standard input) would be another example of a >> program where it makes sense to do this. > > You're both describing programs that read the console, which is not what > the OP was asking for. The OP was asking about re-opening stdin after > reaching EOF, which is incoherent as far as I understand it. > > I'm still waiting for the OP to clarify what they want to do. The OP did say "tty" and mentioned getpass. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On 10/23/2013 05:20 PM, Ben Finney wrote: [email protected] writes: On Wed, Oct 23, 2013, at 16:52, Chris Angelico wrote: There are times when this is correct behaviour - like asking for passwords (SSH and sudo work like this). Less (or pagers generally, or an interactive text editor that allows creating a file from standard input) would be another example of a program where it makes sense to do this. You're both describing programs that read the console, which is not what the OP was asking for. The OP was asking about re-opening stdin after reaching EOF, which is incoherent as far as I understand it. I'm still waiting for the OP to clarify what they want to do. 'Easy there Rainman, the question is entirely coherent, though it may not be achievable this way. The goal of the exercise was: - Read a file the user specifies via command line redirection - When the file is fully read, return to reading keyboard input with things like raw_input and get_pass which I believe use stdin as a source ... probably to avoid having to manually cope with ttys and ptys themselves. One of those two functions - I don't recall which - was giving me a problem with stdin redirected. In the end, I broke down and added a command line parameter to specify which file to read in so that stdin would be unaffected. Now that I think about it, as I recall from the prehistoric era of writing lots of assembler and C, if you use shell redirection, stdin shows up as a handle to the file and there is no way to retrieve/reset it its default association with the tty/pty. Since python is layered on top of this, I expect the same would be the case here as well. -- Tim Daneliuk [email protected] PGP Key: http://www.tundraware.com/PGP/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wed, 23 Oct 2013 14:27:29 +0100, Mark Lawrence wrote: > I confess I don't understand how *nix people endure having to compile > code instead of having a binary install. Because it's trivially easy under Unix? Three commands: ./configure make make install will generally do the job. Unless it doesn't work, in which case it's a world of pain. But that's no different from Windows, except that somebody else has already worked through the pain for you. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wed, 23 Oct 2013 04:57:25 -0700, dufriz wrote: > I am starting to have doubts as to whether Python 3.x will ever be > actually adopted by the Python community at large as their standard. Of course it will. Python 2.7 is the last of the 2 series. It will be given extended support, but eventually -- probably another five years or so -- it will be no longer supported, just like Python 1.5 is no longer supported. > Years have passed, and a LARGE number of Python programmers has not even > bothered learning version 3.x. It's not like the differences are hard to learn. Even a mediocre programmer can learn the differences in semantics and syntax in about five minutes -- if you remember "print is a function", you're about half- way there. Differences to the standard library are more extensive, but still easy to learn. > Why am I bothered by this? Because of lot > of good libraries are still only for version 2.x, and there is no sign > of their being updated for v3.x. What do you call a "lot"? A million? Ten? > I get the impression as if 3.x, despite > being better and more advanced than 2.x from the technical point of > view, is a bit of a letdown in terms of adoption. Don't panic, the plan was always that the migration from 2 to 3 would take about a decade. We're only half-way through it, and the migration is proceeding according to plan: - the majority of packages on PyPI now support Python 3, so the "Wall of Shame" is now renamed the "Wall of Superpowers": https://python3wos.appspot.com/ - big, important projects like numpy, scipy, django, zope, docutils etc. now have either full Python 3 support, partial support, or are actively working on it - As of June this year, 39 of the top 50 downloaded projects from PyPI had Python 3 support: http://py3ksupport.appspot.com/ - It's not just CPython, other implementations like Nuitika, PyPy and Cython have partial or full support for Python 3. So don't worry about it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wednesday 23 October 2013 19:53:20 Dennis Lee Bieber did opine: > On 23 Oct 2013 12:36:09 GMT, Neil Cerutti declaimed > the > > following: > >On 2013-10-23, David wrote: > >> On 23 October 2013 22:57, wrote: > >>> a LARGE number of Python programmers has not even bothered learning > >>> version 3.x. > >> > >> OMG. Please provide their names. We'll send Doug & Dinsdale. > > > >I can send Mr. Wendt and Mr. Kidd. Or are those guys dead? > > I could swear one of them is taking part in a smartphone commercial... > http://www.youtube.com/watch?v=slf3GgxqusI > 22 seconds in... > > > There's always their look-alikes from "Codename: Kids Next Door": Mr. > Wink and Mr. Fibb Just one more question: Did Antony and Luigi, from the amiga days, retire? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: Why did Menachem Begin invade Lebanon? A: To impress Jodie Foster. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. -- https://mail.python.org/mailman/listinfo/python-list
Re-raising a RuntimeError - good practice?
Hi,
I have a Python class that represents a loading job.
Each job has a run_all() method that calls a number of other class methods.
I'm calling run_all() on a bunch of jobs.
Some of methods called by run_all() can raise exceptions (e.g. missing files,
DB connection failures) which I'm catching and logging.
If any of the methods fails, I'd like to terminate running that job, and move
onto the next job.
I'm currently re-raising a RuntimeError, so that I can break out the run_all()
and move onto the next job.
For example:
def run_all(self):
self.logger.debug('Running loading job for %s' % self.friendly_name)
try:
self.export_to_csv()
self.gzip_csv_file()
self.upload_to_foo()
self.load_foo_to_bar()
except RuntimeError as e:
self.logger.error('Error running job %s' % self.friendly_name)
...
def export_to_csv(self):
...
try:
with open(self.export_sql_file, 'r') as f:
self.logger.debug('Attempting to read in SQL export statement
from %s' % self.export_sql_file)
self.export_sql_statement = f.read()
self.logger.debug('Successfully read in SQL export statement')
except Exception as e:
self.logger.error('Error reading in %s - %s' %
(self.export_sql_file, e), exc_info=True)
raise RuntimeError
My question is - is the above Pythonic, or an acceptable practice?
Or is there another way I should be handling errors, and moving on from
failures, and if so what is it please?
Cheers,
Victor
--
https://mail.python.org/mailman/listinfo/python-list
Re: Global Variable In Multiprocessing
On 10/22/2013 11:22 PM, Chandru Rajendran wrote: > CAUTION - Disclaimer * > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you are > not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for any > damage > you may sustain as a result of any virus in this e-mail. You should carry out > your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from this > e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS End of Disclaimer INFOSYS*** Because of the above restriction, we are unable to reply to your question. John Nagle SiteTruth -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
Tim Daneliuk writes: > 'Easy there Rainman I'll thank you not to use mental deficiency as some kind of insult. Calling someone “Rainman” is to use autistic people as the punchline of a joke. We're a community that doesn't welcome such ableist slurs. > The goal of the exercise was: > > - Read a file the user specifies via command line redirection > - When the file is fully read, return to reading keyboard > input with things like raw_input and get_pass which I believe > use stdin as a source ... probably to avoid having to manually > cope with ttys and ptys themselves. One of those two functions - > I don't recall which - was giving me a problem with stdin > redirected. Thank you for clarifying. I think the request is incoherent: If you want to allow the user to primarily interact with the program, this is incompatible with also wanting to redirect standard input. Rather, you should add to your program an option to allow specifying a file to read, and present usage examples that don't redirect standard input. > In the end, I broke down and added a command line parameter to > specify which file to read in so that stdin would be unaffected. That's the right solution, I'd say. > Now that I think about it, as I recall from the prehistoric era of > writing lots of assembler and C, if you use shell redirection, stdin > shows up as a handle to the file and there is no way to retrieve/reset > it its default association with the tty/pty. Since python is layered > on top of this, I expect the same would be the case here as well. Right. Congratulations for learning more about the design of the OS and making a program that fits in well :-) -- \ “A lot of people are afraid of heights. Not me, I'm afraid of | `\ widths.” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Screenshots in Mac OS X
Well, I'm not going to post my whole module as I get little testing on mac, but I will let you in on a little secret: Use a GUI, such as wxPython or QT or other, then create a basic fullscreen frame that is invisible and copy its DC to the clipboard. Not exactly a hack(might be edgy), but it works. Writing the gui/logic code will be up to you. here is a basic wx example f = wxFrame(None, -1) f.Show(True) f.SetTransparent(0) # Bind your hotkeys to capture the screen. Also, not sure ATM... but I recall someone wrote a cross platform screenshot implementation IIRC that replaces PIL's ImageGrab module, I think it is pyscreenshot or something similar. You might want to look into that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Re-raising a RuntimeError - good practice?
On Wed, 23 Oct 2013 20:23:21 -0700, Victor Hooi wrote:
> Hi,
>
> I have a Python class that represents a loading job.
>
> Each job has a run_all() method that calls a number of other class
> methods.
>
> I'm calling run_all() on a bunch of jobs.
>
> Some of methods called by run_all() can raise exceptions (e.g. missing
> files, DB connection failures) which I'm catching and logging.
>
> If any of the methods fails, I'd like to terminate running that job, and
> move onto the next job.
That should be simple:
for job in many_jobs:
try:
job.run_all()
except RunAllException as err:
logger.error(err)
Another approach is to put all your error handling in the one place (or
as few places as possible):
for job in jobs:
try:
try:
job.run_all()
except Exception as err: # catch *everything*
logger.error(err)
raise
except (SpamError, EggsError, CheeseError):
# We expect these exceptions, and ignore them.
# Everything else is a bug.
pass
With this approach, only your top-level code needs to care about catching
exceptions. Although some of your lower-level code may do so as well, but
it's (potentially) no longer their responsibility to deal with logging.
However, the down-side of this approach is that the list of "ignorable
exceptions" needs to be kept small and manageable. That may requires
either diligence on your part, tracking which exceptions can be raised,
or having each method be responsible for generating the right exceptions.
See below.
> I'm currently re-raising a RuntimeError, so that I can break out the
> run_all() and move onto the next job.
>
> For example:
>
> def run_all(self):
> self.logger.debug('Running loading job for %s' %
>self.friendly_name)
> try:
> self.export_to_csv()
> self.gzip_csv_file()
> self.upload_to_foo()
> self.load_foo_to_bar()
> except RuntimeError as e:
> self.logger.error('Error running job %s' %
> self.friendly_name)
At first glance, that looks pretty nasty to me. The *actual* exception
causing the problem is lost. This is one step up from the infamous, and
horrible
"An error occurred"
message. At least you report the name of the job that failed, but you
don't report the actual error, or which component failed.
Fortunately the actual error is logged by the method which fails, which
makes it much better, but suggests that this exception handler isn't
doing anything: the error message it generates is pointless and is just
noise in the log file, so you ought to get rid of it.
> def export_to_csv(self):
> ...
> try:
> with open(self.export_sql_file, 'r') as f:
> self.logger.debug('Attempting to read in SQL export
> statement from %s' % self.export_sql_file)
> self.export_sql_statement = f.read()
> self.logger.debug('Successfully read in SQL export
> statement')
> except Exception as e:
> self.logger.error('Error reading in %s - %s' %
> (self.export_sql_file, e), exc_info=True)
> raise RuntimeError
>
> My question is - is the above Pythonic, or an acceptable practice?
It's certainly acceptable practice, but the downside is that *every*
method needs to care about catching exceptions and logging them. It's
better to push as much of that responsibility as you can out of the
individual methods and into the caller.
Sometimes, though, a method may have to deal with too many different
possible exceptions, which makes managing the list of expected exceptions
to ignore too hard. In that case, use custom exceptions:
class SpamException(Exception):
pass
class Job:
def export_to_csv(self):
...
try:
with open(self.export_sql_file, 'r') as f:
self.logger.debug('Attempting to read in SQL export
statement from %s' % self.export_sql_file)
self.export_sql_statement = f.read()
self.logger.debug('Successfully read in SQL export
statement')
except IOError, OSError as err:
# Low-level methods should always be conservative in what they
# catch, not too eager to cover up bugs in the code.
raise SpamError("blah blah blah", err)
or similar. E.g. you can use RuntimeError, as you do.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On 10/23/2013 10:53 PM, Ben Finney wrote: Right. Congratulations for learning more about the design of the OS and making a program that fits in well:-) It's only possible because, after some 30 years of doing this, I feel very abelist ... -- Tim Daneliuk [email protected] PGP Key: http://www.tundraware.com/PGP/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
On 10/23/2013 10:53 PM, Ben Finney wrote: Congratulations for learning more about the design of the OS and making a program that fits in well It's only because of some 30 years of doing this that I now feel quite abelist ... -- Tim Daneliuk [email protected] PGP Key: http://www.tundraware.com/PGP/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Re-raising a RuntimeError - good practice?
On 2013.10.23 22:23, Victor Hooi wrote:
> For example:
>
> def run_all(self):
> self.logger.debug('Running loading job for %s' % self.friendly_name)
> try:
> self.export_to_csv()
> self.gzip_csv_file()
> self.upload_to_foo()
> self.load_foo_to_bar()
> except RuntimeError as e:
> self.logger.error('Error running job %s' % self.friendly_name)
> ...
> def export_to_csv(self):
> ...
> try:
> with open(self.export_sql_file, 'r') as f:
> self.logger.debug('Attempting to read in SQL export statement
> from %s' % self.export_sql_file)
> self.export_sql_statement = f.read()
> self.logger.debug('Successfully read in SQL export statement')
> except Exception as e:
> self.logger.error('Error reading in %s - %s' %
> (self.export_sql_file, e), exc_info=True)
> raise RuntimeError
You're not re-raising a RuntimeError. You're swallowing all exceptions and then
raising a RuntimeError. Re-raise the original exception in
export_to_csv() and then handle it higher up. As Steven suggested, it is a good
idea to handle exceptions in as few places as possible (and
as specifically as possible). Also, loggers have an exception method, which can
be very helpful in debugging when unexpected things happen,
especially when you need to catch a wide range of exceptions.
--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 10.0
--
https://mail.python.org/mailman/listinfo/python-list
Re: Reading From stdin After Command Line Redirection
Tim Daneliuk writes: > On 10/23/2013 10:53 PM, Ben Finney wrote: > > Right. Congratulations for learning more about the design of the OS and > > making a program that fits in well:-) > > It's only possible because, after some 30 years of doing this, I feel > very abelist ... You may be unaware, so I'll give the benefit of the doubt. To be ableist is analogous with being sexist: a form of prejudicial behaviour against disadvantaged groups. You're free to express yourself however you like in your own space, but in this community, we don't welcome ableist (nor sexist) behaviour. -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Maintaining a backported module
As some of you are aware, I have a module accepted into the standard library: http://docs.python.org/3.4/library/statistics.html I'm now at the point where I wish to backport this module to support versions of Python back to 3.1 at least and possibly 2.7, and put it up on PyPI. I'm looking for advice on best practices for doing so. Any suggestions for managing bug fixes and enhancements to two separate code-bases without them diverging too much? Other than "Avoid it" :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
It's an interesting issue. Back compatibility was broken with 3.x, which is always a risky move. Even Bill F*ng Gates was reluctant to break back compatibility, and he basically ruled the world (for about 20 minutes or so, but still). Moreover, you get a lot of the good stuff with 2.7. Along with more library support. So the smart decision is to code your project 2.7, even though the best thing for Pythonistan would be for us all to voluntarily migrate to 3.x. At least that's my read on it. Feel free to flame if I'm out of my depth here, it wouldn't be the first time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining a backported module
Steven D'Aprano writes: > I'm now at the point where I wish to backport this module to support > versions of Python back to 3.1 at least and possibly 2.7, and put it > up on PyPI. > > I'm looking for advice on best practices for doing so. Any suggestions > for managing bug fixes and enhancements to two separate code-bases > without them diverging too much? It is a great advantage that you've targeted Python 3 primarily. As I understand it, it is far easier to make an existing Python 3 code base also work on Python 2, than vice versa. (Though that will obviously change as Python 3 continues to diverge from Python 2. The more one depends on Python 3 features, the more one depends on back-ported versions of those features for Python 2. I'm pretty sure that's not going to be much of an issue for the ‘statistics’ package, but it's worth mentioning as a general caveat.) > Other than "Avoid it" :-) A useful library for this purpose is ‘six’ (as in “3 × 2”) http://pythonhosted.org/six/>. You can use its features to do things that are useful or better in Python 3, but which need special implementation to work on Python 2; and the same code will just work on both versions. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but if we get Sam Spade, we'll never have any puppies.” | _o__) —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
I said "Even Bill F*ng Gates was reluctant to break back compatibility," Reluctant to do so with his own stuff. Obviously he "embraced and extended" other peoples work. Don't get me started, Gates is Bizarro Guido. Good work with vaccines though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining a backported module
Steven D'Aprano writes: > As some of you are aware, I have a module accepted into the standard > library: > http://docs.python.org/3.4/library/statistics.html Wow, neat, I had seen something about the module and thought it looked great, but I didn't realize you were the author. Awesome! > Any suggestions for managing bug fixes and enhancements to two > separate code-bases without them diverging too much? I haven't touched 3.x yet, but I found with a little bit of care in resisting use of new features, I was able to implement in the intersection of 2.x and 1.5, so the same code worked in both. That avoided the need for two codebases in the stuff I did. I don't know if it would be more difficult with the stats module. -- https://mail.python.org/mailman/listinfo/python-list
pycrypto: what am I doing wrong?
I seem to have misunderstood something about the way Crypto.Cipher is supposed
to work, because I'm getting unexpected results, here is my code..
import hashlib
from Crypto.Cipher import AES
from Crypto import Random
h = hashlib.new('sha256')
h.update('my key')
key = h.digest()
iv = Random.new().read(AES.block_size)
cipher = AES.new(key, AES.MODE_CFB, iv)
txt = 'hello world'
# This is the part where I'm confused, because it seems like encrypt will
output a different result every time, so how can I decrypt it?
msg = cipher.encrypt(txt)
>>> '|s\x08\xf2\x12\xde\x8cD\xe7u*'
msg = cipher.encrypt(txt)
>>> '\xa1\xed7\xb8h>> '\x0b\xd9\x9f0\xd1\xb9E\x81;\x8a\xd4\xff\xdb\xd4\x83\x84\xbd$=\xf3\xaf@a8t\xd8Bz<\xce\xe26hello
>>> world'
# But it does not work subsequently:
msg = iv + cipher.encrypt(txt)
cipher.decrypt(iv+msg)
>>> '\xfb\xa1\xa8\x9e"L<\x10Rg\xb5f^\x8a\x17\xfd\xbd$=\xf3\xaf@a8t\xd8Bz<\xce\xe26\xde\xc6cD\xdal\'\xf3@(\xa6'
What am I doing wrong?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Monday, October 21, 2013 9:29:34 PM UTC-5, Steven D'Aprano wrote:
> On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote:
>
> Challenge: give some examples of things which you can do in Python, but
> cannot do *at all* in C, C++, C#, Java?
Ummm... hmmm let me try here...
string = 'Python is the Best!'
if string:
try:
string = int(string)
except Exception as exc:
integer = str(integer)
else:
print('Typecasting Maybe...')
I get more comments on "Typecasting" from those who don't know how to use a
press more than anything, than I get from the typesetter.
#... maybe she's ignoring me...
Am I right?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining a backported module
On Thursday, October 24, 2013 12:09:55 AM UTC-5, Ben Finney wrote: > A useful library for this purpose is ‘six’ (as in “3 × 2”) > http://pythonhosted.org/six/>. You can use its features to do > things that are useful or better in Python 3, but which need special > implementation to work on Python 2; and the same code will just work on > both versions. +1 for stdev Steven. Thanks for the extra legs. Hope all goes well with introductions... I'm sure it will. :) Good Job. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Thu, Oct 24, 2013 at 3:57 PM, Peter Cacioppi wrote: > Moreover, you get a lot of the good stuff with 2.7. Along with more library > support. So the smart decision is to code your project 2.7, even though the > best thing for Pythonistan would be for us all to voluntarily migrate to 3.x. I won't flame you, but I will disagree with you :) You may get "a lot of" the good stuff with 2.7, but there are plenty of things you won't get - and the gap will widen with every Python release. As of 3.3, you're missing out on, among other things: * PEP 393 strings - high performance and perfect Unicode handling * 'yield from' * Major improvements to 'import' * High performance 'decimal' When 3.4 comes out, add to the list: * enumerations * asyncio * Argument Clinic (introspection) When 3.5 comes out, your 2.7 program will additionally be unable to use: * Who knows? * But it'll be exciting. If you insist on not moving to 3.x, I strongly recommend some future imports - unicode_literals, division, print_function - to make your 2.7 program behave more like a 3.x one. That'll ease the pain of transition, though you'll still probably run into problems with unicode vs bytes in places where your code used to be oblivious... which means your code will become guaranteed-correct when you move to 3.x, where the 2.7 version was merely accidentally-correct. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Antoine Pitrou, 22.10.2013 10:55: > Philip Herron writes: >> Its interesting a few things come up what about: >> exec and eval. I didn't really have a good answer for this at my talk at >> PYCon IE 2013 but i am going to say no. I am >> not going to implement these. Partly because eval and exec at least to me >> are mostly from developing >> interpreters as a debugging exercise so the test doesn't have to invoke >> the program properly and feed in >> strings to interpret at least thats what i have done in the past with an >> virtual machine i wrote before gccpy. > > If you don't implement exec() and eval() then people won't be able to use > namedtuples, which are a common datatype factory. FWIW, for Cython, I personally consider eval() and exec() more of a handy way to insert plain Python code (potentially even generated at runtime) into compiled code, so they are not currently compiled. You can see that from the low Mako benchmark results, for example. We may eventually add an option to compile that code at runtime (assuming you have Cython and a C compiler installed), but I doubt that people would want that as the default. Obviously, Cython has the advantage of being backed by a CPython runtime, so it's easy for us to choose one or the other. An independent Python implementation doesn't easily have that choice. > As for the rest: well, good luck writing an AOT compiler producing > interesting results on average *pure* Python code. It's already been tried > a number of times, and has generally failed. Cython mitigates the issue by > exposing a superset of Python (including type hints, etc.). Agreed, although the word "mitigate" makes it sound more like a work-around than the actual feature it represents. I've written down my thoughts on this topic a while ago. http://blog.behnel.de/index.php?p=241 Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
On Wed, 23 Oct 2013 22:12:57 -0700, Peter Cacioppi wrote: > I said > > "Even Bill F*ng Gates was reluctant to break back compatibility," Don't be fooled though, Python is *extremely* reluctant to break backwards compatibility too. That's why Python has the "__future__" directive, and why some warts have ended up enshrined in the language. For example, although string exceptions were recognised as a bad idea for many years, there was a long deprecation process to get rid of them. It took at least 11 years to remove them completely: http://python-history.blogspot.com.au/2009/03/how-exceptions-came-to-be-classes.html Nick Coglan describes some of the completing pressures on a language like Python: http://www.boredomandlaziness.org/2011/04/musings-on-culture-of-python-dev.html Because of the tension between users demanding Python change more quickly, and those demanding it changes more slowly, you can't satisfy everyone. You probably can't even satisfy anyone. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining a backported module
On 10/23/2013 09:54 PM, Steven D'Aprano wrote: I'm looking for advice on best practices for doing so. Any suggestions for managing bug fixes and enhancements to two separate code-bases without them diverging too much? Confining your code to the intersection of 2.7 and 3.x is probably going to be the easiest thing to do as 2.7 has a bunch of 3.x features. Sadly, when I backported Enum I was targeting 2.5 - 3.x because I have systems still running 2.5. That was *not* a fun experience. :( -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
