Template Data Interface (tdi) 0.9.9.8
Hello World! I'm pleased to announce version 0.9.9.8 of TDI. About TDI = TDI is a markup templating system written in python with (optional but recommended) speedup code written in C. It features strict markup / logic separation, is very fast and provides powerful tools for template manipulation. About Release 0.9.9.8 = TDI grew a new tool collection which handles template dependencies. This release also provides various API and performance improvements and a few bug fixes. Supported Python Versions = * Python 2.4 - 2.7 * PyPy 1.9, 2.0 (Python only) * Jython 2.5, 2.7 (Python only) License === TDI is available under the terms and conditions of the Apache License, Version 2.0. TODO * better framework integration * python 3 support Links = * Homepage + Documentation: http://opensource.perlig.de/tdi/ * PyPI: https://pypi.python.org/pypi/tdi * License: http://www.apache.org/licenses/LICENSE-2.0 André nd Malo -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
cliff -- Command Line Interface Formulation Framework -- version 1.6.0
cliff -- Command Line Interface Formulation Framework -- version 1.6.0 cliff is a framework for building command line programs. It uses setuptools entry points to provide subcommands, output formatters, and other extensions. What's New In This Release? * Add max-width support for table formatter * Add value only output formatter * Fix doc build with Python 2.6.x * Fix interactive mode with command line args * Escape double quotes in shell formatter * Rename private attribute to avoid conflict * Sync with OpenStack's global requirements * Add integration tests with known consumers * Make the formatters a private part of the command Documentation [1]Documentation for cliff is hosted on [2]readthedocs.org Installation Use pip: $ pip install cliff See [3]the installation guide for more details. References 1. http://readthedocs.org/docs/cliff/en/latest/ 2. http://readthedocs.org/ 3. http://cliff.readthedocs.org/en/latest/install.html -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
CaptureMock 1.0 - true record/replay mocking for Python (and other things...)
Hi all, CaptureMock has come of age at last and reached 1.0. Many things have been fixed and improved since the last release. Notably: - Supports python callbacks in a limited fashion (i.e. intercepted code calling back into non-intercepted code) Makes it possible to e.g. intercept Tkinter and use CaptureMock for a limited kind of GUI testing. - Should work better in Python 3 - Mock files are more readable, we use pprint to ensure it doesn't get too wide. Naming of variables is more intelligent and descriptive, make use of strings provided when the objects first appear - Client-server support now handles XMLRPC servers Regards, Geoff Bache More detail: CaptureMock is a tool for creating mocks via a true capture-replay style approach. It records interactions to a separate file which can then be used for replay in future runs. It is thus not another EasyMock clone. Interaction can be recaptured from a real system at any point, and no mock code needs to be written. It handles Python calls, command-line programs, and synchronous messaging over networks. Custom clients can now also be written for any language. Website: http://www.texttest.org/index.php?page=capturemock Examples: https://github.com/msabramo/capturemock_examples/ Mailing list: https://lists.sourceforge.net/lists/listinfo/texttest-users -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: rom 0.26.1 - Redis object mapper for Pthon
Hey everyone, The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy with the declarative base, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find the package at: https://www.github.com/josiahcarlson/rom https://pypi.python.org/pypi/rom And docs can be found at: http://pythonhosted.org/rom/ Please CC me on any replies if you have any questions or comments. Thank you, - Josiah #-- 0.26.1 --- [fixed] issue with deleted entity resurrection, bug report and fix thanks to Justin Mayfield https://github.com/mayfield [fixed] issue with deleted entities not being completely cleared out during delete with Lua writes enabled, bug report and fix also courtesy of Justin Mayfield https://github.com/mayfield #-- 0.26.0 --- [added] support for Python 3.3 thanks to the six library and porting effort from Justin Mayfield https://github.com/mayfield, which also includes some additional tests. [remove] String column from Python 3.3, use the Text column instead. [changed] Both String and Text columns can use unique columns. [fixed] rom's behavior with long ints in some situations. [fixed] rom's behavior with unicode suffixes in Python 2.x. [added] tests for unicode text indexes, unique indexes, prefix indexes, and suffix indexes. [updated] relevant docs regarding the Text column and unique indexes. [fixed] improperly labeled 0.25.1 release in this changelog. #-- 0.25.1 --- [fixed] an issue where Lua writing wouldn't properly update unique indexes on deletion was fixed. Thank you to https://github.com/thedrow for the report. [changed] added a link to the full Python docs to the Readme. #- 0.23 (unreleased) - [changed] reduced number of round trips for single-filter queries by 1, thanks to https://github.com/MickeyKim for the report. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: converting strings to hex
Mark H Harris harrismh...@gmail.com wrote in message news:533e1b2e.5040...@gmail.com... On 4/3/14 9:10 PM, dave em wrote: I am taking a cryptography class and am having a tough time with an assignment similar to this. hi Dave, if your instructor wanted you to work on this with other people she would have made it a group project and ordered pizza for everyone. I'll give you some credit, that last couple of folks that wanted help with their homework here could not bring themselves to admit they wanted help with their homework. :) YMMV but I thought the OP had done a good job before asking for help and then asked about only a tiny bit of it. Some just post a question! HAL, please help me with my homework! I'm sorry, Dave, I can't do that... HAL!!? I'm sorry, Dave, I just can't do that... You might find this interesting. http://sundry.wikispaces.com/transcript-2001 James -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode Chars in Windows Path
Steven D'Aprano st...@pearwood.info writes: When working with Windows paths, you should make a habit of either escaping every backslash: uc:\\automation_common\\Python\\TestCases\\list_dir_script.txt using a raw-string: urc:\automation_common\Python\TestCases\list_dir_script.txt or just use forward slashes: uc:/automation_common/Python/TestCases/list_dir_script.txt The latter should be preferred, in case Python3 compatibility is a goal. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
On Thu, 03 Apr 2014 15:11:38 -0400, Terry Reedy wrote: On 4/3/2014 12:02 PM, Lucas Malor wrote: A more suitable place to propose this would be the python-ideas mailing list. You're right. I posted here because this list was linked by PEP 1. But now that I read more there's also python-ideas listed. Let me know if I have to continue there instead. Given that the idea has been posted to python-ideas and rejected, more that once I believe, I think this was the right place to post this to have variations discussed in a friendly manner. I agree with Terry. Nothing wrong with gathering some feedback here first. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, 04 Apr 2014 09:43:15 +1100, Chris Angelico wrote:
While I am interested in seeing a Decimal literal syntax in Python, and
I would support a shift to have 1.2 evaluate as a Decimal (but not
soon - it'd break backward compat *hugely*)
I used to think the same thing, but have since learned that it's not a
coincidence or accident that people seriously interested in numerical
computation nearly always stick to binary floats. I think it's a little
harsh to say that only dilettantes and amateurs use base-10 floats, but
only a little. Base-10 has one, and only one, thing going for it: the
number you type (in decimal) is the number you get (within the limits of
precision). Apart from that, in every way IEEE-754 binary floats are as
good or better than any other choice of base, including decimal. The same
floating-point complications that plague binary floats also plague
decimal ones, only worse.
I really should stop being shocked by anything I learn about floating
point numbers, but something that knocked my socks off when I learned it
was that as simple an operation as taking the average of two floats is
problematic in decimal. In base-2, and given round-to-nearest division,
(x+y)/2 is always within the range x...y. But that's not necessarily the
case in base-10 floats: sometimes the average of two numbers is not
between those two numbers. Contrast binary floats:
py x = 0.77787516
py y = 0.77787518
py (x + y) / 2
0.77787517
with decimal:
py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516)
py y = Decimal(0.77787518)
py (x + y) / 2
Decimal('0.77787515')
Guido, why can't Python do maths???
(Oh lordy, can you imagine Ranting Rick getting onto that???)
I've changed my mind about Python using Decimal as the default numeric
type. I think that would send a very strong message that Python is not
for serious numeric work.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 6:52 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
py x = Decimal(0.77787516)
py y = Decimal(0.77787518)
py (x + y) / 2
Decimal('0.77787515')
I've changed my mind about Python using Decimal as the default numeric
type. I think that would send a very strong message that Python is not
for serious numeric work.
Hmm. Good point. (I'm not familiar with your notation, by the way;
assuming x...y includes both endpoints? The first thing that comes to
mind is git's revision syntax, in which x and y would be
tags/commits/branches and that would give you everything that's in
those branches but not in their common parent. And I doubt very much
that's what you mean!) So I go back to a previous form of the
request/desire: that the AST store numeric literals as their original
strings (maybe as well as the parsed version), such that an AST
transform can replace all float literals with Decimal literals (if
they exist, or calls to Decimal and string args if they don't).
print(ast.dump(ast.parse(print(0.1 + 0.2
Module(body=[Expr(value=Call(func=Name(id='print', ctx=Load()),
args=[BinOp(left=Num(n=0.1), op=Add(), right=Num(n=0.2))],
keywords=[], starargs=None, kwargs=None))])
Possibly the easiest way - and maybe I should shift this part of the
discussion to -ideas - would be to have Num nodes retain additional
meta-information, in the same way that nodes retain line/column info.
Then it would be relatively simple to write a Decimal-mode hook for
IDLE that would turn it into a Decimal calculator instead of a binary
float calculator. Adding Decimal as a supported type (which would have
to happen if Python gets Decimal literals, but could be done in other
ways too) would help, though it's not strictly necessary.
mod=ast.parse(print(0.1 + 0.2))
exec(compile(mod,-,exec))
0.30004
mod.body[0].value.args[0].left.n=Decimal(0.1)
mod.body[0].value.args[0].right.n=Decimal(0.2)
exec(compile(mod,-,exec))
Traceback (most recent call last):
File pyshell#28, line 1, in module
exec(compile(mod,-,exec))
TypeError: non-numeric type in Num
But it can still be done, as long as it's possible to go back to the
original string - which currently it's not, short of parsing the
entire Python program manually.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516)
py y = Decimal(0.77787518)
py (x + y) / 2
Decimal('0.77787515')
Guido, why can't Python do maths???
Well, you need to work within the system:
(5*x + 5*y) / 10
Decimal('0.77787517')
Actually, I have no idea whether that formula can be relied upon or
the correctness of the above was just luck.
--
https://mail.python.org/mailman/listinfo/python-list
Re: converting strings to hex
On 04/04/2014 04:22, dave em wrote:
You haven't seen nothing yet, wait till M.L. catches you on the flip
side for using gg. {running for cover}
Who is ML?
Good morning :)
--
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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 04/04/2014 03:29, Mark H Harris wrote:
Now, about Python2. It has not died. It appears to be 'useful'.
The perceived reality is that Python2 is 'useful'. Or, is it as I
perceive it, python2 is embedded in so many places that it must be
maintained for a long time because so many code(s) will break otherwise?
Not so much 'useful' as 'used,' so that it is never sacked.
Or, is it really that python2 is so much more 'suitable for a particular
purpose' ('useful') that certain folks just don't want to use python3?
Beats me; the community will have to decide.
For a lot of people, if it ain't broke, don't fix it.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
On Thu, 03 Apr 2014 11:23:39 -0700, Ethan Furman wrote: On 04/03/2014 09:02 AM, Lucas Malor wrote: In reply to Ian Kelly: Instead of disabling fallthrough by default, why not disable it all together? I was tempted but there are cases in which it's useful. An example switch day casein (Monday, Thursday, Wednesday, Tuesday, Friday): gotowork = True continue casein (Monday, Thursday, Wednesday, Tuesday, Friday): daytype = ferial casein (Saturday, Sunday) daytype = festive Absolutely not. Currently, the 'continue' key word means stop processing and go back to the beginning. It does not go back to the beginning. That would require resetting the iterable, which may be impossible. And if you succeeded, it would mean a loop with continue might never terminate! for i in (1, 2, 3): print(i) if i == 2: continue = prints: 1 2 1 2 1 2 1 ... Perhaps you mean continue from the top? But top and bottom is just an artifact of how we write the loop. The only direction that matters is iteration order, and I'm not aware of any language that allows for-loop iteration to go forward and backwards. continue means continue with the next iteration, as the documentation says: https://docs.python.org/3/reference/simple_stmts.html In some languages, it's even spelled next, e.g. Perl. (After a decade plus of reading and writing Python code, I still try to write next when I mean continue.) It's not a big stretch to go from continue with the next iteration to continue with the next case. You would have it mean keep going forward. Thus 'continue' would mean both go backwards and go forwards and would lead to unnecessary confusion. Well, there's certainly already some confusion :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
segmentation fault, executable python file
Hello, I generated an executable python file using cxfreeze. I run that file, it runs fine. But when I run it on another PC, it don't run. I try to it via terminal, and it says Segmentation fault(core dump). I try again run it with sudo, it says nothing and nothing happend. Could any of you please let me know how to fix this? -- https://mail.python.org/mailman/listinfo/python-list
Re: segmentation fault, executable python file
On Fri, Apr 4, 2014 at 7:36 PM, fa...@itprovent.com wrote: Hello, I generated an executable python file using cxfreeze. I run that file, it runs fine. But when I run it on another PC, it don't run. I try to it via terminal, and it says Segmentation fault(core dump). I try again run it with sudo, it says nothing and nothing happend. Could any of you please let me know how to fix this? Freezing a Python script into a binary requires matching all sorts of things, including the word size (32-bit or 64-bit), most likely the versions of various shared libraries, and possibly other compatibilities as well. What are the two computers? I'm guessing your second one is some kind of Unix, but that's as much as I can tell. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: segmentation fault, executable python file
the first one is ubuntu 12.04 64-bit (where i generate the executable file), and the second one is the same. Any idea? I confused for days until today. Thanks for your replay On Friday, April 4, 2014 3:57:33 PM UTC+7, Chris Angelico wrote: On Fri, Apr 4, 2014 at 7:36 PM, fa...@itprovent.com wrote: Hello, I generated an executable python file using cxfreeze. I run that file, it runs fine. But when I run it on another PC, it don't run. I try to it via terminal, and it says Segmentation fault(core dump). I try again run it with sudo, it says nothing and nothing happend. Could any of you please let me know how to fix this? Freezing a Python script into a binary requires matching all sorts of things, including the word size (32-bit or 64-bit), most likely the versions of various shared libraries, and possibly other compatibilities as well. What are the two computers? I'm guessing your second one is some kind of Unix, but that's as much as I can tell. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: segmentation fault, executable python file
On Fri, Apr 4, 2014 at 8:06 PM, fa...@itprovent.com wrote: the first one is ubuntu 12.04 64-bit (where i generate the executable file), and the second one is the same. Any idea? I confused for days until today. Thanks for your replay That's a good start. Next thing to try is running your executable under gdb; instead of getting a simple Segmentation fault message, you get some chance at a bit more info. But from here you need someone more familiar with cxfreeze. All I can advise is to compare installed packages on each; maybe you have multiple versions of some library or something. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
Instead of disabling fallthrough by default, why not disable it all together? I was tempted but there are cases in which it's useful. An example No, it is never useful, it never was. It came into being by accident, a design bug turned into an advertised feature. switch day casein (Monday, Thursday, Wednesday, Tuesday, Friday): gotowork = True continue casein (Monday, Thursday, Wednesday, Tuesday, Friday): daytype = ferial casein (Saturday, Sunday) daytype = festive That casein next to switch bugs me. Did I already propose: switch: local_sabbath() case (1, 2, 3) as sabbath: ... case 6: ... else: ... The key is to look at precedents: try: ... except (E1, E2) as e: ... except ...: ... finally: ... and: lambda: expression The switch: day format is a hybrid of the try and lambda syntaxes and would be compatible with existing Python editors as well as general Python sensibilities. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote: On 4/1/14 5:33 PM, Terry Reedy wrote: hi Terry, hope you are well today, despite gmane difficulties; If you narrowly meant The python interpreter only starting using unicode as the default text class in 3.0, then you are, in that narrow sense, correct. Yes. When I speak of 'python' I am almost always speaking about the interpreter. Which interpreter? PyPy, Numba, Nuitka, or perhaps even the newest in the family, Pyston? https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based- python-implementation/ Wait, all of those are compilers! Nuitka is a static compiler, the others are JIT compilers. Perhaps you meant Jython, IronPython, or Stackless? They're all interpreters. Ah, they're compilers too! Specifically, byte-code compilers. There's even a compile() built-in function. I'm not just being pedantic for the sake of being annoying[1], there's an important point here. Namely, that we shouldn't conflate Python the language with any one specific compiler or interpreter. Not even -- *especially* not even -- CPython the reference implementation. So we have Python *the language*, and any of a number of implementations. By my count, including experimental, obsolete and abandoned versions, I know of at least 50 different implementations, at least 10 of which might count as the Python interpreter for somebody. So the question is, when you speak of Python, do you mean *a specific implementation*, or do you mean *the language*? If I speak of the python community, and I rarely do, I explicitly use the word 'community'. I am concerned with backward compatibility in my own stuff, but I am primarily interested in python3, and I have made the conscious decision to use only python3 moving forward, except in those cases (like QPython 2.7.2 on the Android platform ). So, python(3)'s use of unicode is exciting, not only as a step forward for the python interpreter, but also as a leadership step forward in computer science around the world. I appreciate your enthusiasm, but let's not get too excited. Python is neither the first, nor the most influential, language to include Unicode. And as for it being a leadership step in computer science, that's rather like me proclaiming that my local take-away Italian restaurant shifting to gluten-free pasta is a revolution in chemistry. Python is not a computer-science-ey language. It is of little or no interest to computer scientists involved in the mathematics of computation, or compiler-theory, or type-theory, or any of the other academic disciplines under comp-sci. It's true that you might get a semester or two of learning Python in a comp-sci course (but more likely to be Java), but that's only because students have to be taught *something*. Comp-sci researchers are far more likely to be using something like Mercury or Haskell, not Python. Unicode is completely uninteresting to comp-sci. Whether strings contain 127 symbols or 1114112 or 2 is just a boring detail. [...] On the python unicode continuum version (3) is more useful than version (2). ( this is of course relative and debatable, so the statement is rhetorical ) Now that's funny. You make a completely non-controversial statement, that Python 3's Unicode implementation is more useful (i.e. more functionally complete, fewer design flaws, more efficient) than Python 2's, and *that* is the claim that you smother to death in disclaimers. Whereas other statements you make, which sometimes have been as wrong as an utterly wrong thing, you've been prepared to go to the battlements and fight to the death over. [1] Although that's a bonus *wink* -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: converting strings to hex
On Thu, 03 Apr 2014 21:38:38 -0500, Mark H Harris wrote: On 4/3/14 9:10 PM, dave em wrote: I am taking a cryptography class and am having a tough time with an assignment similar to this. hi Dave, if your instructor wanted you to work on this with other people she would have made it a group project and ordered pizza for everyone. I'll give you some credit, that last couple of folks that wanted help with their homework here could not bring themselves to admit they wanted help with their homework. :) HAL, please help me with my homework! I'm sorry, Dave, I can't do that... HAL!!? I'm sorry, Dave, I just can't do that... marcus in general i would say:- Can you 'HELP' with my homework? is resonable Can you 'DO' my homework for me if wrong Not even mentioning it is homework is really taking the P**s Dave has been open Shown his existing work received assistance on a minor correction, isn't that how we all learn :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:
On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516) py y =
Decimal(0.77787518) py (x + y) / 2
Decimal('0.77787515')
Guido, why can't Python do maths???
Well, you need to work within the system:
(5*x + 5*y) / 10
Decimal('0.77787517')
Actually, I have no idea whether that formula can be relied upon or the
correctness of the above was just luck.
And what happens when x+y would have been calculated correctly, but one,
or both, of 5*x or 5*y loses catastrophically loses accuracy due to
overflow?
py x = 3.1e307
py y = 3.3e307
py (x+y)/2
3.2e+307
py (5*x+5*y)/10
inf
(I've used regular floats here out of laziness, the same principle
applies to Decimals -- there will be *some* number x which is finite, but
5*x overflows to infinity.)
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Friday, April 4, 2014 3:23:31 PM UTC+5:30, Steven D'Aprano wrote: On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote: On 4/1/14 5:33 PM, Terry Reedy wrote: hi Terry, hope you are well today, despite gmane difficulties; If you narrowly meant The python interpreter only starting using unicode as the default text class in 3.0, then you are, in that narrow sense, correct. Yes. When I speak of 'python' I am almost always speaking about the interpreter. Which interpreter? PyPy, Numba, Nuitka, or perhaps even the newest in the family, Pyston? https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based- python-implementation/ Wait, all of those are compilers! Nuitka is a static compiler, the others are JIT compilers. Perhaps you meant Jython, IronPython, or Stackless? They're all interpreters. Ah, they're compilers too! Specifically, byte-code compilers. There's even a compile() built-in function. I'm not just being pedantic for the sake of being annoying[1], I thought you were being statistic... Now who was the chap with the new statistics module? -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/2014 5:53 AM, Steven D'Aprano wrote: On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote: On 4/1/14 5:33 PM, Terry Reedy wrote: If you narrowly meant The python interpreter only starting using unicode as the default text class in 3.0, then you are, in that narrow sense, correct. I really should have said 3.0 was the first version of Python (the language) to specify that code and strings are unicode Yes. When I speak of 'python' I am almost always speaking about the interpreter. Which interpreter? Since the unicode change is a language and not an interpreter issue, it does not matter. Unicode is completely uninteresting to comp-sci. Whether strings contain 127 symbols or 1114112 or 2 is just a boring detail. Until CS researchers want to write academic papers with non-ascii symbols ;-). On the python unicode continuum version (3) is more useful than version (2). ( this is of course relative and debatable, so the statement is rhetorical ) Now that's funny. I agree. You make a completely non-controversial statement, that Python 3's Unicode implementation is more useful (i.e. more functionally complete, fewer design flaws, more efficient) than Python 2's, and *that* is the claim that you smother to death in disclaimers. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: segmentation fault, executable python file
Hi. On 4.4.2014. 11:17, Chris Angelico wrote: But from here you need someone more familiar with cxfreeze. All I can advise is to compare installed packages on each; maybe you have multiple versions of some library or something. From what little I know of it, it freezes as little as possible of Python's modules into the executable and stores the remaining Python code in a single zip file and loads it from there at run-time. That should limit your search area to just the frozen part and externally used libraries, and my instinct tells me gdb should be able to point you in the culprit's direction in no time. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
CFP: MuCoCoS-2014, August, Porto, Portugal
7th International Workshop on Multi/many-Core Computing Systems (MuCoCoS-2014) in conjunction with Euro-Par 2014 25-29 August, 2014, Porto, Portugal http://www.univie.ac.at/mucocos2014 AIMS AND SCOPE The pervasiveness of homogeneous and heterogeneous multi-core and many-core processors, in a large spectrum of systems from embedded and general-purpose to high-end computing systems, poses major challenges to the software industry. In general, there is no guarantee that software developed for a particular architecture will run on another architecture. Furthermore, ensuring that the software preserves some aspects of performance behavior (such as temporal or energy efficiency) across different such architectures is an open research issue. Therefore, a focus of this workshop is on language level, system software and architectural solutions for performance portability across different architectures and for automated performance tuning. The topics of the MuCoCoS workshop include but are not limited to: - Programming models, languages, libraries and compilation techniques - Run-time systems and hardware support - Automatic performance tuning and optimization techniques - Patterns, algorithms and data structures for multi-/many-core systems - Performance measurement, modeling, analysis and tuning - Case studies highlighting performance portability and tuning. As the seventh workshop in the series MuCoCoS 2008 (Barcelona, Spain), MuCoCoS 2009 (Fukuoka, Japan), MuCoCoS 2010 (Krakow, Poland), MuCoCoS 2011 (Seoul, Korea), MuCoCoS 2012 (Salt Lake City, USA), and MuCoCoS 2013 (Edinburgh, UK), MuCoCoS 2014 will be held in Porto, Portugal, in conjunction with Euro-Par 2014. SUBMISSION GUIDELINES Full papers should not exceed 12 pages in the Springer LNCS style. Paper submission has to be performed electronically via the conference Web site in PDF format. MuCoCoS-2014 submission site: https://www.easychair.org/conferences/?conf=europar2014ws (Please select the track: Seventh International Workshop on Multi-/Many-core Computing Systems) Papers accepted for publication must also be supplied in source form (LaTeX). The 12 pages limit is a hard limit. It includes everything (text, figures, references) and will be strictly enforced by the submission system. Download LNCS Latex style: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Papers must offer original contributions. Only contributions not submitted elsewhere for publication will be considered. All accepted papers will be included in the Europar-2014 workshop proceedings, published by Springer in the LNCS series after the workshop. Authors of accepted papers will be requested to sign a Springer copyright form. Submissions are handled through the EasyChair conference system. https://www.easychair.org/conferences/?conf=europar2014ws Once logged into the system select the track: Seventh International Workshop on Multi-/Many-core Computing Systems) IMPORTANT DATES Workshop papers due: May 30, 2014 Workshop author notification: July 4, 2014 Workshop early registration: July 25, 2014 Workshop camera-ready papers due: October 3, 2014 Workshop date: tba WORKSHOP ORGANIZATION Siegfried Benkner, University of Vienna, Austria, program chair Sabri Pllana, Linnaeus University, Sweden, co-chair PROGRAM COMMITTEE - Beverly Bachmayer, Intel, Germany - Eduardo Cesar, Universitat Autonoma de Barcelona, Spain - Milind Chabbi, Rice University, USA - Jiri Dokuli, University of Vienna, Austria - Franz Franchetti, Carnegie Mellon University, USA - Michael Gerndt, TU Munich, Germany - Joerg Keller, FernUniv. Hagen, Germany - Christoph Kessler, Linkoping University, Sweden - Erwin Laure, KTH, Sweden - Renato Miceli, Irish Centre for High-End Computing, Ireland - Lasse Natvig, NTNU Trondheim, Norway - Beniamino Di Martino, Seconda Universita' di Napoli, Italy - Samuel Thibault, Univ. Bordeaux, France - Philippas Tsigas, Chalmers Univ., Sweden - Josef Weidendorfer, TU Munich, Germany -- https://mail.python.org/mailman/listinfo/python-list
Re: Default mutable parameters in functions
On Thu, Apr 3, 2014, at 20:38, Mark Lawrence wrote: I just wish I had a quid for every time somebody expects something out of Python, that way I'd have retired years ago. At least here it's not accompanied by as that's how it works in some other language. I can't imagine a language that would work that way. For one, it would also imply that passing a value would change the default for future calls even for non-mutable types. -- https://mail.python.org/mailman/listinfo/python-list
Jesus: an Islamic view
Jesus: an Islamic view In this pamphlet, the author shows the nature of the Prophet Jesus as Islam provides. He shows that the Prophet Jesus is a human prophet and does not have any divine nature as Christian believe. Did you know that it is obligatory for Muslims to believe in Jesus, or that a record of Jesus' life and teachings is preserved in the Qur'an and sayings of Muhammad, as well as in little-known traditions handed down by Muslim communities over the centuries? Christians brought up in the West are often surprised to discover Muslims who are familiar with the life and teachings of Jesus through the teachings and scriptures of Islam, while they themselves are unlikely to have learned anything about the Prophet Muhammad at church. This is partly a matter of history: Islam incorporates the Judeo-Christian tradition and embraces Jesus in the same way that Christianity incorporates the Old Testament and embraces Moses (peace be upon them both). All three religions trace their roots to Abraham, and in fact the Qur'an and the Bible share and uphold many beliefs, practices and virtues in common -- belief in God, angels and the Day of Judgement, in the virtues of prayer, charity and fasting, and in the importance of truthfulness, patience, and love. Together, Christians and Muslims make up more than half the world's population, and rather than being ideological opposites as some people imagine, their faiths are in many ways the most alike of the wor ld's major religions. Early Muslims were granted protection in Christian Abyssinia This common ground is one of the reasons the Prophet Muhammad (PBH) advised the weak and poor among his early followers to seek refuge in Christian Abyssinia (present-day Ethiopia) to escape persecution by the idolatrous Arab tribes, before Islam became established in Arabia. Muslim historians' account of the event succinctly conveys the heart of the relationship between the two faiths. When the corrupt leaders of Makkah pursued the Muslims into Africa and asked the Negus to return them, the Abyssinian ruler summoned the small community of Muslims, then asked them: 'What is this religion which has caused you to become separate from your people, though you have not entered my religion or that of any other folk around us?' Their spokesman Ja'far, Muhammad's young cousin, replied, 'O King, we were a people steeped in ignorance, worshipping idols, eating unslaughtered meat, committing abominations, and the strong would devour the weak. That is how we were until God sent us a Messenger from out of our midst, one whose lineage was known to us, and whose truthfulness, trustworthiness and integrity were renowned. He called us to God - that we should testify to His Oneness, and worship Him and renounce what we and our ancestors had worshipped in the way of stones and idols; and he commanded us to speak truly, to fulfil our promises, to respect the ties of kinship and the rights of our neighbours, and to refrain from crimes and bloodshed. So we worship God alone, setting nothing beside Him, counting as forbidden what He has forbidden and as permissible what He has allowed. For these reasons have our people turned against us, and persecuted us to try to make us forsake our religion and revert from the worship o f God to the worship of idols. That is why we have come to your country, having chosen you above all others, We have been happy under your protection, and it is our hope, O King, that here with you we shall not suffer wrong.' His speech was translated by the royal interpreters, after which the Negus asked if they had with them any revelation their prophet had brought them. Ja'far then recited the following verses of the Qur'an, from the chapter entitled 'Mary': And make mention of Mary in the Scripture, when she withdrew from her people to a place towards the east, and secluded herself from them. We sent to her Our spirit (the angel Gabriel), and he appeared to her in the likeness of a perfect man. She said, 'I seek refuge in the Compassionate God from you; (do not come near me) if you fear the Lord.' He replied, 'I am none other than a messenger from your Lord, (to announce) to you the gift of a pure son.' She said, 'How can I have a son when no man has touched me, nor am I unchaste?' He said, 'Even so will it be; your Lord says, This is an easy thing for Me. And We shall make him a sign for humanity and a mercy from Us. So it has been decreed.'(Qur'an 19: 16-21) Ja'far's recitation and the translation of these verses brought tears to the king's eyes. He responded, 'This has truly come from the same source as that which Jesus brought.' He granted the Muslims his protection. But the tribesmen of Makkah, furious that their plans and alliances had been frustrated, decided to rouse the king's ire against their monotheist cousins by playing up the differences between Christianity and Islam regarding
Re: Default mutable parameters in functions
On Fri, 04 Apr 2014 10:00:25 -0400, random832 wrote: On Thu, Apr 3, 2014, at 20:38, Mark Lawrence wrote: I just wish I had a quid for every time somebody expects something out of Python, that way I'd have retired years ago. At least here it's not accompanied by as that's how it works in some other language. I can't imagine a language that would work that way. That seems like a failure of imagination to me. At least, I can't imagine anyone unable to imagine a language like that :-P For one, it would also imply that passing a value would change the default for future calls even for non-mutable types. Not all programming languages distinguish between mutable and non-mutable types. Or for that matter even have types. But it's not hard to get that effect in Python, mutable or immutable doesn't matter: py def spam(count, food=spam): ... spam.__defaults__ = (food,) ... return food*count ... py spam(5) 'spamspamspamspamspam' py spam(3, 'eggs') 'eggseggseggs' py spam(5) 'eggseggseggseggseggs' py spam(5, 3) 15 py spam(4) 12 Is it so unusual for a function to want to store persistent state which survives from one call to another but may also vary from time to time? Managing situations like that is one of the reasons OOP was invented! -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
On Apr 4, 2014 3:51 AM, Marko Rauhamaa ma...@pacujo.net wrote: switch day casein (Monday, Thursday, Wednesday, Tuesday, Friday): gotowork = True continue casein (Monday, Thursday, Wednesday, Tuesday, Friday): daytype = ferial casein (Saturday, Sunday) daytype = festive That casein next to switch bugs me. Did I already propose: switch: local_sabbath() case (1, 2, 3) as sabbath: ... case 6: ... else: ... I don't get what this is intended to do. First, why is the expression in the first line after the colon? That doesn't match any existing block syntax (as you note it matches lambda, but that's an expression-level syntax). What's wrong with the much more natural switch local_sabbath():? Second, as clauses are used in other contexts for local assignment. What is the purpose of doing that here? How does this solve the problem of explicitly denoting case multiplicity? -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
If one were to add switch into Python, wouldn't it be desirable to make a pattern matching switch (think the match or case construct from Haskell or ML)? Python currently has poor support for union/sum types in general, not just enumerations. It feels weird to add better support for enumerations while ignoring the broader use case. If a switch statement gets added to Python and I still need to examine ASTs by a long chain of if-elif and isinstance and so on I will cry. -- Devin On Wed, Apr 2, 2014 at 7:53 AM, Lucas Malor 3kywjyd...@snkmail.com wrote: Hi all. I would proposeto you all a switch-case syntax for Python. I already read PEP 3103 and I'm not completely satisfied by any of the proposed solutions. This is my proposal: switch_stmt ::= switch identifier case expression_list : suite (case expression_list : suite)* [else : suite] or, more simply: switch x case var1: case var2: ... case var3: ... else: ... Expression list should yield an iterable. The case suite will be executed if the variable of the identifier is a member of the iterable. For example, in a switch x statement, the code case iterable: is identical to if x in iterable: (or elif etc). So if you want to perform the same case block for more than one value, you have only to specify a tuple, a range etc. I would suggest to add an exception for non-iterable variables, so that you don't have to write case var, : but simply case var: and it will be identical to if x == var: . It's a bit tricky but the alternative is ugly. Fallthrough is disabled by default. The continue keyword cause to skip all the remaining current case suite. The next case will be checked. You can't use the continue keyword in the else clause. Some random remarks: 1. switch is on the same line of the first case. This will avoid any unpythonic syntaxes like: switch x case var1: ... or switch x: case var1: ... 2. Fallthrough is disabled by default because IMHO it's what non-programmers expect and that's what programmer usually needs more. I don't think a switch with such a syntax needs a break statement. 3. As an alternative, the continue statement could be written only at the end of a case suite; it will be less powerful and not consistent with the other compound statements, but it will improve readability. 4. I decided to not use already existing keyword like if or in, since it will be misleading and problematic for syntax highlighters. Tell me what you think about. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
Ian Kelly ian.g.ke...@gmail.com:
On Apr 4, 2014 3:51 AM, Marko Rauhamaa ma...@pacujo.net wrote:
switch: local_sabbath()
case (1, 2, 3) as sabbath:
...
case 6:
...
else:
...
[...]
What's wrong with the much more natural switch local_sabbath():?
Consider:
switch local_sabbath():# bad
case (1, 2, 3) as sabbath:
...
Now Python framing requires that you place something between the first
: and case:
switch local_sabbath():# bad
pass
case (1, 2, 3) as sabbath:
...
Placing the expression after the colon terminates the first colon
cleanly. Also, the lambda precedent allows an expression to follow a
colon; both lambda and my switch mandate that the expression stay on
the same line with the colon.
Second, as clauses are used in other contexts for local assignment.
What is the purpose of doing that here? How does this solve the
problem of explicitly denoting case multiplicity?
The as clause follows the precedent of the try/except statement. It
removes the occasional annoyance in C:
switch (next_char()) {
case '\n':
case '\r':
putchar(???);
: : :
which forces you to introduce a temporary variable:
char c;
: : :
c = next_char();
switch (c) {
case '\n':
case '\r':
putchar(c);
: : :
It is most useful in the default/else branch:
switch: q.pop()
case 0:
log_direction(0)
return 1
case (90, 270) as angle:
log_direction(angle)
return 0
case 180:
log_direction(180)
return -1
else angle:
log_direction(angle)
return math.cos(angle * 2 * PI / 360)
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 4:08 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:
On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516) py y =
Decimal(0.77787518) py (x + y) / 2
Decimal('0.77787515')
Guido, why can't Python do maths???
Well, you need to work within the system:
(5*x + 5*y) / 10
Decimal('0.77787517')
Actually, I have no idea whether that formula can be relied upon or the
correctness of the above was just luck.
And what happens when x+y would have been calculated correctly, but one,
or both, of 5*x or 5*y loses catastrophically loses accuracy due to
overflow?
py x = 3.1e307
py y = 3.3e307
py (x+y)/2
3.2e+307
py (5*x+5*y)/10
inf
(I've used regular floats here out of laziness, the same principle
applies to Decimals -- there will be *some* number x which is finite, but
5*x overflows to infinity.)
I thought that Decimals had arbitrary-precision exponents, at least in
the pure Python version. Turns out that's wrong; although the
context.Emax can be set to any int in the pure Python version, it
can't be removed entirely. One could just temporarily upgrade the
Emax for the above calculation, but the pure Python version was made
inconvenient to use voluntarily in CPython 3.3, and the C version has
strict limits.
In any event, the exponent limits for decimals are much higher than
for floats (the default Emax is 99, and it can be set roughly
within the limits of C integer precision), so any case where you'll
get overflow with a Decimal is already far beyond the point where
you'd have gotten overflow with a float.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
On Fri, Apr 4, 2014 at 10:44 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Consider:
switch local_sabbath():# bad
case (1, 2, 3) as sabbath:
...
I'm not overly fond of that either. That's why I liked the OP's
choice to put the first case in the switch statement.
Now Python framing requires that you place something between the first
: and case:
switch local_sabbath():# bad
pass
case (1, 2, 3) as sabbath:
...
That's absurd. Granted that omitting the pass doesn't match any
existing syntax, but that doesn't mean it *must* be done that way.
Placing the expression after the colon terminates the first colon
cleanly. Also, the lambda precedent allows an expression to follow a
colon; both lambda and my switch mandate that the expression stay on
the same line with the colon.
But in the case of the lambda *expression*, the following expression
is effectively the entire suite of the lambda clause, mirroring
the form of a def statement. If local_sabbath() is treated as the
suite of the switch *statement*, then Python framing tells us the
same construct could be written like this:
switch:
local_sabbath()
case 1:
...
And if that's allowed, then why not this?
switch:
if username == ozzy:
black_sabbath()
else:
local_sabbath()
case 1:
...
Or:
switch:
for sabbath in list_of_sabbaths:
sabbath
case 1:
...
Or even:
switch:
pass
case 1:
...
The intent of the first two are fairly clear, but they're way out of
scope for a switch statement. I don't even intuitively know what to
do with the last two. The point here is that the switch expression
really ought to be a single expression contained in the switch header,
not a suite.
Second, as clauses are used in other contexts for local assignment.
What is the purpose of doing that here? How does this solve the
problem of explicitly denoting case multiplicity?
The as clause follows the precedent of the try/except statement. It
removes the occasional annoyance in C:
switch (next_char()) {
case '\n':
case '\r':
putchar(???);
: : :
which forces you to introduce a temporary variable:
How is the target identifier of the as not a temporary variable?
Try/except statements and with statements use as keywords to capture
values that may not otherwise be available in scope for assignment.
Except assigns the exception instance that was just caught, and with
assigns whatever arbitrary object was returned by the context
manager's __enter__ method. With switch there is no need for that;
just do this:
char = next_char()
switch next_char:
case in '\n\r':
print(char)
Similarly there is no need for the if or while statements to
support an as keyword, as in:
while next_char() as char:
print(char)
There are good reasons why the language generally does not allow
assignments in non-assignment statements, which is what your as is
trying to do. The Pythonic way to write that loop is:
while True:
char = next_char()
if not char: break
print(char)
Which is at least as ungraceful as assigning the switch variable
before the switch statement.
--
https://mail.python.org/mailman/listinfo/python-list
Scoping rules for class definitions
Hi all. I thought I had a pretty good grasp of Python's scoping rules, but today I noticed something that I don't understand. Can anyone explain to me why this happens? x = 'global' def f1(): x = 'local' class C: y = x return C.y def f2(): x = 'local' class C: x = x return C.x f1() 'local' f2() 'global' -- https://mail.python.org/mailman/listinfo/python-list
Re: Scoping rules for class definitions
On Fri, Apr 4, 2014 at 12:37 PM, Rotwang sg...@hotmail.co.uk wrote:
Hi all. I thought I had a pretty good grasp of Python's scoping rules, but
today I noticed something that I don't understand. Can anyone explain to me
why this happens?
x = 'global'
def f1():
x = 'local'
class C:
y = x
return C.y
def f2():
x = 'local'
class C:
x = x
return C.x
f1()
'local'
f2()
'global'
Start by comparing the disassembly of the two class bodies:
dis.dis(f1.__code__.co_consts[2])
3 0 LOAD_NAME0 (__name__)
3 STORE_NAME 1 (__module__)
6 LOAD_CONST 0 ('f1.locals.C')
9 STORE_NAME 2 (__qualname__)
4 12 LOAD_CLASSDEREF 0 (x)
15 STORE_NAME 3 (y)
18 LOAD_CONST 1 (None)
21 RETURN_VALUE
dis.dis(f2.__code__.co_consts[2])
3 0 LOAD_NAME0 (__name__)
3 STORE_NAME 1 (__module__)
6 LOAD_CONST 0 ('f2.locals.C')
9 STORE_NAME 2 (__qualname__)
4 12 LOAD_NAME3 (x)
15 STORE_NAME 3 (x)
18 LOAD_CONST 1 (None)
21 RETURN_VALUE
The only significant difference is that the first uses
LOAD_CLASSDEREF, which I guess is the class version of LOAD_DEREF for
loading values from closures, at line 4 whereas the second uses
LOAD_NAME. So the first one knows about the x in the nonlocal scope,
whereas the second does not and just loads the global (since x doesn't
yet exist in the locals dict).
Now why doesn't the second version also use LOAD_CLASSDEREF? My guess
is because it's the name of a local; if it were referenced a second
time in the class then the second LOAD_CLASSDEREF would again get the
x from the nonlocal scope, which would be incorrect.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 3:20 AM, Mark Lawrence wrote:
On 04/04/2014 03:29, Mark H Harris wrote:
Now, about Python2. It has not died. It appears to be 'useful'.
{snip}
For a lot of people, if it ain't broke, don't fix it.
hi Mark, yes that's my point. I have heard rumors of python2.8? At some
point I would expect that the Cpython interpreter would 'freeze' and no
one would fix it any longer. I have a serious question, namely, why does
the Cpython community continue to suppport two interpreters rather than
asking the Cpython user-base to migrate to Cpython3?
Oh, I have another serious question about implementations. I'm not sure
about (50) implementations, but I know that Jython and IronPython are
serious contenders (although, I have not, nor probably will, use them).
Are the other implementation communities *also* supporting two versions
of the language? Is there a Jython2 also a Jython3 ?
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: converting strings to hex
On 4/4/14 1:16 AM, James Harris wrote: YMMV but I thought the OP had done a good job before asking for help and then asked about only a tiny bit of it. Some just post a question! Indeed they do. Its a little like negotiating with terrorists. As soon as you negotiate with the first one, you then must negotiate with all of them. Bad plan. The OP was s close, that to give him the help is immoral for two reasons: 1) it deprives him of the satisfaction of accomplishing the solution to the puzzle himself, and 2) it deprives the instructor (whoever she is) of the teachable moment. There is something she is trying to get Dave to learn, and she really *does* want him to go through the entire exercise on his own. Other than that, I give the OP credit for honesty and the good 'ol college try. But next time I'd like to see Dave post the problem (and his own solution) and then let the professional Cpython community pipe up on enhancements, or challenges. That way the OP learns twice. You might find this interesting. http://sundry.wikispaces.com/transcript-2001 Indeed I do. I was thirteen when Odyssey came out. I was so impressed with the ship, and yet so disappointed with HAL. My favorite line, I'm sorry, Dave, I'm afraid I can't do that, *must* have the word 'afraid' in there; the HAL 9000 not only had mental illness, will, but also classic controlled emotion... but HAL's soft confident assured voice pattern was fabulous, wasn't it? My second favorite line was, Look Dave, I can see you're really upset about this, as Dave was unplugging HAL's neural net. Classic. It was not until my later career at IBM did I realize that 'HAL' was one letter -0ff from 'IBM'; just never thought about it before. Hilarious. Wasn't it interesting that Kubrick and Clarke were concerned about machines acquiring will and emotion (or mental illness) before anyone got those von Neumann processors to 'think' in the first place? Which, of course, because of the negative answer to the Entscheidungsproblem is not possible. This was a passion of Alan Turing; machines thinking I mean. We're going to find that thinking machine IS possible, but that the system is going to require multiple quantum processors running together (out of phase with one another) in order to be self-aware. I think it will happen in my life-time; I'm encouraged with the work so far... I'm sorry, Dave, I'm afraid I can't do that... ... Look Dave, I can see you're really upset about this... marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 2:58 PM, Mark H Harris harrismh...@gmail.com wrote:
On 4/4/14 3:20 AM, Mark Lawrence wrote:
On 04/04/2014 03:29, Mark H Harris wrote:
Now, about Python2. It has not died. It appears to be 'useful'.
{snip}
For a lot of people, if it ain't broke, don't fix it.
hi Mark, yes that's my point. I have heard rumors of python2.8?
The Python 2.8 release schedule is documented in PEP 404:
http://legacy.python.org/dev/peps/pep-0404/
At some
point I would expect that the Cpython interpreter would 'freeze' and no one
would fix it any longer. I have a serious question, namely, why does the
Cpython community continue to suppport two interpreters rather than asking
the Cpython user-base to migrate to Cpython3?
2.6 and 2.7 exist to ease the pain of migration, which is far from
trivial. Eventually users still on 2.x will need to upgrade, but you
can't force them to do it on your own schedule. That path will just
end up driving them to another language, or to a fork of 2.7.
Oh, I have another serious question about implementations. I'm not sure
about (50) implementations, but I know that Jython and IronPython are
serious contenders (although, I have not, nor probably will, use them).
Are the other implementation communities *also* supporting two versions of
the language? Is there a Jython2 also a Jython3 ?
There is no Jython3 or IronPython3 yet. PyPy is currently supporting
both 2.7 and 3.2.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 04/04/2014 21:58, Mark H Harris wrote:
On 4/4/14 3:20 AM, Mark Lawrence wrote:
On 04/04/2014 03:29, Mark H Harris wrote:
Now, about Python2. It has not died. It appears to be 'useful'.
{snip}
For a lot of people, if it ain't broke, don't fix it.
hi Mark, yes that's my point. I have heard rumors of python2.8? At some
point I would expect that the Cpython interpreter would 'freeze' and no
one would fix it any longer. I have a serious question, namely, why does
the Cpython community continue to suppport two interpreters rather than
asking the Cpython user-base to migrate to Cpython3?
Oh, I have another serious question about implementations. I'm not sure
about (50) implementations, but I know that Jython and IronPython are
serious contenders (although, I have not, nor probably will, use them).
Are the other implementation communities *also* supporting two versions
of the language? Is there a Jython2 also a Jython3 ?
marcus
You could answer all of the above for yourself if you were to use your
favourite search engine.
--
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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 4:50 PM, Mark Lawrence wrote: You could answer all of the above for yourself if you were to use your favourite search engine. hi Mark, yeah, condescending as that is, been there done that. See this link as just one example: http://blog.startifact.com/posts/python28-discussion-channel-on-freenode.html Follow the nextpost- links for a while... at least the first two. You'll get a flavor for what I'm asking about. Its always better to get a straight answer from the core people than to rely on rumors and fork discussions found on google. PEP 404 is hilarious; I missed that one. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: converting strings to hex
On Sat, Apr 5, 2014 at 8:33 AM, Mark H Harris harrismh...@gmail.com wrote: On 4/4/14 1:16 AM, James Harris wrote: YMMV but I thought the OP had done a good job before asking for help and then asked about only a tiny bit of it. Some just post a question! Indeed they do. Its a little like negotiating with terrorists. As soon as you negotiate with the first one, you then must negotiate with all of them. Bad plan. What, you treat student programmers like terrorists?!? Ouch. The OP was s close, that to give him the help is immoral for two reasons: 1) it deprives him of the satisfaction of accomplishing the solution to the puzzle himself, and 2) it deprives the instructor (whoever she is) of the teachable moment. There is something she is trying to get Dave to learn, and she really *does* want him to go through the entire exercise on his own. I strongly disagree. If someone is asking for a hint, it's because s/he is trying to learn. I'm always willing to help someone learn, regardless of whether they're going through a course or currently employed or whatever. Sometimes a small hint can be obtained from the interpreter itself; but often, it takes a measure of experience to grok (one of the differences between the expert and the inexperienced is how quickly a traceback can be read - an expert can often go straight to the line with the problem); a hint from another Python programmer can be immensely helpful, as it can include advice as well as a hard this works, that doesn't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 9:07 AM, Mark H Harris harrismh...@gmail.com wrote: On 4/4/14 4:50 PM, Mark Lawrence wrote: You could answer all of the above for yourself if you were to use your favourite search engine. hi Mark, yeah, condescending as that is, been there done that. Its always better to get a straight answer from the core people than to rely on rumors and fork discussions found on google. Yes, because python-list responses are *so* much more reliable than official statements on python.org, which are easily found with a Google search. Or a DuckDuckGo search. Or a Bing search. Or probably even gopher, we're not partisan here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Default mutable parameters in functions
On Sat, Apr 5, 2014 at 1:34 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: But it's not hard to get that effect in Python, mutable or immutable doesn't matter: py def spam(count, food=spam): ... spam.__defaults__ = (food,) ... return food*count ... py spam(5) 'spamspamspamspamspam' py spam(3, 'eggs') 'eggseggseggs' py spam(5) 'eggseggseggseggseggs' py spam(5, 3) 15 py spam(4) 12 Is it so unusual for a function to want to store persistent state which survives from one call to another but may also vary from time to time? Managing situations like that is one of the reasons OOP was invented! Maybe it'd be clearer if we change the names around. def signal(sig, handler=None): ret = signals[sig] if handler: signals[sig] = handler return ret This neatly merges the definitions of signal.signal() and signal.getsignal(); per the docs: signal.getsignal(signalnum) Return the current signal handler for the signal signalnum. The returned value may be a callable Python object, or one of the special values signal.SIG_IGN, signal.SIG_DFL or None. Here, signal.SIG_IGN means that the signal was previously ignored, signal.SIG_DFL means that the default way of handling the signal was previously in use, and None means that the previous signal handler was not installed from Python. signal.signal(signalnum, handler) Set the handler for signal signalnum to the function handler. handler can be a callable Python object taking two arguments (see below), or one of the special values signal.SIG_IGN or signal.SIG_DFL. The previous signal handler will be returned (see the description of getsignal() above). (See the Unix man page signal(2).) (Incidentally, SIG_IGN and SIG_DFL are just integers. Are they targets for enumification?) signal(SIGINT, ctrl_c_handler) -- whatever the default is signal(SIGINT) ctrl_c_handler signal(SIGINT, other_ctrl_c_handler) ctrl_c_handler signal(SIGINT) other_ctrl_c_handler I think that's a perfectly reasonable API... it just doesn't happen to be how Python works by default. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 5:39 PM, Chris Angelico wrote:
Yes, because python-list responses are *so* much more reliable than
official statements on python.org,
{/sarcasm off}
... from some responders. The discussion following such posts is also
*much* more valuable, too. IMHO
Python.org is the political place to start; but its not much good after
that, in regards the forking of 2.7 -- 2.8
As Ian points out, you can't expect a complete migration on the PSF
schedule (2-3), because of the fear|panic of a fork. So,
comp.lang.python is the best place to find out where the Cpython
community is, and where they expect to go (for that discussion).
I realize that many of Cpython's user-base will never read
comp.lang.python, and then the Internet is an open field for trying to
discern where 'they' are at, and where 'they' want to go.
What I'm trying to say is that I tap many resources (comp.lang.python is
just one of them) and I'm going to tap that source even though I also
tap the Internet with a google search (and others).
Eeyore doesn't like to be bugged, by double line spaces, nor by
questions. What's the point of having a comp.lang.python news list if
its not open for simple questions of opinion? Yes, I know google is my
friend. Comp.lang.python should be my friend too.
(and others)
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 9:52 AM, Mark H Harris harrismh...@gmail.com wrote:
On 4/4/14 5:39 PM, Chris Angelico wrote:
Yes, because python-list responses are *so* much more reliable than
official statements on python.org,
{/sarcasm off}
... from some responders. The discussion following such posts is also *much*
more valuable, too. IMHO
Python.org is the political place to start; but its not much good after
that, in regards the forking of 2.7 -- 2.8
Official statements on python.org are the perfect place to find out
whether or not there'll be a 2.8. And that's exactly what PEP 404
details.
As Ian points out, you can't expect a complete migration on the PSF schedule
(2-3), because of the fear|panic of a fork. So, comp.lang.python is the
best place to find out where the Cpython community is, and where they expect
to go (for that discussion).
What *is* the PSF schedule? Have you read that? Do you know when the
PSF expects all code to transition from Py2 to Py3? Because you can
find that on python.org too (at least some estimates).
What I'm trying to say is that I tap many resources (comp.lang.python is
just one of them) and I'm going to tap that source even though I also tap
the Internet with a google search (and others).
Eeyore doesn't like to be bugged, by double line spaces, nor by questions.
What's the point of having a comp.lang.python news list if its not open for
simple questions of opinion? Yes, I know google is my friend.
Comp.lang.python should be my friend too.
You're certainly free to ask. And we're free to tell you to use a
search engine to find authoritative responses :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: converting strings to hex
On 4/4/14 5:36 PM, Chris Angelico wrote: If someone is asking for a hint, it's because s/he is trying to learn. I'm always willing to help someone learn, regardless of whether they're going through a course or currently employed or whatever. Sometimes a small hint can be obtained from the interpreter itself; but often, it takes a measure of experience to grok (one of the differences between the expert and the inexperienced is how quickly a traceback can be read - an expert can often go straight to the line with the problem); a hint from another Python programmer can be immensely helpful, as it can include advice as well as a hard this works, that doesn't. I accept that. It really depends case-by-case at what point the person asks for help ( tension is really a good teacher sometimes ) and at what level the help is provided ( give the hint, but maintain the tension ). I particularly agree with your statement above in every venue except the educational venue where the break-over moment (the teachable moment) is NOT the moment being queried ! If the student is NOT able to discover on their own that one 'moment' the teachable moment may be lost forever, and the student(s) never have the opportunity to visit that moment again. Now, was this one of those for Dave, who knows. Beats me. I do appreciate your disagreement, and I think you have a good point. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 04/04/2014 23:52, Mark H Harris wrote: As Ian points out, you can't expect a complete migration on the PSF schedule (2-3), because of the fear|panic of a fork. So, comp.lang.python is the best place to find out where the Cpython community is, and where they expect to go (for that discussion). Fear/panic of a fork, where did that come from? It's certainly the first I've ever heard of it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Default mutable parameters in functions
In article mailman.8908.1396653807.18130.python-l...@python.org, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Fri, 04 Apr 2014 10:00:25 -0400, random...@fastmail.us declaimed the following: I can't imagine a language that would work that way. For one, it would also imply that passing a value would change the default for future calls even for non-mutable types. Some early FORTRAN compilers purportedly had problems with, for example: X = 1 call mutant(1) Y = 1 where subroutine mutant(y) y = y + 1 return meant that Y now held the value of 2 -- that is, literals were stored in mutable memory, and since FORTRAN passes by reference, the address of the literal is passed, and the assignment changed the constant. Problem? I always assumed it was a feature :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, 04 Apr 2014 15:58:29 -0500, Mark H Harris wrote: Oh, I have another serious question about implementations. I'm not sure about (50) implementations, Here's a list. Which ones you count as actual implementations of Python and which are not may be a matter of opinion. (Do translators count? Supersets and subsets of the language? How many changes can one make before you have a completely different language? I haven't included obviously different languages like Cobra and Delight.) Berp, Brython, CLPython, CPython, CapPython, ChinesePython, Compyler, Copperhead, Cython, HoPe, HotPy, IronPython, Jython, Kivy, Mypy, Mython, Nuitka, Numba, Parakeet, Parallel Python, Perthon, Pippy, Psyco, Py4A, PyMite, PyMT, PyPad, PyPy, PyQNX, PyVM, Pycorn, Pyjamas, Pynie, Pystachio, Pyston, Python for .NET, Python for OS/2, Python for S60, Python-iPod, Python2C, Pythonce, Pythonium Core, Pythran, QPython, RapydScript, Shedskin, Skulpt, Stackless, TinyPy, Typhon, UnPython, Unladen Swallow, Vyper, WPython As I said, some of these may be abandoned, obsolete, experimental, or even vapourware. Some are probably just ports of CPython to another platform rather than completely independent implementations. The big four are CPython, IronPython, Jython and PyPy, although Stackless is still maintained and in active use as part of the EVE Online game. Stackless is older than all of them except CPython itself. Cython is a superset of Python, but it is capable of running pure Python code, so it counts as a Python compiler, and is in very active development and use. Nuitika is a static compiler written by a developer willing to go against the conventional wisdom that JIT compilers are the way to go for dynamic languages like Python, and he claims to have impressive speedups. but I know that Jython and IronPython are serious contenders (although, I have not, nor probably will, use them). If you are using a Debian-based system, it is trivial to install them via apt-get or aptitude: sudo aptitude install jython ironpython Are the other implementation communities *also* supporting two versions of the language? Is there a Jython2 also a Jython3 ? Not Jython or IronPython yet. As far as I know, the implementations which support Python 3 are CPython, Cython, Kivy, Nuitika and PyPy. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, 04 Apr 2014 11:01:48 -0600, Ian Kelly wrote:
On Fri, Apr 4, 2014 at 4:08 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:
On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516) py y =
Decimal(0.77787518) py (x + y) / 2
Decimal('0.77787515')
Guido, why can't Python do maths???
Well, you need to work within the system:
(5*x + 5*y) / 10
Decimal('0.77787517')
Actually, I have no idea whether that formula can be relied upon or
the correctness of the above was just luck.
And what happens when x+y would have been calculated correctly, but
one, or both, of 5*x or 5*y loses catastrophically loses accuracy due
to overflow?
py x = 3.1e307
py y = 3.3e307
py (x+y)/2
3.2e+307
py (5*x+5*y)/10
inf
(I've used regular floats here out of laziness, the same principle
applies to Decimals -- there will be *some* number x which is finite,
but 5*x overflows to infinity.)
I thought that Decimals had arbitrary-precision exponents, at least in
the pure Python version. Turns out that's wrong; although the
context.Emax can be set to any int in the pure Python version, it can't
be removed entirely. One could just temporarily upgrade the Emax for
the above calculation, but the pure Python version was made inconvenient
to use voluntarily in CPython 3.3, and the C version has strict limits.
In any event, the exponent limits for decimals are much higher than for
floats (the default Emax is 99, and it can be set roughly within the
limits of C integer precision), so any case where you'll get overflow
with a Decimal is already far beyond the point where you'd have gotten
overflow with a float.
If you write the most obvious code that works -- usually a good thing in
computing, but not always so in numeric computing -- and calculate
(x+y)/2, with Decimal, most of the time the result will be correct but
sometimes it won't be. In addition to that problem, if the addition
overflows you will get an inf instead of the correct answer.
But if you write the tricky code (5*x+5*y)/10, you may eliminate the
failure cases, but at the cost that while it will still overflow to inf
in the same cases as before, now it will also overflow in a whole lot of
cases that *would have worked correctly* if only you had written the
obvious code. There's no free lunch here.
You might argue that this doesn't matter, since the problem values for x
and y have been moved from scattered values everywhere to only(?)
values so huge that surely nobody will care. Apart, of course, those
people who do care. Still, I'm sympathetic to the idea that swapping
average doesn't work right for really humongous numbers overflow
sooner than they otherwise would have counts as a win.
But of course, neither of us know what other problems this tricky code
will introduce. Perhaps it fixes the failures for *some* values of x and
y, but introduces a different set of failures for *other* values of x and
y. I'm not quite good enough at numeric analysis to rule that out,
although I haven't tried very hard. (The division by 10 is obviously just
a shift, so its error is at most 0.5 ULP. But I'm not sure about the
multiplications by 5.)
But all of this is missing the really important point. Isn't the
(supposed) move to Decimal-by-default supposed to *simplify* numeric
calculations, not complicate them? Do we really expect the average non-
expert to write (5*x+5*y)/10 instead of the obvious (x+y)/2?
There's no doubt that binary floating point calculations are tricky
beasts, and while IEEE-754 semantics mean that they just about always do
the right thing, still, serious numeric work is half advanced mathematics
and half voodoo. Base-10 floats don't improve that situation, they make
it worse.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 11:00 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: As I said, some of these may be abandoned, obsolete, experimental, or even vapourware. Some are probably just ports of CPython to another platform rather than completely independent implementations. Python for OS/2 is definitely just a port. It's built from as close to unmodified sources as possible, and doesn't (deliberately) add/remove any features or anything. On the other hand, there's a Python for Android which may be a separate project. (Or is that the Py4A you referred to?) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Default mutable parameters in functions
Dennis Lee Bieber wlfr...@ix.netcom.com Wrote in message: On Fri, 04 Apr 2014 10:00:25 -0400, random...@fastmail.us declaimed the following: I can't imagine a language that would work that way. For one, it would also imply that passing a value would change the default for future calls even for non-mutable types. Some early FORTRAN compilers purportedly had problems with, for example: X = 1 call mutant(1) Y = 1 where subroutine mutant(y) y = y + 1 return meant that Y now held the value of 2 -- that is, literals were stored in mutable memory, and since FORTRAN passes by reference, the address of the literal is passed, and the assignment changed the constant. I can confirm that, first hand. In late 60's, CDC 6400, I deliberately wrote code to exploit that. Not for production of course. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
process do not join?
I am trying to debug my program that launch processes to run a function to copy
data between hosts located really far away from each other. The end of my
function are in the orders.py and mergedirs.py.
From this point onwards, in is python code. The problem is that this code
hangs in the last instruction forking(), instead of my program continue.
The call of my function were made with: outputs = parmap(mergeDirs, args). This
is my parmap function.
It seems that the function mergeDirs ends, but the process does not join. I
checked that the mergeDirs is working properly, because I ran the code without
processes, and it works fine.
I don't know what is happening. How can I debug this problem?
def parmap(f, X):
pipe = [Pipe() for x in X]
# 2 - what is happening with the tuples (c,x) and (p, c)?
proc = [Process(target=spawn(f), args=(c, x))
for x, (p, c) in zip(X, pipe)]
#[p.start() for p in proc]
for p in proc:
print(Spawn)
p.start()
#[p.join() for p in proc]
for p in proc:
print(Joining)
p.join()
return [p.recv() for (p, c) in pipe]
Copy data time: 104.863273859
orders.py(99): return cluster
mergedirs.py(48): return (new_included, command, poutput)
spawn.py(7): pipe.close()
process.py(259): exitcode = 0
process.py(261): util._exit_function()
--- modulename: util, funcname: _exit_function
util.py(303): info('process shutting down')
--- modulename: util, funcname: info
util.py(77): if _logger:
util.py(304): debug('running all atexit finalizers with priority = 0')
--- modulename: util, funcname: debug
util.py(73): if _logger:
util.py(305): _run_finalizers(0)
--- modulename: util, funcname: _run_finalizers
util.py(257): if _finalizer_registry is None:
util.py(263): if minpriority is None:
util.py(266): f = lambda p : p[0][0] is not None and p[0][0] =
minpriority
util.py(268): items = [x for x in _finalizer_registry.items() if f(x)]
util.py(269): items.sort(reverse=True)
util.py(271): for key, finalizer in items:
util.py(279): if minpriority is None:
util.py(307): if current_process() is not None:
--- modulename: process, funcname: current_process
process.py(63): return _current_process
util.py(318): for p in active_children():
--- modulename: process, funcname: active_children
process.py(69): _cleanup()
--- modulename: process, funcname: _cleanup
process.py(78): for p in list(_current_process._children):
process.py(70): return list(_current_process._children)
util.py(323): for p in active_children():
--- modulename: process, funcname: active_children
process.py(69): _cleanup()
--- modulename: process, funcname: _cleanup
process.py(78): for p in list(_current_process._children):
process.py(70): return list(_current_process._children)
util.py(327): debug('running the remaining atexit finalizers')
--- modulename: util, funcname: debug
util.py(73): if _logger:
util.py(328): _run_finalizers()
--- modulename: util, funcname: _run_finalizers
util.py(257): if _finalizer_registry is None:
util.py(263): if minpriority is None:
util.py(264): f = lambda p : p[0][0] is not None
util.py(268): items = [x for x in _finalizer_registry.items() if f(x)]
util.py(269): items.sort(reverse=True)
util.py(271): for key, finalizer in items:
util.py(279): if minpriority is None:
util.py(280): _finalizer_registry.clear()
process.py(278): util.info('process exiting with exitcode %d' %
exitcode)
--- modulename: util, funcname: info
util.py(77): if _logger:
process.py(279): return exitcode
forking.py(127): sys.stdout.flush()
forking.py(128): sys.stderr.flush()
forking.py(129): os._exit(code)
--
https://mail.python.org/mailman/listinfo/python-list
Re: process do not join?
This log came when I launched the command:
python -m trace --trace myclass.py
On Saturday, April 5, 2014 3:18:34 AM UTC+1, xeon Mailinglist wrote:
I am trying to debug my program that launch processes to run a function to
copy data between hosts located really far away from each other. The end of
my function are in the orders.py and mergedirs.py.
From this point onwards, in is python code. The problem is that this code
hangs in the last instruction forking(), instead of my program continue.
The call of my function were made with: outputs = parmap(mergeDirs, args).
This is my parmap function.
It seems that the function mergeDirs ends, but the process does not join. I
checked that the mergeDirs is working properly, because I ran the code
without processes, and it works fine.
I don't know what is happening. How can I debug this problem?
def parmap(f, X):
pipe = [Pipe() for x in X]
# 2 - what is happening with the tuples (c,x) and (p, c)?
proc = [Process(target=spawn(f), args=(c, x))
for x, (p, c) in zip(X, pipe)]
#[p.start() for p in proc]
for p in proc:
print(Spawn)
p.start()
#[p.join() for p in proc]
for p in proc:
print(Joining)
p.join()
return [p.recv() for (p, c) in pipe]
Copy data time: 104.863273859
orders.py(99): return cluster
mergedirs.py(48): return (new_included, command, poutput)
spawn.py(7): pipe.close()
process.py(259): exitcode = 0
process.py(261): util._exit_function()
--- modulename: util, funcname: _exit_function
util.py(303): info('process shutting down')
--- modulename: util, funcname: info
util.py(77): if _logger:
util.py(304): debug('running all atexit finalizers with priority = 0')
--- modulename: util, funcname: debug
util.py(73): if _logger:
util.py(305): _run_finalizers(0)
--- modulename: util, funcname: _run_finalizers
util.py(257): if _finalizer_registry is None:
util.py(263): if minpriority is None:
util.py(266): f = lambda p : p[0][0] is not None and p[0][0] =
minpriority
util.py(268): items = [x for x in _finalizer_registry.items() if f(x)]
util.py(269): items.sort(reverse=True)
util.py(271): for key, finalizer in items:
util.py(279): if minpriority is None:
util.py(307): if current_process() is not None:
--- modulename: process, funcname: current_process
process.py(63): return _current_process
util.py(318): for p in active_children():
--- modulename: process, funcname: active_children
process.py(69): _cleanup()
--- modulename: process, funcname: _cleanup
process.py(78): for p in list(_current_process._children):
process.py(70): return list(_current_process._children)
util.py(323): for p in active_children():
--- modulename: process, funcname: active_children
process.py(69): _cleanup()
--- modulename: process, funcname: _cleanup
process.py(78): for p in list(_current_process._children):
process.py(70): return list(_current_process._children)
util.py(327): debug('running the remaining atexit finalizers')
--- modulename: util, funcname: debug
util.py(73): if _logger:
util.py(328): _run_finalizers()
--- modulename: util, funcname: _run_finalizers
util.py(257): if _finalizer_registry is None:
util.py(263): if minpriority is None:
util.py(264): f = lambda p : p[0][0] is not None
util.py(268): items = [x for x in _finalizer_registry.items() if f(x)]
util.py(269): items.sort(reverse=True)
util.py(271): for key, finalizer in items:
util.py(279): if minpriority is None:
util.py(280): _finalizer_registry.clear()
process.py(278): util.info('process exiting with exitcode %d' %
exitcode)
--- modulename: util, funcname: info
util.py(77): if _logger:
process.py(279): return exitcode
forking.py(127): sys.stdout.flush()
forking.py(128): sys.stderr.flush()
forking.py(129): os._exit(code)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/2014 6:07 PM, Mark H Harris wrote: On 4/4/14 4:50 PM, Mark Lawrence wrote: You could answer all of the above for yourself if you were to use your favourite search engine. hi Mark, yeah, condescending as that is, been there done that. Since there *are* people who use python-list as a substitute, it does not hurt to mention searches done, the result, along with what you still want to know. Its always better to get a straight answer from the core people than to rely on rumors and fork discussions found on google. I am a core developer and I am 99.99% sure that the core developers will not produce a CPython 2.8. For one thing we will likely do instead, see http://legacy.python.org/dev/peps/pep-0466/ -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 2:04 PM, Terry Reedy tjre...@udel.edu wrote: I am a core developer and I am 99.99% sure that the core developers will not produce a CPython 2.8. For one thing we will likely do instead, see http://legacy.python.org/dev/peps/pep-0466/ There's also been talk of a potential compiler change for the Windows builds, which otherwise only ever happens at minor releases. Is there a PEP to link people to about that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Saturday, April 5, 2014 2:28:29 AM UTC+5:30, Mark H. Harris wrote: hi Mark, yes that's my point. I have heard rumors of python2.8? At some point I would expect that the Cpython interpreter would 'freeze' and no one would fix it any longer. I have a serious question, namely, why does the Cpython community continue to suppport two interpreters rather than asking the Cpython user-base to migrate to Cpython3? Computer-hobbyists and computer-professionals are quite different sets of people. Are you aware That people FORTRAN, COBOL, mainframes are still in use? That people deep in those would not be amused if their systems suddenly stopped working? That some of the above people have not clue that the world around is not exactly in the same state they see it? And that YOU would not be amused if your credit card suddenly stopped working? (very likely running in some cloistered COBOL mainframe env). IOW: 1. Python is a fun language; its also a serious language 2. Python is not as old as FORTRAN and COBOL but at 20 years its not exactly young either 3. Its reached so far because core-devs behave responsibly towards different constituencies -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/2014 11:22 PM, Chris Angelico wrote: On Sat, Apr 5, 2014 at 2:04 PM, Terry Reedy tjre...@udel.edu wrote: I am a core developer and I am 99.99% sure that the core developers will not produce a CPython 2.8. For one thing we will likely do instead, see http://legacy.python.org/dev/peps/pep-0466/ There's also been talk of a potential compiler change for the Windows builds, which otherwise only ever happens at minor releases. Is there a PEP to link people to about that? Not that I know of. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 6:16 PM, Mark Lawrence wrote: Fear/panic of a fork, where did that come from? It's certainly the first I've ever heard of it. hi Mark, it came from Ian; or, my interpretation of Ian. It comes out on the net too (from various places). Here is Ian's quote, then my comment: Eventually users still on 2.x will need to upgrade, but you can't force them to do it on your own schedule. That path will just end up driving them to another language, or to a fork of 2.7. The sentiment behind this last quote is essentially fear (and that is natural). Its basically the tension between (I'm speaking as the royal we here) we don't want folks to be driven away from Cpython as a language, and we don't want them to fork the Cpython interpreter, so we'll take a very casual and methodically conservative approach to nudging people towards a Cpython3 migration route ( I am speaking not for the community, just hypothetically trying to get at the gist of Ian's quote); please forgive me if I didn't quite get it. I spent most of the afternoon reading this: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html This doc is long, thorough in detail, and mostly complete. Its a great read. The migration is not trivial, and it can't happen in one fell swoop, either. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 10:04 PM, Terry Reedy wrote: I am a core developer and I am 99.99% sure that the core developers will not produce a CPython 2.8. For one thing we will likely do instead, see http://legacy.python.org/dev/peps/pep-0466/ Thanks Terry. The back-port sounds great; I find the Rejected alternatives interesting. I think this must be where I was getting the gist that 2.8 might be an option--- just all the discussion that went on trying to figure out what to do with the security issues. I notice a good bit on unicode there too. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 7:00 PM, Steven D'Aprano wrote: Berp, Brython, CLPython, CPython, CapPython, ChinesePython, Compyler, Copperhead, Cython, HoPe, HotPy, IronPython, Jython, Kivy, Mypy, Mython, Nuitka, Numba, Parakeet, Parallel Python, Perthon, Pippy, Psyco, Py4A, PyMite, PyMT, PyPad, PyPy, PyQNX, PyVM, Pycorn, Pyjamas, Pynie, Pystachio, Pyston, Python for .NET, Python for OS/2, Python for S60, Python-iPod, Python2C, Pythonce, Pythonium Core, Pythran, QPython, RapydScript, Shedskin, Skulpt, Stackless, TinyPy, Typhon, UnPython, Unladen Swallow, Vyper, WPython Thanks for this list. As I said, some of these may be abandoned, obsolete, experimental, or even vapourware. Some are probably just ports of CPython to another platform rather than completely independent implementations. The only one I've used regularly is QPython (on Android) which is apparently a 2.7.2 port. Its relatively slow but 'useful' because its obviously highly mobile, which gives me the opportunity to code-on-the-go, or try a new idea in those awkward times when only a cell-phone is convenient for the venue. but I know that Jython and IronPython are serious contenders (although, I have not, nor probably will, use them). If you are using a Debian-based system, it is trivial to install them via apt-get or aptitude: sudo aptitude install jython ironpython Its has always seemed to me that Java or C++ would be better suited to creating python. I wonder will C always be the standard canonical PSF python interpreter base language? Has the C python community considered making the standard base language Java or C++ ? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 3:10 PM, Mark H Harris harrismh...@gmail.com wrote: we don't want folks to be driven away from Cpython as a language, and we don't want them to fork the Cpython interpreter, so we'll take a very casual and methodically conservative approach to nudging people towards a Cpython3 migration route If it's too much work to make the changes to move something from Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite it in a different language. There would have to be some strong other reason for shifting, especially since there's a 2to3 but not a PytoRuby. And forking is a pretty huge job; someone's gotta maintain it. What's more likely is that, once python.org stops maintaining Python 2.x at all, people will just stay on 2.7.9 or whatever the last version is, without any bugfixes. Companies like Red Hat will be looking at security patches (which is what PEP 466 is all about), but only to the extent that they have people willing to put in the work to make and test them. After that, it'll be like running old versions of anything else: you weigh the cost of migrating to the new version against the risk of exploits if you don't move. It's that simple. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 3:31 PM, Mark H Harris harrismh...@gmail.com wrote: Its has always seemed to me that Java or C++ would be better suited to creating python. I wonder will C always be the standard canonical PSF python interpreter base language? Has the C python community considered making the standard base language Java or C++ ? Java you know about (Jython); what's the advantage of C++ over C? A Python interpreter needs to do broadly this: 1) Parse a text file into an abstract syntax tree 2) Compile the AST into bytecode 3) Execute the bytecode: 3a) Manage object lifetimes and garbage collection 3b) Perform lower-level calls 3c) Efficiently handle namespaces etc Java has an advantage over C in that 3a can be done by the JVM. (At least, I believe that's how Jython does it; a Python object is backed by a Java object, and every Python object that references another Python object is backed by a corresponding reference to the corresponding Java object, so the JVM knows about all object lifetimes.) C++ doesn't have that, at least not normally (and I've never really liked most C++ garbage collectors - maybe there's a good one that I've not yet met), so all you'd really gain is 3b, in that you could conveniently pass jobs down to a lower-level C++ library. (Java also gains this advantage - or maybe disadvantage, as you can easily interface to other Java code but not so easily to C code.) Most programming languages make it easy to talk to C code, ergo most libraries are written for C interfaces, ergo most programming languages don't need C++. The only case I can think of is Google's V8 interpreter (ECMAScript), which uses C++ bindings to handle scoping; it's nice and easy as long as you embed V8 in a C++ program, and not so easy if you're going back and forth between the two languages; at that point, it basically reverts to a C-like interface, so there's no advantage. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 10:10 PM, Mark H Harris harrismh...@gmail.com wrote: On 4/4/14 6:16 PM, Mark Lawrence wrote: Fear/panic of a fork, where did that come from? It's certainly the first I've ever heard of it. hi Mark, it came from Ian; or, my interpretation of Ian. It comes out on the net too (from various places). Here is Ian's quote, then my comment: Eventually users still on 2.x will need to upgrade, but you can't force them to do it on your own schedule. That path will just end up driving them to another language, or to a fork of 2.7. The sentiment behind this last quote is essentially fear (and that is natural). Its basically the tension between (I'm speaking as the royal we here) we don't want folks to be driven away from Cpython as a language, and we don't want them to fork the Cpython interpreter, so we'll take a very casual and methodically conservative approach to nudging people towards a Cpython3 migration route ( I am speaking not for the community, just hypothetically trying to get at the gist of Ian's quote); please forgive me if I didn't quite get it. A fork is undesirable because it fragments the community. I don't think fear or panic are the right words for it. -- https://mail.python.org/mailman/listinfo/python-list
About threading.Thread
Hello guys:
I have an question on threading.Thread
My code is here:
File1:
a.py
import threading
import time
def hello():
while True:
print('hello')
threads = threading.enumerate()
for thread in threads:
print(thread.getName())
time.sleep(3)
def fun():
a = threading.Thread(target=hello(), name='hello')
print(a file: I won't display!)
a.start()
File2:
b.py
import time
from a import fun
fun()
print(b file: I won't display!)
When I run: python b.py (python version: 2.7.6, 3.3.5, 3.4.0)
It seems that threading.Thread() in file1 not create a new thread but use
MainThread.
Anyone can explain this ?
Thank you in advance.
Best regards.
peipei
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 10:42 PM, Rustom Mody wrote: Computer-hobbyists and computer-professionals are quite different sets of people. I know its just a gut feel, and I know there are a lot of lurkers here too, but it seems that there are *way* more folks from the professional camp on comp.lang.python than otherwise. Do you have a gut feel for the % of hobbyists vs. professionals participating here? Are you aware That [people?] FORTRAN, COBOL, mainframes are still in use? Well, the S390 is still in use (running gnu/linux these days) and the z series machines from IBM. FORTRAN and COBOL have government (military) niche. I remember during the Y2K problem COBOL coders were working their butts off. There is a 2014 standard doc replacing the 2002 standard, believe. The last time I used FORTRAN IV was in about 1977, on the System360-44, but GNU still supports it, and as far as I know it still has a wide user group (mostly academic). I have it on my system here, but I don't use it. 1. Python is a fun language; its also a serious language A very serious language; yes, its fun too. 2. Python is not as old as FORTRAN and COBOL but at 20 years its not exactly young either It won't have its day until it becomes ubiquitous... and its coming! As the gnu/linux numbers continue to climb, more everyday is C python becoming ubiquitous. I'm hoping the ubiquitous version is C python 3.4+ 3. Its reached far because core-devs behave responsibly towards different constituencies I think its because the language is flexible, extensible, powerful (batteries included), and is supported by a world-wide community of software engineers (both amateur and professional) who are committed to its development and adoption world-wide. The PEP process has had a lot to due with this (and not to ape the BDFL) it has had a lot to due with some Dutch genius.;-) However, knowing your user-base is certainly important. Its always a problem (any venue, any environment) to try to please everyone. Tough choices have to be made. The C python community does a pretty good job of this. Python-ideas and the PEP process are a unique and unparalleled strategy for enhancement. Very nice. Having said that, I do believe that the migration to C python3 has been too conservative. Nobody wants to maintain a fork, not really. I don't think its something anyone should be afraid of. Somebody should put a date on C python 3.4+ migration and cut off support for 2.7.x/ Its just an opinion. If 'Twisted' isn't ready for 3.x, well, they need to get ready. That's also just an opinion. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, Apr 4, 2014 at 10:40 PM, Chris Angelico ros...@gmail.com wrote: On Sat, Apr 5, 2014 at 3:10 PM, Mark H Harris harrismh...@gmail.com wrote: we don't want folks to be driven away from Cpython as a language, and we don't want them to fork the Cpython interpreter, so we'll take a very casual and methodically conservative approach to nudging people towards a Cpython3 migration route If it's too much work to make the changes to move something from Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite it in a different language. There would have to be some strong other reason for shifting, especially since there's a 2to3 but not a PytoRuby. For whatever the current project is, yes -- if there's no route to Python 3 then they will simply be stuck on Python 2.7 indefinitely. However, if Python is perceived as a language that doesn't provide backward compatibility and long-term maintainability via some migration path, then users will be less likely to pick Python for their *next* project. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 11:40 PM, Chris Angelico wrote:
If it's too much work to make the changes to move something from
Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite
it in a different language.
Totally, no doubt.
There would have to be some strong other
reason for shifting, especially since there's a 2to3 but not a
PytoRuby. And forking is a pretty huge job; someone's gotta maintain
it.
I agree there, too. That's why I don't think anyone should worry
about a new program, nor about a fork. Nobody really wants to fork a
programming language, esp one like python. It takes an entire team of
dedicated people to support it--- jut not worth trying to do that.
What's more likely is that, once python.org stops maintaining
Python 2.x at all, people will just stay on 2.7.9 or {snip}
After that, it'll be like running old versions of
anything else: you weigh the cost of migrating to the new version
against the risk of exploits if you don't move. It's that simple.
Yup, totally agree. So, just do it. Probably after 3.4 will be the
right time. Beats me.
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: About threading.Thread
On Sat, Apr 5, 2014 at 4:02 PM, 张佩佩 zhangpeipei...@outlook.com wrote: def fun(): a = threading.Thread(target=hello(), name='hello') It seems that threading.Thread() in file1 not create a new thread but use MainThread. Anyone can explain this ? Thank you in advance. Suggestion: Cut the code down until you find the exact bit that's showing a problem. You don't need two files for this; in fact, all you need is your definition of hello, the call to threading.Thread(), and a print statement after it, which you'll see doesn't happen. The problem here is that you're already *calling* hello() in the argument list. Before threading.Thread() gets called, its arguments get fully evaluated... which calls hello(), which infinitely loops. That's why it's getting called on the main thread. To spin off a thread that will call hello(), take the parentheses off: a = threading.Thread(target=hello, name='hello') That'll pass a function, rather than the return value of that function, and then Thread can call that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 4:02 PM, Mark H Harris harrismh...@gmail.com wrote: I know its just a gut feel, and I know there are a lot of lurkers here too, but it seems that there are *way* more folks from the professional camp on comp.lang.python than otherwise. Do you have a gut feel for the % of hobbyists vs. professionals participating here? Impossible to say. However, I would suggest that the more prolific posters are going to be those who use Python more (and thus it's worth investing more time in), which is going to skew the post stats towards the professional end of the spectrum. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 11:49 PM, Chris Angelico wrote: On Sat, Apr 5, 2014 at 3:31 PM, Mark H Harris harrismh...@gmail.com wrote: Its has always seemed to me that Java or C++ would be better suited to creating python. I wonder will C always be the standard canonical PSF python interpreter base language? Has the C python community considered making the standard base language Java or C++ ? what's the advantage of C++ over C? A Python interpreter needs to do broadly this: 1) Parse a text file into an abstract syntax tree 2) Compile the AST into bytecode 3) Execute the bytecode: 3a) Manage object lifetimes and garbage collection 3b) Perform lower-level calls 3c) Efficiently handle namespaces etc The only advantage of C++ over C is polymorphism, really. There are in my view only three reasons to even use C++: 1) the iostream library, and 2) polymorphism, and 3) operator overloading. If you need to do all three, then C++ is a really good candidate. I am still thinking about the concept of unifying Number; Number as a C++ abstract base class, and an entire Class hierarchy which carries through making *any* Number just work. The ability of the C++ compiler to construct and maintain the virtual function tables would be an advantage. Operator overloading (and maybe templates) would make C++ advantageous also. Guido told me that the modern C python is object oriented. Operator overloading is a big part of this. It seems to me that a modern object oriented language would best be implemented with a true object oriented base language, C++ rather than C. I have always questioned this, just curious why the decision for C was made--- historically, methodologically, and maybe scientifically. It would be tons of work, but maybe not as much as one might think, initially. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
Chris Angelico ros...@gmail.com writes: I would suggest that the more prolific posters are going to be those who use Python more (and thus it's worth investing more time in), which is going to skew the post stats towards the professional end of the spectrum. It's also plausible that the more prolific posters are those who spend *less* time actually coding, and instead spend their free time being prolific in this forum. Other explanations are plausible. Any of them could be contributing factors in any mixture. Without actual data – which neither of us has on this matter – all of these hypotheses are unfounded speculation. Let's not draw any conclusions in the absence of evidence. -- \ “I went to the cinema, it said ‘Adults: $5.00, Children $2.50’. | `\ So I said ‘Give me two boys and a girl.’” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/5/14 12:02 AM, Ian Kelly wrote: A fork is undesirable because it fragments the community. I don't think fear or panic are the right words for it. Yes. I get that. I think what is desired (just thinking out loud from my own vantage point) is a unified community, but also a foundation of perceived permanence. The PSF establishes this to a certain extend, as well the PEP process, and to some extent the communities willingness to support two interpreters. It looks like C python is here to stay; I can count on it for my projects years into the future. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Apr 5, 2014 at 4:23 PM, Mark H Harris harrismh...@gmail.com wrote: The only advantage of C++ over C is polymorphism, really. There are in my view only three reasons to even use C++: 1) the iostream library, and 2) polymorphism, and 3) operator overloading. If you need to do all three, then C++ is a really good candidate. The iostream library actually gives you very little over the stdio functions (printf, FILE*, etc), beyond that they're arguably easier to use. (I say arguably because there've been plenty of times when I've been writing C++ code and just not bothered with cout, finding printf the better option. Sometimes you find yourself arguing with cout and it's not worth arguing with.) Operator overloading, ultimately, is just this: x + y // becomes x.operator+(y) // or operator+(x,y) When you're actually writing C++ code, that's a huge advantage in readability. But if you're writing an interpreter for another language, there's no benefit; you may as well not bother. Maybe it'd be of value if you want to write a Python-to-C++ translator that then lets you compile the resulting C++ code, but only if you want the C++ code to be readable. So all you're left with is polymorphism. Well, big problem: Python and C++ have distinctly different semantics for multiple inheritance. It wouldn't be possible, much less practical, to try to implement Python's MRO on top of a C++ class structure, other than by basically ignoring the whole structure and using it much the same way PyObject * is used in the existing C code. I am still thinking about the concept of unifying Number; Number as a C++ abstract base class, and an entire Class hierarchy which carries through making *any* Number just work. The ability of the C++ compiler to construct and maintain the virtual function tables would be an advantage. Operator overloading (and maybe templates) would make C++ advantageous also. The virtual function tables don't cater for the MRO, see above. But even with simple single inheritance, the effort of creating a new class at run-time would be quite a problem; remember, 'class' in C++ is a declaration to the compiler, but 'class' in Python is an executable statement. Guido told me that the modern C python is object oriented. Operator overloading is a big part of this. It seems to me that a modern object oriented language would best be implemented with a true object oriented base language, C++ rather than C. I have always questioned this, just curious why the decision for C was made--- historically, methodologically, and maybe scientifically. Python is object oriented, and it has operator overloading. But it's possible to implement operator overloading in a language that doesn't have it - it's not OOPs all the way down, turtle-style - so somewhere there has to be that boundary, and building one object oriented language on top of another doesn't necessarily actually give many benefits. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Raymond Hettinger added the comment: Thanks Mark, that is an excellent suggestion. -- Added file: http://bugs.python.org/file34719/fraction_pow2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF
Christian Clauss added the comment: Makefile and make.bat in https://github.com/python/pythondotorg/blob/master/docs are NOT the correct files to modify. It is unclear to where the correct files are. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20969 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
Médéric Boquien added the comment: Thanks for the explanations Charles-François. I guess the new API would not be before 3.5 at least. Is there still a chance to integrate my patch (or any other) to improve the situation for the 3.4 series though? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
Andreas Schwab added the comment: Finn Thain fth...@telegraphics.com.au writes: until Aranym gets fixed. Aranym *is* fixed. Andreas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
Josiah Carlson added the comment: Quick update before I head to bed. Thank you for the input, I had gotten the individual async calls working a couple days ago, and I was just working to replace the communicate() method for Windows. Yes, I'm using asyncio._overlapped, though asyncio uses subprocessing, so I needed to defer import of _overlapped until one of a couple crucial methods were being called in order to prevent issues relating to circular imports. I also ended up moving asyncio.windows_utils.pipe out to subprocess, as copying/pasting it for a third 'create an overlapped-io pipe' implementation for the standard library just doesn't make a lot of sense, and another circular import seemed like a bad idea. If/when subprocess goes away completely, someone else can move the function back. With overlapped IOs able to be cancelled, it's not all that bad to make a completely re-entrant communicate() without threads, though I made a few mistakes in my first pass tonight that I need to fix tomorrow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Changes by Berker Peksag berker.pek...@gmail.com: -- resolution: - fixed stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20375 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19491] Python Crashing When Saving Documents
Terry J. Reedy added the comment: I am closing this on the theory that the problem has been fixed by one of the many crash fixers since 3.2. There is certainly insufficient information to act on. Currently, a problem would have to be demonstrated with 3.4 (or possible 2.7). -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19491 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Andreas Schwab dixit: Finn Thain fth...@telegraphics.com.au writes: Sorry, what? You seek to veto an upstream Python bug fix because it will lead to correct binaries that a certain emulator can't handle? That Yes, because of the value ARAnyM has for Linux/m68k development and especially testing – for example, considering that there are no porterboxen, we can, currently, just tell people needing one to install a VM themselves, and even provide images from which to start. Furthermore, Andreas' bug fix was to be merged for python 3.5. Debian is not obliged to use that version with that patch up until Aranym gets Debian is consistent across architectures. (Well, mostly.) This patch changes a known-good but less optimal behaviour (using the old dtoa routines) by behaviour that matches the other architectures even better but only iff the FPU (FPU emulation) supports changing precision. Which it didn’t last time I looked. fixed. Aranym *is* fixed. What *precise* version of ARAnyM is the first to have been released with a fix for this issue? I never got any response to my message to upstream in which I asked for a release: pine.bsm.4.64l.1403211905340.7...@herc.mirbsd.org (No response *at all*, mind you. Not even an ACK or “no”.) Once we do have a fixed version, we can communicate that around. (Note that “have” includes having e.g. backports to stable and several old *buntu versions at least.) bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21152] Idle: timed autosave for shell (and maybe editor) window
New submission from Terry J. Reedy: From #21140, msg215485, Raymond Hettinger: Students commonly save shell sessions as a record of everything they tried in call. It would nice if there were a way to trigger a periodic autosave (perhaps every five minutes or so). -- components: IDLE messages: 215499 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: timed autosave for shell (and maybe editor) window type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21152 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21140] Idle: saving an OutputWindow should default to .txt
Terry J. Reedy added the comment: Raymond, I open #21152 with your idea. #11838 and #19042 are somewhat related but timed autosave is not a part of either. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21140 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
Andreas Schwab added the comment: The fixed version is here: git://git.code.sf.net/p/aranym/code Andreas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
mattip added the comment: Correct, the other patches were against pypy, sorry. I now patched and tested against banch 2.7 on the python tree. -- Added file: http://bugs.python.org/file34720/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
Stefan Krah added the comment: If the asm instructions silently fail, I'd say add a test to ./configure that detects the broken versions of the emulator in question. Or don't bother and tell people to use the proper version of the emulator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF
Antoine Pitrou added the comment: The PSF is not the author of the docs. Perhaps something like Python documentation authors. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20969 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
Andreas Schwab added the comment: There is nothing that fails. The emulator has always correctly implemented the insn. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
Serhiy Storchaka added the comment: I'm wondering why resource warnings are not raised in CPython? ./python -Werror -bb -m test.regrtest -uall test_argparse test_file test_httpservers -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown
Roundup Robot added the comment: New changeset b6deab7204e6 by Vinay Sajip in branch '2.7': Issue #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/b6deab7204e6 New changeset b5c91b61991a by Vinay Sajip in branch '3.4': Issue #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/b5c91b61991a New changeset 76689a706900 by Vinay Sajip in branch 'default': Closes #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/76689a706900 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21149 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21153] bdist_rpm fails if project contains files with spaces in the names
New submission from Jason R. Coombs: In https://bitbucket.org/pypa/setuptools/issue/178, Eduard reported an issue that setuptools fails to install due to files in its structure with spaces in the filenames. These files have been around for some time (over two years in Distribute), but are now revealing a limitation in bdist_rpm. The aforementioned ticket demonstrates the issue, and I will be providing a script to replicate the failure shortly. -- components: Distutils messages: 215508 nosy: dstufft, eric.araujo, jason.coombs priority: normal severity: normal status: open title: bdist_rpm fails if project contains files with spaces in the names versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21153] bdist_rpm fails if project contains files with spaces in the names
Jason R. Coombs added the comment: The attached script (issue21153.py) replicates the failure in a Unix environment with the 'rpm' command present. -- Added file: http://bugs.python.org/file34721/issue21153.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
Thomas Heller added the comment: My usecase is: I create kind of bound methods with functools.partial. Apologies for the confusion by using the word 'equivalent'; what I mean is that partial instances should (IMO) compare equal when they contain the same function and args/keywords which compare equal. I guess functools.partialmethod has the same problem and I would suggest the same fix/enhancement but I have not used them yet because I have to write python2/3 compatible code. Anyway; if this behaviour is not seen as a bug then it is probably python-ideas material, but I'm too tired to start a discussion there atm. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17522] Add api PyGILState_Check
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17522 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16475] Support object instancing and recursion in marshal
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Kristján Valur Jónsson added the comment: Closing this as won-t fix. Exiting with running threads is a can of worms. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8410] Fix emulated lock to be 'fair'
Kristján Valur Jónsson added the comment: Closing this issue. It is largely superseded. For our Python 2.7 branches, we have a custom GIL lock which can have different inherent semantics from the common Lock. In particular, we can implement a fair PyGIL_Handoff() function to be used to yield the GIL to a waiting thread. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8410] Fix emulated lock to be 'fair'
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- resolution: - rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- resolution: - wont fix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
