Re: Confessions of a Python fanboy
On Monday 11 May 2015 11:46, zipher wrote: By having methods like len() in your built-in namespace when it's really only relevant to objects that are types of containers, you blur one primary component of OOP: encapsulation. Gosh, one would almost think that Python's concept of OOP wasn't pure enough for you. You should talk to that other guy who says that Python is too pure, his name is Mark Rosenblitt-Janssen. I'm sure you two would have a lot to talk about. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
On 11/05/2015 07:15, Steven D'Aprano wrote: On Monday 11 May 2015 11:46, zipher wrote: By having methods like len() in your built-in namespace when it's really only relevant to objects that are types of containers, you blur one primary component of OOP: encapsulation. Gosh, one would almost think that Python's concept of OOP wasn't pure enough for you. You should talk to that other guy who says that Python is too pure, his name is Mark Rosenblitt-Janssen. I'm sure you two would have a lot to talk about. Ah, the penny has finally dropped. I recall years ago somebody pointing out his website. It had clearly been put together after the narcotics from several bulk carriers had been consumed. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 2:58:09 AM UTC+2, zipher wrote: I guess everyone expects this behavior since Python implemented this idea of everything is an object, but I think this branch of OOP (on the branch of the Tree of Programming Languages) has to be chopped off. The idea of everything is an object is backwards (unless your in a LISP machine). Like I say, it's trying to be too pure and not practical. Expressing this sort of emphatic, insulting and superficial opinions, to the people who would be most irritated by them (the Python mailing list) and without the slightest interest for contrary viewpoints and constructive discussion, is a very unpleasant form of trolling. If you don't like Python, you are welcome to prefer other programming languages. If you want to use Python with C-like primitive types, you can use arrays. Both choices are perfectly good, and routinely made without bothering other people with inane conversations. Lorenzo Gatti -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Mon, May 11, 2015 at 5:12 AM, boB Stepp robertvst...@gmail.com wrote: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? I'm surprised that this thought has not been added to the Zen Of Python, as I see it as more and more recurrent as I continue my studies. What I would like to comprehend is what is the essential mindset of Python? That is, what do I need to understand, so that I am no longer likely to be surprised by discovering new possibilities in Python such as what the current thread is discussing? The Zen of Python is a static document, a historical artifact of a sort. But in terms of understanding the philosophy of Python, we're all adults here is a big part of it. Once you grok the notion that nothing can be prevented, you're freed from such considerations as: * Obfuscating, encrypting, or otherwise hiding your source code * Private members with restricted access * Strict type checking, to prevent someone passing in a wrong piece of data * Prevention of monkey-patching etc, etc, etc. In actual fact, anyone can bypass any restriction, in any language; and Python is just more open/honest about it than languages like C++; for instance, instead of having true private members where the compiler stops you from looking at or changing them, Python gives you single-underscore-named attributes, where nobody stops you from doing anything, but there's a general understanding that they're not governed by the usual compatibility rules, so upgrading a library might break your code. Happy with that? Go ahead then, use the internals. Hakuna matata, what a wonderful phrase. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling a function is faster than not calling it?
Steven D'Aprano schrieb am 10.05.2015 um 11:58: Why is calling a function faster than bypassing the function object and evaluating the code object itself? And not by a little, but by a lot? Here I have a file, eval_test.py: # === cut === from timeit import Timer def func(): a = 2 b = 3 c = 4 return (a+b)*(a-b)/(a*c + b*c) code = func.__code__ assert func() == eval(code) t1 = Timer(eval; func(), setup=from __main__ import func) t2 = Timer(eval(code), setup=from __main__ import code) # Best of 10 trials. print (min(t1.repeat(repeat=10))) print (min(t2.repeat(repeat=10))) # === cut === Note that both tests include a name lookup for eval, so that as much as possible I am comparing the two pieces of code on an equal footing. Here are the results I get: [steve@ando ~]$ python2.7 eval_test.py 0.804041147232 1.74012994766 [steve@ando ~]$ python3.3 eval_test.py 0.7233301624655724 1.7154695875942707 Directly eval'ing the code object is easily more than twice as expensive than calling the function, but calling the function has to eval the code object. Well, yes, but it does so directly in C code. What you are essentially doing here is replacing a part of the fast C code path for executing a Python function by some mostly equivalent but more general Python code. So, you're basically replacing a function call by another function call to eval(), plus some extra generic setup overhead. Python functions know exactly what they have to do internally in order to execute. eval() cannot make the same streamlined assumptions. Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday 11 May 2015 10:57, zipher wrote: I guess everyone expects this behavior since Python implemented this idea of everything is an object, but I think this branch of OOP (on the branch of the Tree of Programming Languages) has to be chopped off. The idea of everything is an object is backwards (unless your in a LISP machine). Like I say, it's trying to be too pure and not practical. Python is in production use in hundreds of thousands of organisations. It has been heavily used for over twenty years, in everything from quick and dirty one line scripts to hundred-thousand LOC applications. As well as the obvious OOP features, it includes features and idioms from imperative, procedural, functional and pipe-lining programming languages, with explicit influence from Pascal, C, Haskell, Dylan and Lisp, among others. Yeah, too pure and not practical. You're a funny guy. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday 11 May 2015 10:14, Mark Rosenblitt-Janssen wrote:
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
class str(int): pass
str('2')
2 #- an integer!!!
Thank the gods that you're around to point this out to us, because we never
would have extrapolated from the fact that int can be rebound to discover
that the same applies to str!
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
[issue24068] statistics module - incorrect results with boolean input
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20014] Makes array.array constructor accepts ascii-unicode typecode
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Array objects pickled in 3.x with protocol =2 are unpickled incorrectly in 2.x
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Delivery Status Notification (Failure)
On 9 May 2015 at 13:56, Chris Angelico ros...@gmail.com wrote: Yeah, I know, shocking. But I wanted to at least *try* doing the normal and official thing, in the hopes that they were a legit company that perhaps didn't realize what this looked like. By all means report to abuse@ in the future, but please do not CC the list. My spam filters have learned to filter out most job spam automatically by now, but it doesn't filter out your reply. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
I am in process learning Python and normally hang out on the Tutor list, but monitor this one hoping to learn what I can. This thread is of interest to me from the standpoint of trying to understand the Python way of doing things. On Sun, May 10, 2015 at 12:28 PM, Gary Herron gher...@digipen.edu wrote: On 05/10/2015 09:48 AM, Rustom Mody wrote: On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote: On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote: Here's something that might be wrong in Python (tried on v2.7): class int(str): pass This defines a new class named int that is a subclass of str. It has no relation to the builtin class int. int(3) '3' This creates an instance of the above int class, which is basically equivalent to calling str(3). Were you expecting a different result? In C (family) languages int is a keyword From that pov this is completely bizarre Not really. Expecting Python to act like C family languages *is* bizarre. I have to admit being surprised by this, too. I am just now studying on how to write my own classes in Python, and have come to realize that doing this is *possible*, but the *surprise* to me is why the language design allowed this to actually be done. Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? I'm surprised that this thought has not been added to the Zen Of Python, as I see it as more and more recurrent as I continue my studies. What I would like to comprehend is what is the essential mindset of Python? That is, what do I need to understand, so that I am no longer likely to be surprised by discovering new possibilities in Python such as what the current thread is discussing? -- boB -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On 10/05/2015 20:12, boB Stepp wrote: On Sun, May 10, 2015 at 12:28 PM, Gary Herron gher...@digipen.edu wrote: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? I'm surprised that this thought has not been added to the Zen Of Python, as I see it as more and more recurrent as I continue my studies. What I would like to comprehend is what is the essential mindset of Python? That is, what do I need to understand, so that I am no longer likely to be surprised by discovering new possibilities in Python such as what the current thread is discussing? You need to understand that Python is so powerful that after 14 years I still can't wrap my mind around all of the possibilities that it offers. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is array.array('u') deprecated?
On 08/05/2015 15:40, jonathan.slend...@gmail.com wrote: Le vendredi 8 mai 2015 15:11:56 UTC+2, Peter Otten a écrit : So, this works perfectly fine and fast. But it scares me that it's deprecated and Python 4 will not support it anymore. Hm, this doesn't even work with Python 3: My mistake. I should have tested better. data = array.array(u, ux*1000) data[100] = y re.search(y, data) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.4/re.py, line 166, in search return _compile(pattern, flags).search(string) TypeError: can't use a string pattern on a bytes-like object You can search for bytes re.search(by, data) _sre.SRE_Match object; span=(400, 401), match=b'y' data[101] = z re.search(by, data) _sre.SRE_Match object; span=(400, 401), match=b'y' re.search(byz, data) re.search(by\0\0\0z, data) _sre.SRE_Match object; span=(400, 405), match=b'y\x00\x00\x00z' but if that is good enough you can use a bytearray in the first place. Maybe I'll try that. Thanks for the suggestions! Jonathan http://sourceforge.net/projects/pyropes/ of any use to you? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue24134] assertRaises can behave differently
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file39340/assert_raises_args_deprecation.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Larry Hastings added the comment: I'd rather have the general-purpose freelist for ints too. How about we close this issue now, and assuming the freelist for ints goes in we can abandon this approach entirely. -- resolution: - rejected stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: According to my and Larry's measurements [1] the distribution of created int's by size during running Python tests is: On 32-bit Linux: int 42828741 13.40% 0 425353 0.99% 0.99% 1 21399290 49.96% 50.96% 2 10496856 24.51% 75.47% 34873346 11.38% 86.85% 41021563 2.39% 89.23% 51246444 2.91% 92.14% 6 733676 1.71% 93.85% 7 123074 0.29% 94.14% 8 139203 0.33% 94.47% ... On 64-bit Linux: int 47600237 13.53% 0 294964 0.62% 0.62% 1 36135772 75.92% 76.53% 24504046 9.46% 86.00% 32109837 4.43% 90.43% 41277995 2.68% 93.11% 5 542775 1.14% 94.25% 6 485451 1.02% 95.27% ... 86% of ints have size = 3 on 32-bit and = 2 on 64-bit. This is enough to represent 32-bit integers (as in Python 2 int). I think we should support free list not only for 1-digit ints, but at least up to 3 digit on 32-bit build and up to 2 digits on 64-bit build. Other natural limit is 3 digit on 64-bit build (enough to represent 64-bit C long on Linux or pointer on all platforms). Larger integers perhaps are encountered mainly in tests. Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Antoine Pitrou added the comment: I'd rather stick to the simple freelist approach. People interested in (allegedly) more ambitious designs can open new issues, together with patches to evaluate their efficiency. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
Op 10-05-15 om 19:28 schreef Gary Herron: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? Besides, it's still available as __builtins__.int (unless you've also overridden that). This is a common python myth. That is selectively used when convenient and ignored when that is convenient. Try overriding None, True or False in python3 and see what happens. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
[issue24164] Support pickling objects with __new__ with keyword arguments with protocol 2+
New submission from Serhiy Storchaka: Pickling of objects of classes whose __new__ mandates the use of keyword-only arguments is supported with protocol 4 (using a new opcode NEWOBJ_EX). But it is possible to implement this feature with protocol 2+ (less efficiently than with NEWOBJ_EX). __new_ex__ is pickled as partial(cls.__new__, cls, *args, **kwargs). Pickled data is compatible with older Python releases up to 2.7 (issue5228). Proposed patch adds support of __new__ with keyword arguments with protocols 2 and 3. -- components: Extension Modules, Interpreter Core, Library (Lib) files: pickle_new_ex_protocol_2.patch keywords: patch messages: 242890 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Support pickling objects with __new__ with keyword arguments with protocol 2+ type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39341/pickle_new_ex_protocol_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24164 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Calling a function is faster than not calling it?
On 11/05/2015 04:58, Steven D'Aprano wrote:
On Mon, 11 May 2015 07:08 am, BartC wrote:
On 10/05/2015 10:58, Steven D'Aprano wrote:
def func():
a = 2
b = 3
c = 4
return (a+b)*(a-b)/(a*c + b*c)
print (min(t1.repeat(repeat=10)))
print (min(t2.repeat(repeat=10)))
Maybe the overheads of using eval() are significant when calling a
simple function such as your example.
When I made it do a bit more work:
[...]
Then the eval() call took only 3% longer rather than 100%.
Well duh :-)
If I use:
def func():
time.sleep(365*24*60*60) # Sleep for a year.
then the overhead of calling it will be immeasurably small, regardless of
how we call it. But I don't care about big expensive functions. I actually
care about the fastest way to execute a tiny piece of code, and for that,
the overhead of eval is significant.
Your subject line is misleading. You're not comparing calling a function
with not calling it. You're comparing different ways of calling it (if
'calling' means somehow passing control to the body of the function,
then eventually getting back to where you were).
You just seem surprised that using eval() to do this is slower than a
direct call. I, knowing nothing about eval (I thought it liked string
arguments), except that it can be used to execute the body of a
function, am not that surprised.
But regardless of whether the overhead is 3% or 30%, there is an anomaly
here. Conceptually at least, calling a function does more work than
eval'ing the function's code object: the function evaluates the code
object, plus it has overhead of its own which eval'ing the code object
lacks.
Here is one possible, minimal, pseudo-code implementation of function
__call__:
def __call__(self, *args):
ns = {}
for i, parameter in enumerate(self.parameters):
ns[parameter] = args[i]
return eval(self.__code__, globals(), ns)
If I extract the call to eval, and run that alone, without needing to set up
function arguments, I should avoid the overhead of the __call__ method. We
should expect that:
Perhaps you're making assumptions about how a normal call is
implemented. Maybe it's not just implemented on top of eval(). (And it's
unlikely to use an actual call to __call__, because how would /that/
call be implemented; into another call to a nested __call__, etc?)
(I've no idea how Python actually does it, but performing a quick test
in another (also interpreted) language, calling an empty function func()
via a function pointer takes twice as long as calling it directly.
Because it has to do a bit more work.
In that case, because there are two bytecodes to be executed for the
call, not one, and it needs to check the number of arguments because it
can't be done when the bytecode is generated.)
The
anomaly is that, according to my tests, and confirmed by others, this is
not the case. However function __call__ works, it doesn't use eval. So what
does it do?
Is eval() called like a normal function? Then maybe you're forgetting
the overhead of calling a function. Whatever is saved on calling func(),
is expended on calling eval(). And eval() has overheads of its own
because it can't just immediately execute the code like func() can, it
has to get to that point first. And the 'return' in the code that is
being executed, can't (I think) return directly to your program, but has
to first return to eval(), which then does its own return.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
[issue1602] windows console doesn't print or input Unicode
Nick Coghlan added the comment: It sounds like fixing this properly requires fixing issue 17620 first (so the interactive interpreter actually uses sys.stdin), so I've flagged that as a dependency. -- dependencies: +Python interactive console doesn't use sys.stdin for input ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Marc-Andre Lemburg added the comment: I like the idea of adding a free list of longs in Python 3, but I think we should extend this somewhat to cover more ground, e.g. by pre-allocating a block of 1 digit long objects, like we did for Python 2 ints, and perhaps allocate up to 4k (= 1 memory page) towards such a free list. The added cache locality of having the data in a pre-allocated block should provide some more performance. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: [1] http://comments.gmane.org/gmane.comp.python.devel/153078 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Python-Dev] anomaly
On 10 May 2015 at 17:34, Mark Rosenblitt-Janssen dreamingforw...@gmail.com wrote: Here's something that might be wrong in Python (tried on v2.7): class int(str): pass int(3) '3' It's not wrong as such. It is allowed to define your own class that subclasses a builtin class, and it's allowed to shadow builtin names. So while this is (obviously) bad practice, it's not wrong. For a simpler example: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. str class 'str' str = Hello str 'Hello' Paul -- https://mail.python.org/mailman/listinfo/python-list
[issue1602] windows console doesn't print or input Unicode
Changes by Paul Moore p.f.mo...@gmail.com: -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On 11/05/2015 11:15, Antoon Pardon wrote: Op 10-05-15 om 19:28 schreef Gary Herron: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? Besides, it's still available as __builtins__.int (unless you've also overridden that). This is a common python myth. That is selectively used when convenient and ignored when that is convenient. Try overriding None, True or False in python3 and see what happens. According to https://docs.python.org/3/reference/lexical_analysis.html#keywords None, True and False are all keywords in Python 3, int isn't as I believe has already been pointed out. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue24138] Speed up range() by caching and modifying long objects
Marc-Andre Lemburg added the comment: On 11.05.2015 11:42, Serhiy Storchaka wrote: Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. True, but if it's only 1-4k RAM, I don't think anyone would mind :-) Python 2 is doing exactly that with 1k RAM for the integer free list. I think it was one of the first free lists ever added to Python, so done in a time when RAM was expensive ;-). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Feature Request: Reposition Execution
On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Antoon Pardon antoon.par...@rece.vub.ac.be: Which is exactly the point! They were turned into keywords because the developers didn't want to allow them being overridden. There is no a priori reason why we should turn True into a keyword and allow int in the builtins. We are only allowed to be adults, for as far as the developers let us. They allow us to be adults with regards to int but they don't allow us to be adults with regards to True. Defending int being overridable by declating We're all adults is being selective. I'm still failing to see the point. What problem are you having a difficulty solving? Marko -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix PyRun - One file Python Runtime 2.1.0
ANNOUNCING eGenix PyRun - One file Python Runtime Version 2.1.0 An easy-to-use single file relocatable Python run-time - available for Linux, Mac OS X and Unix platforms, with support for Python 2.6, 2.7 and **also for Python 3.4**. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-PyRun-2.1.0-GA.html INTRODUCTION eGenix PyRun is our open source, one file, no installation version of Python, making the distribution of a Python interpreter to run based scripts and applications to Unix based systems as simple as copying a single file. eGenix PyRun's executable only needs 11MB for Python 2 and 13MB for Python 3, but still supports most Python application and scripts - and it can be compressed to just 3-4MB using upx, if needed. Compared to a regular Python installation of typically 100MB on disk, eGenix PyRun is ideal for applications and scripts that need to be distributed to several target machines, client installations or customers. It makes installing Python on a Unix based system as simple as copying a single file. eGenix has been using eGenix PyRun internally in the mxODBC Connect Server product since 2008 with great success and decided to make it available as a stand-alone open-source product. We provide both the source archive to build your own eGenix PyRun, as well as pre-compiled binaries for Linux, FreeBSD and Mac OS X, as 32- and 64-bit versions. The binaries can be downloaded manually, or you can let our automatic install script install-pyrun take care of the installation: ./install-pyrun dir and you're done. Please see the product page for more details: http://www.egenix.com/products/python/PyRun/ NEWS This major new release of eGenix PyRun 2.1 comes with the following new features and changes: New Features * Upgraded eGenix PyRun to work with and use Python 2.7.9 per default. * Upgraded eGenix PyRun to work with and use Python 3.4.3 for Python 3 support. * Added support for setting rpath on the PyRun binary to make it easy to ship external libraries together with PyRun, without having to set the LD_LIBRARY_PATH variable. * Added special support for egenix-pyopenssl to load its OpenSSL libs during startup. * PyRun allows to disable the new default HTTPS certificate verification (PEP 476) by setting the env var PYRUN_HTTPSVERIFY to 0. Default is to apply certificate verification. * Add support for more Python command line options: -s and -3 are ignored, -R raises an error explaining to use the PYTHONHASHSEED env var instead, -B prevents writing of byte code files.This should increase compatibility of PyRun with the standard Python command line interface. Enhancements / Changes -- * Added patch for Python 2.7.9 and 3.4.3 to make ctypes work again after changes to those versions of Python. See https://bugs.python.org/issue23042 for details. * The PyRun -v command line switch will now be passed to Python and supports setting the level using e.g. -vv for a verbose 2 level. * Disabled user site configurations in PyRun, since these are not needed or wanted for typical PyRun uses and cost startup time. * Optimized sys.path setup a bit. PyRun won't check for a Python build run and will not check lib/site-python on startup anymore. * PyRun for Python 3.4 is no longer compiled to always run in optimized mode. This allows using asserts in tests again. Fixes - * Entering license in the interactive shell now returns the correct URL for all supported Python versions. * Tilde expansion now works for most arguments of install-pyrun. This wasn't working before due to a bug. install-pyrun Quick Install Enhancements - eGenix PyRun includes a shell script called install-pyrun, which greatly simplifies installation of PyRun. It works much like the virtualenv shell script used for creating new virtual environments (except that there's nothing virtual about PyRun environments). https://downloads.egenix.com/python/install-pyrun With the script, an eGenix PyRun installation is as simple as running: ./install-pyrun targetdir This will automatically detect the platform, download and install the right pyrun version into targetdir. We have updated this script since the last release: * Updated install-pyrun to default to eGenix PyRun 2.1.0 and its feature set. * Added -r/--requirements option which allows automatically installing a set of required packages using a requirements file, so you can easily set up a complete Python
ANN: eGenix PyRun - One file Python Runtime 2.1.0
ANNOUNCING eGenix PyRun - One file Python Runtime Version 2.1.0 An easy-to-use single file relocatable Python run-time - available for Linux, Mac OS X and Unix platforms, with support for Python 2.6, 2.7 and **also for Python 3.4**. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-PyRun-2.1.0-GA.html INTRODUCTION eGenix PyRun is our open source, one file, no installation version of Python, making the distribution of a Python interpreter to run based scripts and applications to Unix based systems as simple as copying a single file. eGenix PyRun's executable only needs 11MB for Python 2 and 13MB for Python 3, but still supports most Python application and scripts - and it can be compressed to just 3-4MB using upx, if needed. Compared to a regular Python installation of typically 100MB on disk, eGenix PyRun is ideal for applications and scripts that need to be distributed to several target machines, client installations or customers. It makes installing Python on a Unix based system as simple as copying a single file. eGenix has been using eGenix PyRun internally in the mxODBC Connect Server product since 2008 with great success and decided to make it available as a stand-alone open-source product. We provide both the source archive to build your own eGenix PyRun, as well as pre-compiled binaries for Linux, FreeBSD and Mac OS X, as 32- and 64-bit versions. The binaries can be downloaded manually, or you can let our automatic install script install-pyrun take care of the installation: ./install-pyrun dir and you're done. Please see the product page for more details: http://www.egenix.com/products/python/PyRun/ NEWS This major new release of eGenix PyRun 2.1 comes with the following new features and changes: New Features * Upgraded eGenix PyRun to work with and use Python 2.7.9 per default. * Upgraded eGenix PyRun to work with and use Python 3.4.3 for Python 3 support. * Added support for setting rpath on the PyRun binary to make it easy to ship external libraries together with PyRun, without having to set the LD_LIBRARY_PATH variable. * Added special support for egenix-pyopenssl to load its OpenSSL libs during startup. * PyRun allows to disable the new default HTTPS certificate verification (PEP 476) by setting the env var PYRUN_HTTPSVERIFY to 0. Default is to apply certificate verification. * Add support for more Python command line options: -s and -3 are ignored, -R raises an error explaining to use the PYTHONHASHSEED env var instead, -B prevents writing of byte code files.This should increase compatibility of PyRun with the standard Python command line interface. Enhancements / Changes -- * Added patch for Python 2.7.9 and 3.4.3 to make ctypes work again after changes to those versions of Python. See https://bugs.python.org/issue23042 for details. * The PyRun -v command line switch will now be passed to Python and supports setting the level using e.g. -vv for a verbose 2 level. * Disabled user site configurations in PyRun, since these are not needed or wanted for typical PyRun uses and cost startup time. * Optimized sys.path setup a bit. PyRun won't check for a Python build run and will not check lib/site-python on startup anymore. * PyRun for Python 3.4 is no longer compiled to always run in optimized mode. This allows using asserts in tests again. Fixes - * Entering license in the interactive shell now returns the correct URL for all supported Python versions. * Tilde expansion now works for most arguments of install-pyrun. This wasn't working before due to a bug. install-pyrun Quick Install Enhancements - eGenix PyRun includes a shell script called install-pyrun, which greatly simplifies installation of PyRun. It works much like the virtualenv shell script used for creating new virtual environments (except that there's nothing virtual about PyRun environments). https://downloads.egenix.com/python/install-pyrun With the script, an eGenix PyRun installation is as simple as running: ./install-pyrun targetdir This will automatically detect the platform, download and install the right pyrun version into targetdir. We have updated this script since the last release: * Updated install-pyrun to default to eGenix PyRun 2.1.0 and its feature set. * Added -r/--requirements option which allows automatically installing a set of required packages using a requirements file, so you can easily set up a complete Python
Re: anomaly
On Mon, May 11, 2015 at 2:40 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 10/05/2015 20:12, boB Stepp wrote: I'm surprised that this thought has not been added to the Zen Of Python, as I see it as more and more recurrent as I continue my studies. What I would like to comprehend is what is the essential mindset of Python? That is, what do I need to understand, so that I am no longer likely to be surprised by discovering new possibilities in Python such as what the current thread is discussing? You need to understand that Python is so powerful that after 14 years I still can't wrap my mind around all of the possibilities that it offers. That's quite a statement! I see I have a loooggg journey ahead!! -- boB -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Op 11-05-15 om 12:40 schreef Mark Lawrence: On 11/05/2015 11:15, Antoon Pardon wrote: Op 10-05-15 om 19:28 schreef Gary Herron: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? Besides, it's still available as __builtins__.int (unless you've also overridden that). This is a common python myth. That is selectively used when convenient and ignored when that is convenient. Try overriding None, True or False in python3 and see what happens. According to https://docs.python.org/3/reference/lexical_analysis.html#keywords None, True and False are all keywords in Python 3, int isn't as I believe has already been pointed out. Which is exactly the point! They were turned into keywords because the developers didn't want to allow them being overridden. There is no a priori reason why we should turn True into a keyword and allow int in the builtins. We are only allowed to be adults, for as far as the developers let us. They allow us to be adults with regards to int but they don't allow us to be adults with regards to True. Defending int being overridable by declating We're all adults is being selective. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
Dave Angel da...@davea.name: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. One thing that gives me trouble quite often is that Ctrl-C doesn't kill a multithreaded Python program. Instead, you need to do: Ctrl-Z [1]+ Stopped kill %1 Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On 11/05/2015 12:39, Antoon Pardon wrote: Op 11-05-15 om 12:40 schreef Mark Lawrence: On 11/05/2015 11:15, Antoon Pardon wrote: Op 10-05-15 om 19:28 schreef Gary Herron: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? Besides, it's still available as __builtins__.int (unless you've also overridden that). This is a common python myth. That is selectively used when convenient and ignored when that is convenient. Try overriding None, True or False in python3 and see what happens. According to https://docs.python.org/3/reference/lexical_analysis.html#keywords None, True and False are all keywords in Python 3, int isn't as I believe has already been pointed out. Which is exactly the point! They were turned into keywords because the developers didn't want to allow them being overridden. There is no a priori reason why we should turn True into a keyword and allow int in the builtins. We are only allowed to be adults, for as far as the developers let us. They allow us to be adults with regards to int but they don't allow us to be adults with regards to True. Defending int being overridable by declating We're all adults is being selective. If you say so but I disagree and can't be bothered to say anything else. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
why would this print 'True'?
from itertools import ifilter if all (hasattr (b, 'test') for b in ifilter (lambda b: b 10, [1,2,3,4])): print 'True' same result using filter instead of ifilter. hasattr (b, 'test') where b is 1, 2, 3... should all be False. So why does this print True? -- Those who fail to understand recursion are doomed to repeat it -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote: There is no a priori reason why we should turn True into a keyword and allow int in the builtins. Why should there be an *a priori* reason? There's no a priori reason why I speak English, instead of communicating through the medium of dance. Nevertheless there are many good, compelling reasons for speaking English (as well as some reasons that are best described as historical accidents). Might I be better off if I spoke Latin, Japanese or Klingon? Perhaps, perhaps not. Those are valid choices too, but they're not choices I have made. With programming languages, the designer can take the same route as Pascal or Java, and define standard functions as keywords that cannot be shadowed or redefined. Or one can design the language to be like Forth, where there are no keywords and literally everything can be redefined. Or one can take a middle-road, where certain syntactic elements, and a very small number of constant values, are made keywords, and everything else is free to be redefined. There's no a priori reason for any of those choices. But there are reasons. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: Well, 1-4k RAM can be consumed just after the start up (it's only 100-300 integers) and never freed. What next? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Feature Request: Reposition Execution
On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. Are you suggesting that the app sends itself a signal? Is that even allowed? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Mon, May 11, 2015 at 2:44 AM, Chris Angelico ros...@gmail.com wrote: On Mon, May 11, 2015 at 5:12 AM, boB Stepp robertvst...@gmail.com wrote: Common Python thought:: We're all adults here.If you want to override a builtin within your own namespace, who are we to stop you? I'm surprised that this thought has not been added to the Zen Of Python, as I see it as more and more recurrent as I continue my studies. What I would like to comprehend is what is the essential mindset of Python? That is, what do I need to understand, so that I am no longer likely to be surprised by discovering new possibilities in Python such as what the current thread is discussing? The Zen of Python is a static document, a historical artifact of a sort. But in terms of understanding the philosophy of Python, we're all adults here is a big part of it. Once you grok the notion that nothing can be prevented, you're freed from such considerations as: * Obfuscating, encrypting, or otherwise hiding your source code * Private members with restricted access * Strict type checking, to prevent someone passing in a wrong piece of data * Prevention of monkey-patching etc, etc, etc. In actual fact, anyone can bypass any restriction, in any language; and Python is just more open/honest about it than languages like C++; for instance, instead of having true private members where the compiler stops you from looking at or changing them, Python gives you single-underscore-named attributes, where nobody stops you from doing anything, but there's a general understanding that they're not governed by the usual compatibility rules, so upgrading a library might break your code. Happy with that? Go ahead then, use the internals. Thanks, Chris, that helps a lot. It seems that beyond being a programming language, Python has a well-established culture that suggests how the language should be used. I am gathering that understanding the language and embracing the existing culture are needed to use Python in the way it is meant to be used, though the language design allows *other* ways, too. Hakuna matata, what a wonderful phrase. Indeed! And a good way to start my Monday morning. -- boB -- https://mail.python.org/mailman/listinfo/python-list
Feature Request: Reposition Execution
Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. The script is unaware of this. Current solution would require to have an Abort boolean everywhere. The abort boolean could then be set to True to indicate all code and all loops must abort. This is far from the ideal solution. I think a much better solution could be to reposition the instruction pointer so to speak. However for x86 stack clean up would be necessary. I would assume python has a stack too... which would need cleaning up. Perhaps the entire stack can simply be cleaned up. So that the point for execution continuation is always clean in a clean state. So this allows for the stack to be cleaned completely... without any trouble. I also hope this feature gets implemented quickly cause I kinda need it. Therefore I will give some example code to see how it could look like: def MyFunction(): while SomeCondition: RunMyCode return def OtherFunction(): while BatmanIsAliveLOL: BustPenguins return def DetectProblem: if ProblemDetected: Aborted = True Abort( AbortToPoint ) return SpawnThread( DetectProblem) while MyMainLoop: AbortToPoint: if Aborted: Reset stuff MainCode, Call Routines. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On 11/05/2015 02:18, zipher wrote: Huh? Python has plenty of keywords, and indeed, none of them can be redefined or shadowed.But you would gain nothing (and lose a bit or dynamic-language freedom) by making int a keyword. Okay. I apologize for thinking in C and believing int was a keyword. Even C allows this: #define int(a) strlen(a) (although it doesn't like #define int strlen for some reason.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: why would this print 'True'?
Nevermind - I found the answer. I was trying this in ipython with pylab: http://stackoverflow.com/questions/7491951/python-builtin-all-with-generators Neal Becker wrote: from itertools import ifilter if all (hasattr (b, 'test') for b in ifilter (lambda b: b 10, [1,2,3,4])): print 'True' same result using filter instead of ifilter. hasattr (b, 'test') where b is 1, 2, 3... should all be False. So why does this print True? -- Those who fail to understand recursion are doomed to repeat it -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On 05/11/2015 08:35 AM, Steven D'Aprano wrote: On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. Are you suggesting that the app sends itself a signal? Is that even allowed? No idea if it's allowed. I didn't notice his sample was multithreaded, as i grabbed on the externally goes badly wrong. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Op 11-05-15 om 13:58 schreef Marko Rauhamaa: Antoon Pardon antoon.par...@rece.vub.ac.be: Which is exactly the point! They were turned into keywords because the developers didn't want to allow them being overridden. There is no a priori reason why we should turn True into a keyword and allow int in the builtins. We are only allowed to be adults, for as far as the developers let us. They allow us to be adults with regards to int but they don't allow us to be adults with regards to True. Defending int being overridable by declating We're all adults is being selective. I'm still failing to see the point. What problem are you having a difficulty solving? The point is that all too often someone wants to defend a specific choice the developers have made and cites some general rule or principle in support, ignoring the fact that python breaks that rule/principle in other area's. We are all adults, we give you the freedom to break things or write confusing code and variantions is such a rule/principle, because often enough changes in the language are introduced to make it easier to eliminate bugs or are refused because they would be too bug prone. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Op 11-05-15 om 14:34 schreef Steven D'Aprano: On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote: There is no a priori reason why we should turn True into a keyword and allow int in the builtins. Why should there be an *a priori* reason? I don't say there should be an *a priori* reason, but one implies or at least strongly suggests an *a priori* reason when one comes with such general rule as /We are all adults, so we allow this kind of thing./ We allow buitins to be overridden, doesn't sound as a very accurate description of the underlining reason, when you know that things have been removed from builtins and made a keyword in order to prevent them from being overridden. -- https://mail.python.org/mailman/listinfo/python-list
[issue24165] Free list for single-digits ints
New submission from Serhiy Storchaka: Proposed patch adds free list for single-digit PyLong objects. In Python tests 7% of created objects are ints. 50% of them are 15-bit (single-digit on 32-bit build), 75% of them are 30-bit (single-digit on 64-bit build). See the start of the discussion in issue24138. -- components: Interpreter Core files: int_free_list_2.patch keywords: patch messages: 242894 nosy: BreamoreBoy, ethan.furman, larry, lemburg, mark.dickinson, pitrou, rhettinger, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Free list for single-digits ints type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39342/int_free_list_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
Antoon Pardon antoon.par...@rece.vub.ac.be: The point is that all too often someone wants to defend a specific choice the developers have made and cites some general rule or principle in support, ignoring the fact that python breaks that rule/principle in other area's. Granted, but you have set the trap for them by demanding a justification when no justification was required. Every language has their cute idiosyncrasies and arbitrary design choices. Still, I have seen some glitches in the matrix as well: setattr(3, __str__, lambda: hello) Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'int' object attribute '__str__' is read-only setattr(3, hello, lambda: hello) Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'int' object has no attribute 'hello' Bottom line, though, is that these corner cases in no way prevent you from accomplishing your programming objective using Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: I looked at this six years ago. I still haven't found a situation where I pined for a NamedTupleReader. That said, I have no objection to committing it if others, more well-versed in current Python code and NamedTuples than I gives it a pass. Note that I added a couple comments to the csv.py diff, but nobody either updated the code or explained why I was out in the weeds in my comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote: I have to admit being surprised by this, too. I am just now studying on how to write my own classes in Python, and have come to realize that doing this is *possible*, but the *surprise* to me is why the language design allowed this to actually be done. Read Cory Doctorow lately on the War Against General Purpose Computing, where a bunch of people who don't really understand are trying to make it impossible for any computer to do something that is The Wrong Thing. Or gently approach the relevant computing theory through Doug Hofstadter's _Goedel, Escher, Bach_, or some essays in _Metamagical Themas_. Generally speaking, making a computer totally incapable of doing Wrong Things leaves it incapable of doing anything at all. Mel. -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling a function is faster than not calling it?
On Mon, May 11, 2015 at 10:01 AM, BartC b...@freeuk.com wrote:
(1) It has an extra argument ('code'), in addition to any normal arguments
of func (0 in this case)
Which might well push execution down the unoptimized code path. Also,
ISTR that Steven's original timeit runs tacked on a standalone eval ;
... to the function call case, so the LOAD_GLOBAL bytecode would have
been done in the function call case as well. He was, I think, doing
what he could to make the two cases as nearly identical as he could.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Immediate Hire: Sr. Java Software Engineer - Oklahoma - GC, US Citizens Onlt
Hi, Hope you are doing well, Please find the requirement below and let me know you interest on this position on nagar...@intsystech.com or feel free to call me on my D:908-333-3534. Requirement: Job Description - Sr. Java Software Engineer Location: Edmond, Oklahoma Responsibilities: Provide applications development and enhancement functions; including analysis, design, coding, testing, and deployment of Java web applications and web services. Work with business analysts and technical architects to formalize specifications for custom development. Proactively work to solve issues while including the key functional and/or business stakeholders. Provide analysis and prototyping of new custom solutions, or new requirements for existing custom solutions. With limited supervision, develop and enhance custom solutions using approved technologies and platforms. Document and perform unit, integration, and regression testing in support of new implementations and releases. Skills: Basic Qualifications 7+ years of object oriented application development experience using Java Solid experience with web application development Practical knowledge with web service and API development Expertise in application servers including WebSphere, JBoss and Tomcat Proficiency with the Spring Framework including Spring MVC and Spring Data Strong understanding of object oriented concepts, web application and web service design, open source tools, and web application frameworks Professional experience designing, developing and deploying software solutions Nice to Have: Financial Services Systems experience Security Experience Drools and jBPM knowledge Understanding of LifeRay Other attributes: Attention to detail Focus on quality of both code and user experience Thrive in an entrepreneurial environment Excellent oral and written communication skills Strong analytical and problem solving skills Inspire a culture of innovation and teamwork Thanks Best Regards? Raju International Systems Technologies Inc. 10 Corporate place south.| Suite 203 | Piscataway, NJ 08854 | D:908-333-3540 |Fax:732-348-9533| E-mail: nagar...@intsystech.com | G-talk: nagarajuusstaff...@gmail.com URL: www.intsystech.com -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 9:52:16 AM UTC-5, Skip Montanaro wrote: Steven Python is in production use in hundreds of thousands of organisations. It Steven has been heavily used for over twenty years, in everything from quick and Steven dirty one line scripts to hundred-thousand LOC applications. Mark Yeah, so was COBOL. Boom. Your point being? That a billion lines of code doesn't equate to practicality. The software development landscape has changed so much since the days when COBOL was king of data processing that its popularity then had less to do with some sort of software natural selection than IBM's utter domination of the computing landscape in the 1960s. Yes, and I would argue that the OOP landscape has changed since the 1990s (with the rise of very high level languages like Python). The idea of everything is an object is an exploration of PL design that I'm claiming is not appropriate for whatever language will create this data ecosystem that I say is as inevitable as a single language being used on the Internet -- it's simply a chaotic attractor that is irresistible for it's sheer utility. I also bought the idea of everything as an object, it has a unbeatable purity to it. But we won't ever get to the point were OOP is like the purity of math because the greatest utility of OOP is working with real-world data. And that real-world puts bounds on the otherwise abstract purity in which a language is theoretically capable. Mark P.S. As Mr. Reedy said, please remove pydev from the To: line. This is the proper general rule when a discussion goes into abstractions, rather than practicality of development. -- https://mail.python.org/mailman/listinfo/python-list
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
New submission from Paul Baker: On the www.python.org/downloads/windows page, the Windows x86 MSI installer links for versions 2.4.4, 2.4.3, 2.4.2 and 2.4.0 point to the IA64 versions of the installers rather than the x86 versions. For example, the 2.4.4 link points to python-2.4.4.ia64.msi rather than python-2.4.4.msi. -- components: Installation, Windows messages: 242897 nosy: paul.baker, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 2.4.X links on www.python.org/downloads/windows point to the wrong files ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Don't CS departments still have a computer languages survey class? When I was a graduate student at Iowa in the early 80s, we had one. (It was, as I recall, an upper level undergrad course. I didn't get into CS until graduate school, so went back to filled in some missing stuff.) I don't recall all the languages we touched on, but ISTR there were five or six. I know we hit Lisp (today, it would likely be Scheme), and probably APL (today it would probably be Python+Pandas, MATLAB, R, or something similar). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling a function is faster than not calling it?
On Mon, May 11, 2015 at 4:50 AM, BartC b...@freeuk.com wrote: You just seem surprised that using eval() to do this is slower than a direct call. Well, it is surprising. Most uses of eval() are to evaluate Python expressions in string form. That I expect to be quite slow, given the parsing+byte compilation overhead. I wouldn't expect eval()ing a code object to be all that different than calling the function containing the code object. My guess (without looking in ceval.c) is that the code path through the VM has been tweaked heavily over the years to try and speed it up. Except for places where that path overlaps with the path for eval(code_object), I doubt any attention has been paid to speeding up eval. I could certainly be way off-base here. Perhaps the path taken through the interpreter for eval(code_object) is more-or-less a subset of the path taken for a simple function call. Skip -- https://mail.python.org/mailman/listinfo/python-list
[issue24165] Free list for single-digits ints
Brett Cannon added the comment: Any chance of running hg.python.org/benchmarks to see what kind of performance this would get us? -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On Mon, May 11, 2015 at 11:38 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: We allow buitins to be overridden, doesn't sound as a very accurate description of the underlining reason, when you know that things have been removed from builtins and made a keyword in order to prevent them from being overridden. There are principles, and then there are specific instances that go against those principles. The overarching principle has its justification; the violations have to have their own justifications. As Steven said, there are no a priori reasons for most things - or to put it another way, there are very few design decisions that come down to a fundamental this is right, this is wrong - but there can be strong and weak justifications for things. Why does Python have most built-ins as simply looked-up names that can be overridden? Because otherwise, there would be a veritable ton of keywords: dir(builtins) ['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError', 'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError', 'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetError', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FileExistsError', 'FileNotFoundError', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'InterruptedError', 'IsADirectoryError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotADirectoryError', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'PermissionError', 'ProcessLookupError', 'ReferenceError', 'ResourceWarning', 'RuntimeError', 'RuntimeWarning', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'TimeoutError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning', 'ValueError', 'Warning', 'ZeroDivisionError', '__build_class__', '__debug__', '__doc__', '__import__', '__loader__', '__name__', '__package__', '__spec__', 'abs', 'all', 'any', 'ascii', 'bin', 'bool', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'exec', 'exit', 'filter', 'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'map', 'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit', 'range', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'vars', 'zip'] in addition to these, which _are_ keywords: keyword.kwlist ['False', 'None', 'True', 'and', 'as', 'assert', 'break', 'class', 'continue', 'def', 'del', 'elif', 'else', 'except', 'finally', 'for', 'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'nonlocal', 'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with', 'yield'] Python 2 had 'print' as a keyword, and it was specifically turned into a non-keyword in Python 3 to allow it to be overridden. It could have been turned into a function while still being a keyword, but it wasn't. Conversely, True and False became keywords, because there's no practical reason to override them. [1] You may well want to shadow 'copyright' with your own program's copyright notice, given that the built-in name is primarily there for interactive use. You might use 'input' to store the incoming text in a non-interactive program, or 'quit' in an interactive one to store a flag that becomes True when the user wants to terminate. Very frequently, 'id' is used as a database ID. None of these shadowings is a problem to the language; chances are none of them will ever be a problem to your code either. Having most of the built-in names *not* be keywords means that adding new built-ins doesn't break code; code that used the name for some other meaning will still work, but won't be able to use the new feature. That's a good thing. ChrisA [1] http://thedailywtf.com/articles/What_Is_Truth_0x3f_ notwithstanding. -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature Request: Reposition Execution
On 2015-05-11, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to interrupt/reset/reposition a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. Are you suggesting that the app sends itself a signal? Is that even allowed? Of course (at least on Unix/Linux/Posix systems). And there's even a special case defined to make sending signals to yourself easy: you just send them to PID 0. From man 2 kill on Linux: DESCRIPTION The kill() system call can be used to send any signal to any process group or process. [...] If pid equals 0, then sig is sent to every process in the process group of the calling process. And just to make sure I ran a little test, and it works exactly as advertised: -testit.py #!/usr/bin/python import os, sys, time, threading, signal def thread1(): while True: sys.stdout.write(Hello %s\n % time.time()) time.sleep(1) threading.Thread(target=thread1).start() time.sleep(2) os.kill(0,signal.SIGKILL) --- $ ./testit.py Hello 1431354383.19 Hello 1431354384.19 Killed $ -- Grant Edwards grant.b.edwardsYow! Hello. Just walk at along and try NOT to think gmail.comabout your INTESTINES being almost FORTY YARDS LONG!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 2015-05-11, Skip Montanaro skip.montan...@gmail.com wrote: Don't CS departments still have a computer languages survey class? When I was a graduate student at Iowa in the early 80s, we had one. (It was, as I recall, an upper level undergrad course. I didn't get into CS until graduate school, so went back to filled in some missing stuff.) I don't recall all the languages we touched on, but ISTR there were five or six. I know we hit Lisp (today, it would likely be Scheme), and probably APL (today it would probably be Python+Pandas, MATLAB, R, or something similar). There was a similar class at both Iowa State and University of MN. You learned a half-dozen languages in a single quarter. IIRC, at ISU we did Lisp, Prolog, APL, Snobol and a couple others. The main pedagogical language at the time was Pascal, but we also learned FORTRAN, COBOL, BASIC, and a couple three assembly languages (PDP-11, VAX, Z80, 6502). If you were a computer enineering major instead of computer science, you also leared a hardware description language. At the time it was AHPL. More recent gruaduates only seem to know one language (Java or C++) and are completely baffled by anything else. And don't get me started on that damned noise they call music... -- Grant Edwards grant.b.edwardsYow! ! Now I understand at advanced MICROBIOLOGY and gmail.comth' new TAX REFORM laws!! -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Steven Python is in production use in hundreds of thousands of organisations. It Steven has been heavily used for over twenty years, in everything from quick and Steven dirty one line scripts to hundred-thousand LOC applications. Mark Yeah, so was COBOL. Boom. Your point being? The software development landscape has changed so much since the days when COBOL was king of data processing that its popularity then had less to do with some sort of software natural selection than IBM's utter domination of the computing landscape in the 1960s. If you bought IBM's hardware (as almost everyone did *), you also got what they offered in the way of software. I believe (though this is certainly before my time in the industry) that basically meant FORTRAN or COBOL (maybe APL? Wow, I've mentioned it twice in one day). In contrast, software developers and project managers had plenty of options available when they chose Python. Skip * Searching Google for If it's blue, buy two doesn't turn up any obvious hits for this old aphorism (roughly meaning, If you need to buy computers, buying IBM is a safe bet, or more to the professional bottom line of the person making the decision, Nobody's going to fire you if you buy an IBM mainframe and it turns out to be the wrong choice). Am I the only person who remembers it? -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote: Antoon Pardon antoon.par...@rece.vub.ac.be: The point is that all too often someone wants to defend a specific choice the developers have made and cites some general rule or principle in support, ignoring the fact that python breaks that rule/principle in other area's. Granted, but you have set the trap for them by demanding a justification when no justification was required. Every language has their cute idiosyncrasies and arbitrary design choices. No. Here's where I must disagree. I think one can infer a goal for particular programming languages, even if it is subconscious. For example, with LISP it could be generality. For C, it could be staying as close to the machine as possible while maximizing the use to humans -- contradiction that works because they've limited their architecture to VonNeumann (stackless) machines. I think the subconscious goal of OOP languages is to create a data ecosystem, starting with a unified data model under the realization that ultimately: all data relates to other data -- that my database of wind speed and direction from 2012 is relatable, by some finite number of hops, to your data on population growth in Chicago. Call it the seven degrees of data and remember the exabytes of data out there. Python is creating the perfect system for that because it has an interpreter environment with which to manipulate objects that could be retrieved on the net and sent back out. It has docstrings so that your foreign object can self-document, and doctests, so that I can be confident that your code works as *I* expect. There are reasons to have limits on programming freedom. It puts order to chaos. It guides the wily programmers into a particular train of thought. You don't override True because you'd be breaking one of the [explicit] goals of the language: readability. If there were no constraints, life itself could not exist. I don't think shadowing built-in types was a design choice but simply never got exercised because most people are used to handling such things, *subconsciously*, like C. To Mr. Gatti, my point was not an insult, it is a theoretical postulate in the domain of Computer Science. One that has not really been studied. OOP is still far from it's goal, so the field is still answering questions within it. Mark -- https://mail.python.org/mailman/listinfo/python-list
[issue24166] ArgumentParser behavior does not match generated help
New submission from Benjamin Schubert:
When creating a ArgumentParser on which we attach a subparser with different
options and then add a nargs=+ argument to the initial parser, the command
format string generated does not match the behavior.
for example it would generate :
argparse_error.py [-h] {ls,du} ... vm [vm ...]
but only accept one vm.
I would suspect a bug when parsing the arguments (as the help meets the desired
behavior).
Attached is a little script to reproduce the error.
Thank you !
--
components: Library (Lib)
files: argparse_error.py
messages: 242895
nosy: tellendil
priority: normal
severity: normal
status: open
title: ArgumentParser behavior does not match generated help
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file39343/argparse_error.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote: On Monday 11 May 2015 10:57, zipher wrote: I guess everyone expects this behavior since Python implemented this idea of everything is an object, but I think this branch of OOP (on the branch of the Tree of Programming Languages) has to be chopped off. The idea of everything is an object is backwards (unless your in a LISP machine). Like I say, it's trying to be too pure and not practical. Python is in production use in hundreds of thousands of organisations. It has been heavily used for over twenty years, in everything from quick and dirty one line scripts to hundred-thousand LOC applications. Yeah, so was COBOL. Boom. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
Further posts on this thread should delete pydev-list or gmane.comp.python.devel. It was a mistake by the troll to ever post this there. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling a function is faster than not calling it?
On 11/05/2015 15:12, Skip Montanaro wrote:
On Mon, May 11, 2015 at 4:50 AM, BartC b...@freeuk.com
mailto:b...@freeuk.com wrote:
You just seem surprised that using eval() to do this is slower than
a direct call.
Well, it is surprising. Most uses of eval() are to evaluate Python
expressions in string form. That I expect to be quite slow, given the
parsing+byte compilation overhead. I wouldn't expect eval()ing a code
object to be all that different than calling the function containing the
code object.
func() (when the call is itself inside a function) has this bytecode:
11 0 LOAD_GLOBAL 0 (func)
3 CALL_FUNCTION0
6 POP_TOP
7 LOAD_CONST 0 (None)
10 RETURN_VALUE
eval(code) (when this is also inside a function, and code is local) has
this bytecode:
16 6 LOAD_GLOBAL 0 (eval)
9 LOAD_FAST0 (code)
12 CALL_FUNCTION1
15 POP_TOP
16 LOAD_CONST 0 (None)
19 RETURN_VALUE
So eval() seems to be just as much a function call as func() is. Except:
(1) It has an extra argument ('code'), in addition to any normal
arguments of func (0 in this case)
(2) Before it can do whatever func() does, in has to /get there/ first.
And that can code presumably has a similarly indirect path to return to
the point to where eval() was called. So there is extra code inside eval
to deal with this (as well as check whether a string has been passed).
That code must be the extra overhead.
So it seems clear to me that the eval method has to do everything that
calling func() has to do, and then some.
(That doesn't necessarily mean it would be slower; whatever goes on
inside could well have been made less efficient for a direct call than
for an indirect one via eval. But the results suggest it is slower using
eval. And it isn't really surprising.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
STINNER Victor added the comment: You should report bugs of the website to https://github.com/python/pythondotorg/issues -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to properly apply OOP in the bouncing ball code
Thanks for your help. I have updated the code as follows, there are no more errors but the images will not move at all, as all the images are staying at the upper left corner. Please advice, thanks. import sys, pygame pygame.init() size = width, height = 800, 600 black = [0,0,0] screen = pygame.display.set_mode(size) class BALL: def __init__(self,image): self.ball = pygame.image.load(image) self.ballrect = self.ball.get_rect() self.speed= [2, 2] def control(self): ballmove = self.ballrect.move(self.speed) if ballmove.left 0 or ballmove.right width: self.speed[0] = -self.speed[0] if ballmove.top 0 or ballmove.bottom height: self.speed[1] = -self.speed[1] def settings(self): clock = pygame.time.Clock() screen.fill(black) screen.blit(self.ball, self.ballrect) pygame.display.flip() clock.tick(60) while 1: for event in pygame.event.get(): if event.type == pygame.QUIT: sys.exit() bob = BALL(spongebob.png) bob.control() bob.settings() patrick = BALL(patrick.jpg) patrick.speed[0] = 5 patrick.speed[1] = 8 patrick.control() patrick.settings() jaws = BALL(jaws.jpg) jaws.speed[0] = 1 jaws.speed[1] = 10 jaws.control() jaws.settings() On Friday, May 8, 2015 at 11:40:46 AM UTC-4, Tommy C wrote: I'm trying to apply OOP in this bouncing ball code in order to have multiple balls bouncing around the screen. The objective of this code is to create a method called settings, which controls all the settings for the screen and the bouncing behaviour of multiple balls, under the class Ball. However, I keep on getting errors related to attributes (e.g., speed). I'm new to OOP in Python so your help will be much appreciated. Thanks in advance. import pygame import random import sys pygame.init() class Ball: def __init__(self, X, Y): self.velocity = [1,1] self.ball_image = pygame.image.load (ball.jpg) self.ball_boundary = self.ball_image.get_rect () self.black = [0,0,0] self.width = 800 self.height = 600 self.num = 8 self.X = random.randint(0, self.width) self.Y = random.randint(0, self.height) def settings(self): #X = random.randint(0, self.width) #Y = random.randint(0, self.height) clock = pygame.time.Clock() size = self.width, self.height screen = pygame.display.set_mode(size) ball_boundary = self.ball_image.get_rect() speed = self.velocity pic = self.ball_image pygame.display.set_caption(Balls) num_balls = self.num ball_list = [] for i in range(num_balls): ball_list.append( Ball(random.randint(10, self.width-10),random.randint(10, self.height-10)) ) while 1: for event in pygame.event.get(): if event.type == pygame.QUIT: sys.exit(0) screen.fill(self.black) for balls in ball_list: if balls.ball_boundary.left 0 or balls.ball_boundary.right self.width: balls.speed[0] = -balls.speed[0] if balls.ball_boundary.top 0 or balls.ball_boundary.bottom self.height: balls.speed[1] = -balls.speed[1] balls.ball_boundary = balls.ball_boundary.move (self.velocity) screen.blit (balls.ball_image, balls.ball_boundary) pygame.display.flip() play = Ball(random.randint(0, 800), random.randint(0, 600)) play.settings() Message File Name LinePosition Traceback module C:\\Multiple_balls_TC.py63 settings C:\\Multiple_balls_TC.py56 AttributeError: Ball instance has no attribute 'speed' -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 2.7.10 release candidate 1
It is my privilege to announce the first release candidate of 2.7.10, the next bugfix release in the 2.7 series. Downloads are at https://www.python.org/downloads/release/python-2710rc1/ The full changelog is at https://hg.python.org/cpython/raw-file/80ccce248ba2/Misc/NEWS Please consider testing 2.7.10rc1 with your application and reporting bugs to https://bugs.python.org Regards, Benjamin -- https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Sunday, May 10, 2015 at 10:32:07 PM UTC-5, Ian wrote:
On Sun, May 10, 2015 at 7:39 PM, zipher dreamingforw...@gmail.com wrote:
Similarly, you'd want:
encode(codestr)
to instantiate all objects in the codestr. You can't do this with eval,
because it doesn't allow assignment (eval(n=2) returns InvalidSyntax).
Is exec what you're looking for?
exec('n = 2')
print(n)
2
Ah, yeah, I guess that does it. But (shame) it looks like you've gone past the
BDFL. Try:
help(exec)
^
SyntaxError: invalid syntax
Better
Mark
--
https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Monday, May 11, 2015 at 10:22:15 AM UTC-5, zipher wrote: Ah, yeah, I guess that does it. But (shame) it looks like you've gone past the BDFL. Try: [...] Better Oops, omit word better. Sent before reading over it again... m -- https://mail.python.org/mailman/listinfo/python-list
Re: How to properly apply OOP in the bouncing ball code
On Friday, May 8, 2015 at 10:40:46 AM UTC-5, Tommy C wrote: I'm trying to apply OOP in this bouncing ball code in order to have multiple balls bouncing around the screen. The objective of this code is to create a method called settings, which controls all the settings for the screen and the bouncing behaviour of multiple balls, under the class Ball. However, I keep on getting errors related to attributes (e.g., speed). I'm new to OOP in Python so your help will be much appreciated. Thanks in advance. You are making a error that few in the programming community have caught up to. OOP design for *data abstraction* is a completely different beast that OOP for *simulation*. The confusion is around the use of the word object which both denotes a physical world item and a virtual one detached from reality. I would say that Python might not be the right fit, but instead a language dedicated to simulation. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On 2015-05-11, Skip Montanaro skip.montan...@gmail.com wrote: Python is in production use in hundreds of thousands of organisations. It has been heavily used for over twenty years, in everything from quick and dirty one line scripts to hundred-thousand LOC applications. Mark Yeah, so was COBOL. Boom. Your point being? That Python, like COBOL, is an eminently practical language. -- Grant Edwards grant.b.edwardsYow! YOU PICKED KARL at MALDEN'S NOSE!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote: On 2015-05-11, Skip Montanaro skip.montan...@gmail.com wrote: Python is in production use in hundreds of thousands of organisations. It has been heavily used for over twenty years, in everything from quick and dirty one line scripts to hundred-thousand LOC applications. Mark Yeah, so was COBOL. Boom. Your point being? That Python, like COBOL, is an eminently practical language. LOL! Good one. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Tue, May 12, 2015 at 1:22 AM, zipher dreamingforw...@gmail.com wrote:
Ah, yeah, I guess that does it. But (shame) it looks like you've gone past
the BDFL. Try:
help(exec)
^
SyntaxError: invalid syntax
That's because, in the version of Python you're using, exec is a
keyword. You could switch to Python 3, where it's a function, or
request it by name. Though interestingly, my Py2 doesn't have any help
on exec:
help('exec')
no documentation found for 'exec'
Not sure why that is.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote: The point is that all too often someone wants to defend a specific choice the developers have made and cites some general rule or principle in support, ignoring the fact that python breaks that rule/principle in other area's. It's a free country, you can do what you like. No I can't, I'm not allowed to kill people. Um, okay. Just because there are exceptions to a rule doesn't mean it isn't a general rule. A few exceptions are just exceptions, they don't invalidate the fact that consenting adults is a basic design principle of Python. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
Paul Baker added the comment: Done: https://github.com/python/pythondotorg/issues/751 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On Mon, May 11, 2015 at 10:11 AM, zipher dreamingforw...@gmail.com wrote: I also bought the idea of everything as an object, it has a unbeatable purity to it. But we won't ever get to the point were OOP is like the purity of math because the greatest utility of OOP is working with real-world data. And that real-world puts bounds on the otherwise abstract purity in which a language is theoretically capable. Did someone here say it would? Sure, OOP isn't as pure as math, but most object-oriented languages aren't pure OO languages, either. (Maybe Smalltalk?) In Python, when you want to manipulate bazillions of numbers, you use numpy, pandas, etc. In C++, you code in the C subset it (still) contains when you don't want objects. The practicality side of things suggests that even though everything-is-an-object isn't perfect, it may be good enough. People/projects/companies generally can't afford to follow every change that blows through their environment. That's why (for example), COBOL lasted so long. In fact, I suspect you could still make a good living writing COBOL, if you really wanted to. (Searching indeed.com for COBOL in Chicago, IL gave me 81 hits.) Python was never meant to be pure. It has, by Guido's own admission, borrowed ideas from many other languages. Very little in Python is truly new, certainly not its object model. At the user level everything appears to be an object, but not everything is under the covers (e.g., numeric elements of array objects). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Immediate Hire: Sr. Java Software Engineer - Oklahoma - GC, US Citizens Onlt
From: Larry Martell larry.mart...@gmail.com I am only interested in work that I can do remotely from home. If you have any opportunities like that, please contact me. Please do not engage spammers or quote spam. -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- https://mail.python.org/mailman/listinfo/python-list
[issue24165] Free list for single-digits ints
Serhiy Storchaka added the comment: Report on Linux xarax 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:15 UTC 2015 i686 athlon Total CPU cores: 2 ### 2to3 ### 15.796000 - 15.652000: 1.01x faster ### etree_generate ### Min: 0.687270 - 0.715218: 1.04x slower Avg: 0.698458 - 0.722657: 1.03x slower Significant (t=-9.02) Stddev: 0.01846 - 0.00431: 4.2808x smaller ### etree_iterparse ### Min: 1.145829 - 1.117311: 1.03x faster Avg: 1.159865 - 1.129438: 1.03x faster Significant (t=21.95) Stddev: 0.00835 - 0.00513: 1.6297x smaller ### etree_parse ### Min: 0.816515 - 0.867189: 1.06x slower Avg: 0.825879 - 0.877618: 1.06x slower Significant (t=-48.87) Stddev: 0.00405 - 0.00630: 1.5556x larger ### etree_process ### Min: 0.542221 - 0.565161: 1.04x slower Avg: 0.548276 - 0.569324: 1.04x slower Significant (t=-28.38) Stddev: 0.00380 - 0.00361: 1.0540x smaller ### json_load ### Min: 1.020657 - 0.995001: 1.03x faster Avg: 1.025593 - 0.998038: 1.03x faster Significant (t=28.37) Stddev: 0.00503 - 0.00468: 1.0738x smaller ### nbody ### Min: 0.577393 - 0.588626: 1.02x slower Avg: 0.578246 - 0.590917: 1.02x slower Significant (t=-43.51) Stddev: 0.00037 - 0.00203: 5.4513x larger ### regex_v8 ### Min: 0.123794 - 0.119950: 1.03x faster Avg: 0.124631 - 0.121131: 1.03x faster Significant (t=4.92) Stddev: 0.00340 - 0.00371: 1.0917x larger The following not significant results are hidden, use -v to show them: django_v2, fastpickle, fastunpickle, json_dump_v2, tornado_http. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 11.05.2015 21:03, Steve Dower wrote: Steve Dower added the comment: Simply because I didn't update the doc string :) I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. But my main question is why would you still need the old versions around, given that compatibility is already broken? In Python 2, distutils could be easily be used on earlier Python versions, simplifying the amount of work you'd need to do in your setup.py to address differences between the various Python versions you wanted to support. I don't know what the deal is for Python 3. Apart from that, it may be necessary to compile some parts of C extensions with older compilers. Probably a rare case, but then again: what do we gain by removing the old code ? Note that VC9 was handled in the same way: it was added to the set rather than replacing it. That was done in the Python 2 series, though, where the above guarantee was used as basis, so things may be different for Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sunday, May 10, 2015 at 9:38:38 PM UTC-4, Ian wrote: On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa ma...@pacujo.net wrote: Scheme is my favorite language. I think, however, it is a pretty advanced language and requires a pretty solid basis in programming and computer science. Python, in contrast, is a great introductory programming language. Sure, you *can* get quite advanced with it, too, but you can get quite a bit of fun stuff done with just the basics. MIT famously used Scheme in their introductory course for more than two decades. Although they switched to Python a few years ago, I don't think they did so because there was anything wrong with Scheme. Wikipedia informs me that Yale and Grinnell are still using Scheme for their introductory courses. Yale has taken the unusual step of outsourcing its introductory CS class to Harvard, which uses C as the main language in its CS50 class. http://yaledailynews.com/blog/2014/11/07/faculty-approve-cs50-for-yale/ Faculty approve CS50 for Yale Just under a month after announcing that Yale's computer science department was considering importing Harvard's most popular course, faculty voted to bring CS50 to Yale. Following what Yale College Dean Jonathan Holloway described as a long, healthy discussion, faculty at Thursday's monthly meeting voted overwhelmingly to approve CS50 as a class to be taught at Yale. Computer science department chair Joan Feigenbaum said that the next step for CS50 will be for Harvard to approve the sharing of CS50 with Yale. If the course earns approval, she noted, Yale will formally introduce the class in Fall 2015. -- https://mail.python.org/mailman/listinfo/python-list
[issue1100942] Add datetime.time.strptime and datetime.date.strptime
Maciej Szulik added the comment: Berker per your comment updated patch changing those two new methods (namely date.strptime and time.strptime) to be classmethod and not staticmethods. -- Added file: http://bugs.python.org/file39345/issue1100942.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1100942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24157] test_urandom_fd_reopened failure on Mac OS X
Ned Deily added the comment: Skip, looking at the test, it seems likely that there is unexpected writing to stdout in the subprocess. Can you add a print(out) in the test (around test_os.py:1273) to see what is actually being written on your machine? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24157 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24159] Misleading TypeError when pickling bytes to a file opened as text
Changes by Ned Deily n...@acm.org: -- nosy: +alexandre.vassalotti, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Changes by Ned Deily n...@acm.org: -- nosy: +ghaering stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc
Changes by Ned Deily n...@acm.org: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Paul Moore added the comment: I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work (I guess we'll then just continue to override the .initialize() call). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: I guess we need a third opinion. For me, the subclasses of CCompiler are undocumented and not a guaranteed interface (people using them directly are consenting adults). They're also an eyesore, so if I can clean them up without breaking the CCompiler interface (or minor version upgrades) then I should. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24163] shutil.copystat fails when attribute security.selinux is present
Ned Deily added the comment: Possibly related: Issue15238 (msg165591 re root) -- nosy: +hynek, ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 11.05.2015 23:50, Paul Moore wrote: I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work (I guess we'll then just continue to override the .initialize() call). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. This is not about our code. We can work around all this. The point is that in general, we don't break things in Python just because we can, even if we don't need to. In this case, I don't see a need to break things to add support for a new compiler version, which is why I don't follow Steve's arguments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Responding to Raju and friends at Intsystech...
On Mon, May 11, 2015 at 11:12 AM, nagaraju thoudoju nagarajuusstaff...@gmail.com wrote: Please find the requirement below and let me know you interest on this position So this Raju fellow wants to know our interest on [sic] this position, and he's not responded appropriately to anyone's pleas to stop spamming comp.lang.python. Searching groups.google.com for intsystech returned over 26,000 hits, so I doubt we are the only people he's actively spamming. How about everybody reading this note responds to his missive, telling him our interest. Be nice. Respond as if you really are interested in something Intsystech might have to offer. Be sure to leave python-list@python.org/comp.lang.python out of your reply, but paste the following email addresses into your cc list (which includes a few of Raju's fellow spammers): i...@intsystech.com, h...@intsystech.com, suryaprak...@intsystech.com, pavan.ku...@intsystech.com, ke...@intsystech.com, manish.ku...@intsystech.com There's no need to send an angry reply. We can kill them with kindness. In fact, it will waste more of their time if they think, even for a moment, that your email represents legitimate interest in their spam. I think Larry Martell's response was was just about right. Raju posts about a Java position on-site in Edmond, OK, so respond asking him about Python (or COBOL, or Perl, or C++) positions in Anchorage AK, or Chicago IL, or London UK, or telecommuting positions... I don't think there will be any need to tell Raju and his associates where you saw his message. It won't really matter, and it's clearly everywhere at this point. I suspect it will take him a good long while to sift through all the apparently valid responses which just waste their time and make it nearly impossible for them to find the scant valid responses to their spam. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Responding to Raju and friends at Intsystech...
From: Skip Montanaro skip.montan...@gmail.com On Mon, May 11, 2015 at 11:12 AM, nagaraju thoudoju nagarajuusstaff...@gmail.com wrote: Please find the requirement below and let me know you interest on this position So this Raju fellow wants to know our interest on [sic] this position, and he's not responded appropriately to anyone's pleas to stop spamming comp.lang.python. Searching groups.google.com for intsystech returned over 26,000 hits, so I doubt we are the only people he's actively spamming. How about everybody reading this note responds to his missive, telling him our interest. Be nice. Respond as if you really are interested in something Intsystech might have to offer. Be sure to leave python-list@python.org/comp.lang.python out of your reply, but paste the following email addresses into your cc list (which includes a few of Raju's fellow spammers): i...@intsystech.com, h...@intsystech.com, suryaprak...@intsystech.com, pavan.ku...@intsystech.com, ke...@intsystech.com, manish.ku...@intsystech.com There's no need to send an angry reply. We can kill them with kindness. In fact, it will waste more of their time if they think, even for a moment, that your email represents legitimate interest in their spam. I think Larry Martell's response was was just about right. Raju posts about a Java position on-site in Edmond, OK, so respond asking him about Python (or COBOL, or Perl, or C++) positions in Anchorage AK, or Chicago IL, or London UK, or telecommuting positions... I don't think there will be any need to tell Raju and his associates where you saw his message. It won't really matter, and it's clearly everywhere at this point. I suspect it will take him a good long while to sift through all the apparently valid responses which just waste their time and make it nearly impossible for them to find the scant valid responses to their spam. Skip ab...@1and1.com ab...@oneandone.net cab...@tatacommunications.com 4755ab...@tatacommunications.com -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- https://mail.python.org/mailman/listinfo/python-list
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Simply because I didn't update the doc string :) I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. But my main question is why would you still need the old versions around, given that compatibility is already broken? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Antoine Pitrou added the comment: You probably need a workload that uses integers quite heavily to see a difference. And even then, it would also depend on the allocation pattern. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Yury Selivanov added the comment: Nick, Guido, Updated patch attached. -- Added file: http://bugs.python.org/file39344/await_06.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Stefan Behnel added the comment: Well, as I've shown in issue 24076 (I'm copying the numbers here), even simple arithmetic expressions can benefit from a free-list. Basically anything that uses temporary integer results. Original: $ ./python -m timeit 'sum(range(1, 10))' 1000 loops, best of 3: 1.86 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 1))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 1.05 msec per loop With freelist: $ ./python -m timeit 'sum(range(1, 10))' 1000 loops, best of 3: 1.52 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 1))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 931 usec per loop -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24076] sum() several times slower on Python 3
Stefan Behnel added the comment: Issue 24165 was created to pursue the path of a free-list for PyLong objects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: anomaly
On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote: On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote: On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote: I have to admit being surprised by this, too. I am just now studying on how to write my own classes in Python, and have come to realize that doing this is *possible*, but the *surprise* to me is why the language design allowed this to actually be done. Read Cory Doctorow lately on the War Against General Purpose Computing, where a bunch of people who don't really understand are trying to make it impossible for any computer to do something that is The Wrong Thing. I think you are conflating two different ideas of the Wrong Thing. I don't think so. A formal solution to a problem, i.e. a solution coded as a computer program, is limited to the things that can be done using formal techniques. Whether it's people trying to enact their social standards in code, or whether it's people trying to nail the door shut against everything they don't expect, or think is illogical, the limits will still be there. Mel. -- https://mail.python.org/mailman/listinfo/python-list
