Re: Python and the need for speed
On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote: > When people talk about making a restricted optimizable subset of Python, > the implication (if not the explicit declaration) is that it's done > strictly by removing, not by rewriting. Maybe *some* people have a naive, if not foolish, idea that all you need to do to speed up CPython is to go through the C code and hit delete over any functions you don't want. But that's hardly a technique that is going to work: not only will you break features, but merely removing code doesn't magically make the rest of the code base faster. At the very least, you have to re-write the code that depends on the features you have just removed. If we're going to talk about speeding up Python, we ought to talk about *serious* approaches to the problem, not the musing of random, ignorant bloggers and other naive commentators. So let's look at what the experts have done: PyPy: a complete re-write, with a completely different approach (JIT compilation). WPython (alas, now more or less abandoned): a complete re-write of the virtual machine, using 16-bit "wordcodes" instead of 8 bit "bytecodes", nevertheless this enabled a lot of good optimizations: http://repository.root-me.org/Programmation/Python/EN%20-%20Beyond% 20python%20bytecode.pdf https://storage.googleapis.com/google-code-archive-downloads/v2/ code.google.com/wpython2/Cleanup%20and%20new%20optimizations%20in% 20WPython%201.1.pdf Unladen Swallow: among other changes, added new, specialist byte-codes to speed up common operations. http://qinsb.blogspot.com.au/2011/03/unladen-swallow-retrospective.html Nuitka: a static optimizing compiler, and a complete re-write. Nuitka implements a number of compile-time optimizations while still keeping (claimed) 100% compatibility with CPython. http://nuitka.net/doc/user-manual.html FATPython adds compile-time name lookups, specialised functions, dead- code elimination, constant folding and propagation to a CPython base. https://haypo.github.io/fat-python-status-janv12-2016.html Cython: a *superset*, not subset, of Python. I could continue, but you get the point. Some of these are experimental, like FATPython; some were production ready but abandoned because the community had little interest (wpython); some are actively maintained and used in production by many people (cython, PyPy). The Python ecosystem is actually quite healthy, if you need to speed up code there are lots of solutions, and some of them are even good solutions. Nevertheless, it is interesting to discuss whether or not any of these features will go mainstream or make it into CPython. But anyway... it's not sufficient to just delete features to speed up a language. You have to change implementation, and very likely add entirely new internal APIs for the compiler. Creating a restricted subset of Python, and giving up compatibility with ordinary Python, is certainly an opinion. That's what Facebook did with their version of PHP. But its not the only approach. > A couple more quotes from the article: > >> It should be possible to define a subset of the Python language, >> uninspiredly dubbed “TurboPython”, that excludes those features that >> stand in the way of high-performance JIT execution (or compilation). >> Not using some of these features coincides with good design practices, >> so it doesn’t necessarily have to be all bad. > ... >> Since TurboPython is a subset of Python, it will also run on Python >> interpreters, albeit slower. > > Both of these imply that the standard library of TurboPython is > *exactly* the standard library of CPython, No. It doesn't say anything about the standard library. Maybe TurboPython has no standard library at all. The library is independent of the interpreter, and until somebody actually puts the effort in of writing it (or copying it from one repo to another), we are equally justified in saying any of: - TurboPython's std lib will have 100% functional compatibility with Python, only the implementation may change; - TurboPython has no std lib, it only has the built-in types and modules, if you want more, you can port it yourself; - TurboPython's std lib is a subset of the Python std lib, just as TurboPython itself is a subset of Python; - TurboPython's std lib is a MILLION TIMES BETTER than Python's. Since TurboPython doesn't exist, any of those statements are equally true. But in a *practical* sense, for our mythical/hypothetical TurboPython to have a chance at going mainstream, it needs a record/struct type, which in Python is namedtuple. That does not necessarily mean it needs to exec() arbitrary code. It just needs a way to create classes dynamically. Even Java can do that. http://stackoverflow.com/questions/2320404/ > minus the bits that aren't > supported. We just cut a few of those nasty dynamic features out of the > language, and voila! it becomes faster. That's exactly what I'm talking ab
Re: Python and the need for speed
On 11/04/2017 00:33, Chris Angelico wrote: If he does, it might be the final thing that gets him banned from the mailing list. A meta-note, since I happen to have seen this email come up. I don't know about the other list moderators, but I don't personally follow every sprawling thread and post on the look-out for offensive behaviour. Can I suggest, if anyone believes that there is a case for suspending someone from the list, that they email the List Owner whose address is at the bottom of: https://mail.python.org/mailman/listinfo/python-list and point out the behaviour they believe merits suspension or a warning or whatever. We can then confer between ourselves and decide what action to take. Thanks TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, Apr 11, 2017 at 6:26 PM, Tim Golden wrote: > On 11/04/2017 00:33, Chris Angelico wrote: >> >> If he does, it might be the final thing that gets him banned from the >> mailing list. > > > A meta-note, since I happen to have seen this email come up. > > I don't know about the other list moderators, but I don't personally follow > every sprawling thread and post on the look-out for offensive behaviour. Can > I suggest, if anyone believes that there is a case for suspending someone > from the list, that they email the List Owner whose address is at the bottom > of: > > https://mail.python.org/mailman/listinfo/python-list > > and point out the behaviour they believe merits suspension or a warning or > whatever. We can then confer between ourselves and decide what action to > take. > Thanks. At this stage, I was still at the "ask the poster himself to kindly refrain from being offensive", but yes, that would be the next step. (The post you're quoting is my tongue-in-cheek response to another poster's tongue-in-cheek comment poking fun at my precise language, which is exactly how this list behaves.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 9:26:14 AM UTC+1, Tim Golden wrote: > On 11/04/2017 00:33, Chris Angelico wrote: > > If he does, it might be the final thing that gets him banned from the > > mailing list. > > A meta-note, since I happen to have seen this email come up. > > I don't know about the other list moderators, but I don't personally > follow every sprawling thread and post on the look-out for offensive > behaviour. Can I suggest, if anyone believes that there is a case for > suspending someone from the list, that they email the List Owner whose > address is at the bottom of: > >https://mail.python.org/mailman/listinfo/python-list > > and point out the behaviour they believe merits suspension or a warning > or whatever. We can then confer between ourselves and decide what action > to take. > > Thanks > > TJG While we're at it how do we go about changing this https://www.python.org/community/lists/ which states that "comp.lang.python is a high-volume Usenet open (not moderated) newsgroup for general discussions and questions about Python."? Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
(Picking up one small part of your email; for the most part, I believe
we are in belligerent agreement.)
On Tue, Apr 11, 2017 at 6:19 PM, Steven D'Aprano wrote:
> Are you aware that literal_eval is *not* the same code that the Python
> interpreter uses for evaluating literals? They are kept in sync manually,
> or not kept in sync as the case may be.
Yes, I am; however, literal_eval starts by compiling to AST. (At
least, it does in current versions. I don't know about older
CPythons.) That means that, unless it gets completely rewritten, it
still gets *for free* all changes to the parsing of source to AST. For
example:
rosuav@sikorsky:~$ python3.5 -c "import ast;
print(ast.literal_eval('1_234_567'))"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/ast.py", line 46, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
File "/usr/lib/python3.5/ast.py", line 35, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "", line 1
1_234_567
^
SyntaxError: unexpected EOF while parsing
rosuav@sikorsky:~$ python3.6 -c "import ast;
print(ast.literal_eval('1_234_567'))"
1234567
Did literal_eval get changed in 3.6 to add support for this? Nope. It
just hands the string of text to the compiler and says "give me an
AST", and then does its whitelisted walk on that. That's a pretty huge
slab of work that would have to be redone if compile() were removed
from the language. Yes, brand new language features (eg f-strings)
have to be considered and either accepted or rejected, and yes,
literal_eval does have some definitions of "literal" that aren't atoms
(eg complex numbers), necessitating some slightly more complicated
rules - but they're all derived from the AST.
That's why a "no-runtime-compilation-allowed" Python has to either
lose or manually reimplement this. I very much doubt that CPython
upstream is interested in a patch to literal_eval to make it not use
compile - it makes it slower, larger, and more work to maintain,
merely in order to remove a dependency on something that's a core
feature. Ergo TurboPython would need to be the one maintaining this
alternate literal_eval, adding significantly to the initial _and_
ongoing work of the project.
And that's why I said that removing compile() would mean that
ast.literal_eval() would go.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11 08:19:31 +, Steven D'Aprano said: On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote: When people talk about making a restricted optimizable subset of Python, the implication (if not the explicit declaration) is that it's done strictly by removing, not by rewriting. Maybe *some* people have a naive, if not foolish, idea that all you need to do to speed up CPython is to go through the C code and hit delete over any functions you don't want. But that's hardly a technique that is going to work: not only will you break features, but merely removing code doesn't magically make the rest of the code base faster. At the very least, you have to re-write the code that depends on the features you have just removed. If we're going to talk about speeding up Python, we ought to talk about *serious* approaches to the problem, not the musing of random, ignorant bloggers and other naive commentators. Hey! This random, ignorant blogger has feelings too! :-) I don't know much about interpreter or compiler design, but I never claimed that speeding up CPython would simply be a matter of deleting some code. I merely suggested that approaches different from PyPy and other JIT compilers should be explored, since I do not feel that these projects are delivering satisfactory results. I am glad to see it got this discussion started, at the very least. some are actively maintained and used in production by many people (cython, PyPy). Are there any statistics on PyPy usage? I'm not convinced it is being used widely. As far as I can tell, it really is only useful for server applications because of the long JIT warm-up time. The Python ecosystem is actually quite healthy, if you need to speed up code there are lots of solutions, and some of them are even good solutions. There seem to be no solutions for my use case (rinohtype). DropBox and Google seem to agree that there are no good solutions, since they are moving to Go. Nevertheless, it is interesting to discuss whether or not any of these features will go mainstream or make it into CPython. Indeed! I initially wanted to include the following in the article, but decided it would be too controversial. But now that I've been exposed as an ignorant and naive blogger, I might as well share these thoughts. I have the feeling that a faster Python will never materialise unless the CPython core developers make performance a high priority. I understand that high performance was never a goal in CPython development (and Python language design!), but recent events (DropBox, Google) might help to reconsider that standpoint. Here's a wild idea: consider Python 3 feature-complete. Similar to how Python 3 cleaned up the unicode and other warts of Python 2, Python 4 could clean up the performance warts, but retaining the "soul" of the language. But that last part is a diffucult one, because it would lead to endless discussions of what would still be Python. So it's better to define an official "TurboPython" subset. This would also ensure backwards compatibility, but of course complicate the implementation. But who am I (or anyone) to suggest what the CPython core developers should do? I can only supply food for thought. Best regards, Brecht -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 11/04/2017 09:19, Steven D'Aprano wrote:
On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote:
When people talk about making a restricted optimizable subset of Python,
the implication (if not the explicit declaration) is that it's done
strictly by removing, not by rewriting.
Maybe *some* people have a naive, if not foolish, idea that all you need
to do to speed up CPython is to go through the C code and hit delete over
any functions you don't want. But that's hardly a technique that is going
to work: not only will you break features, but merely removing code
doesn't magically make the rest of the code base faster.
At the very least, you have to re-write the code that depends on the
features you have just removed.
If we're going to talk about speeding up Python, we ought to talk about
*serious* approaches to the problem, not the musing of random, ignorant
bloggers and other naive commentators. So let's look at what the experts
have done:
PyPy: a complete re-write, with a completely different approach (JIT
compilation).
A massively complicated approach, that not many fully understand. It can
give some good results, but it's no longer executing byte-code.
(Yet /I/ can get good performance, that can often match pypy, and still
be executing a byte-code at a time. But that's because the language is
smaller and less dynamic.)
WPython (alas, now more or less abandoned): a complete re-write of the
virtual machine, using 16-bit "wordcodes" instead of 8 bit "bytecodes",
nevertheless this enabled a lot of good optimizations:
http://repository.root-me.org/Programmation/Python/EN%20-%20Beyond%
20python%20bytecode.pdf
Yes, tightening up some bytecodes. But with limited results (I think up
to 2x as fast based on their results).
Most of the projects you've listed work with the language as it is; they
do the best they can with what's already there.
Removing stuff from the language could help, but that is not an option,
unless you call it Python 4 and break all compatibility. At the moment,
with:
def fn(): print("Yes")
exec(s)
fn()
You can't tell if that fn call will print Yes, No, or do anything else,
because the exec() could have redefined it.
/Adding/ things to the language might have to the way forward, but it's
already groaning under the weight of add-ons. And you don't want a
feature that adds clutter that is only there for performance hints.
Well, a little clutter might be OK:
constant pi = 3.14159
Now 'pi' is /guaranteed/ to be the value you've specified (unlike
math.pi). That sort of thing can help optimisation /and/ readability.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: strange behaviour when writing a large amount of data on stdout
On Thursday, November 24, 2005 at 8:06:34 PM UTC+5:30, [email protected] wrote: > Bengt Richter wrote: > > Depends on what you run ;-) Maybe how many times buggy apps die in unusual > > ways. > > Or worse, buggy drivers. Your car might have bad 4-wheel drive that you > > never used, > > so you thought your car reliable ;-) > > > Sure, no casual toys are allowed. But this is true in general, whatever > OS it is. Hi , I do get the same error while executing python script (test script written robotframework - issue while capturing the screenshot ) Pleas find below error: Opening browser 'firefox' to base url 'https://onbep.agra.com/ze' [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: No browser is open | FAIL | IOError: [Errno 12] Not enough space My Infra detais : Win10 64 bit , 4GB RAM Any thing to be set in OS level ? Regards, LnT -- https://mail.python.org/mailman/listinfo/python-list
IOError: [Errno 12] Not enough space
Hi, version information python 27 java version "1.8.0_111" OS -Win 10 , 64Bit , 8GB RAM , 60GB HD executing python test script (robotframework) for a we bapplication Application url will be invoked by Firefox 38.0 Please find below log: Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: No browser is open | FAIL | IOError: [Errno 12] Not enough space I have cleared %TEMP% and reran the script. But still I see this. Could you please show me some Light ? Regards, LnT -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, 11 Apr 2017 07:00 pm, [email protected] wrote: > While we're at it how do we go about changing this > https://www.python.org/community/lists/ which states that > "comp.lang.python is a high-volume Usenet open (not moderated) newsgroup > for general discussions and questions about Python."? Change it to what, and why? As it is, it is correct. comp.lang.python is a high-volume Usenet unmoderated newsgroup for general discussions related to Python. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Temporary variables in list comprehensions
Vincent Vande Vyvre writes: > final = [(x, y+1) for x, y in zip(e, e)] final = [(x, x+1) for x in e] -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, 11 Apr 2017 07:11 pm, Chris Angelico wrote: > (Picking up one small part of your email; for the most part, I believe > we are in belligerent agreement.) :-) [...] > Did literal_eval get changed in 3.6 to add support for this? Nope. It > just hands the string of text to the compiler and says "give me an > AST", and then does its whitelisted walk on that. That's a pretty huge > slab of work that would have to be redone if compile() were removed > from the language. Not necessarily. You are still focused on *one specific implementation*, where literal_eval() is written in pure Python and calls the compile() built-in function. But that's not the only way to solve the problem. That's implementation, not interface. Here's another implementation: Suppose the Python compiler/interpreter included a parser that takes a string and compiles it to an AST. Pretty much every modern language has that, the days of BASIC interpreters that loop over lines of source code executing them as they go are long gone. So we need something to parse source to AST, just so the interpreter can interpret the source code. It just needs to exist. It doesn't have to be a public part of the language. So the interpreter relies on this internal "compile-to-AST". And literal_eval() can do exactly the same thing, if it is part of the interpreter. There's no reason why literal_eval() must be written in pure Python. It can be implemented any way you like, anywhere you like. Obviously this requires hooking literal_eval() into the interpreter as a built-in command. Maybe its even a single op-code in the (Turbo)Python virtual machine. We can make the op-codes as complex as we need! The existing op-codes range from the incredibly simple: POP_TOP Removes the top-of-stack (TOS) item. to quite complex: SETUP_WITH(delta) This opcode performs several operations before a with block starts. First, it loads __exit__() from the context manager and pushes it onto the stack for later use by WITH_CLEANUP. Then, __enter__() is called, and a finally block pointing to delta is pushed. Finally, the result of calling the enter method is pushed onto the stack. The next opcode will either ignore it (POP_TOP), or store it in (a) variable(s) (STORE_FAST, STORE_NAME, or UNPACK_SEQUENCE). https://docs.python.org/3/library/dis.html so there is absolutely no reason why literal_eval() cannot be a built-in function that uses the exact same parser as the interpreter, if that's important to you. Just because literal_eval() has access to the interpreter's parser, doesn't mean that there has to be a compile() builtin that can handle arbitrary source code. > That's why a "no-runtime-compilation-allowed" Python has to either > lose or manually reimplement this. I very much doubt that CPython > upstream is interested in a patch to literal_eval to make it not use > compile - it makes it slower, larger, and more work to maintain, > merely in order to remove a dependency on something that's a core > feature. Nobody is talking about CPython removing the compile() builtin. But if TurboPython wants to remove the compile() builtin, AND it becomes super-popular -- maybe Google and Facebook and Apple decide to throw away Go, PHP and Swift and move exclusively to Python *wink* -- then perhaps Python 4.5 or 5.2 will actually include a switch to disable compile(), exec() and eval() and enable a bunch of optimizations. Anything is possible, if enough people want it. *If*. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
django user images
hello
if i want to create a query in django with to take all images and preview that
list in html like easy work.
but if want in html page preview only the personal images where login user what
changes i need in my code ?
model.py
class MyModel(models.Model):
user = models.ForeignKey(User, unique=True)
photo = models.ImageField(upload_to='images')
views.py
class BasicUploadView(request):
photos_list = Photo.objects.all()
return render(request, 'photos/basic_upload/index.html', {'photos':
photos_list})
html page :
{% for photo in photos %}
{{ photo.file.name }}
{% endfor %}
--
https://mail.python.org/mailman/listinfo/python-list
Need webFOCUS Business Intelligence Developer
Hi , Greetings from Niche software solutions . We have a new job opening for the following position, please find the job description below.Please share your most recent updated resume to move forward into the process, If you are not interested please let me know if you have any friends or colleagues that who would be interested in this position Job Title: webFOCUS Business Intelligence Developer Location : Pittsburgh, PA Duration : 6 Months Interview Mode – Phone interview is a must & Skype or face to face interview possible to follow Need 3 to 5 years' experience in the design, administration, programming, and support of an enterprise reporting environment using the WebFOCUS business intelligence platform Job Description: .Bachelor's degree in Computer Science, Information Systems, or related discipline preferred; equivalent experience is acceptable .Develop and maintain reporting modules utilizing the developer and reporting tool kits within WebFOCUS .Oracle SQL coding skills with particular attention given to detail and accuracy .Experience in Java, JavaScript, jQuery, AJAX, HTML, XML, JSON, CSS and Visual Basic is preferred .Utilize the administrative tools within WebFOCUS to provide end users with ad hoc and personalized reporting while maintaining a secure and cohesive environment. .Thorough understanding of the WebFOCUS product architecture Best Regards, Jack Stutter Niche Soft Solutions INC. Direct: +1503-536-2043 Email id: [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Need webFOCUS Business Intelligence Developer
Hi , Greetings from Niche software solutions . We have a new job opening for the following position, please find the job description below.Please share your most recent updated resume to move forward into the process, If you are not interested please let me know if you have any friends or colleagues that who would be interested in this position Job Title: webFOCUS Business Intelligence Developer Location : Pittsburgh, PA Duration : 6 Months Interview Mode – Phone interview is a must & Skype or face to face interview possible to follow Need 3 to 5 years' experience in the design, administration, programming, and support of an enterprise reporting environment using the WebFOCUS business intelligence platform Job Description: .Bachelor's degree in Computer Science, Information Systems, or related discipline preferred; equivalent experience is acceptable .Develop and maintain reporting modules utilizing the developer and reporting tool kits within WebFOCUS .Oracle SQL coding skills with particular attention given to detail and accuracy .Experience in Java, JavaScript, jQuery, AJAX, HTML, XML, JSON, CSS and Visual Basic is preferred .Utilize the administrative tools within WebFOCUS to provide end users with ad hoc and personalized reporting while maintaining a secure and cohesive environment. .Thorough understanding of the WebFOCUS product architecture Best Regards, Jack Stutter Niche Soft Solutions INC. Direct: +1503-536-2043 Email id: [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: > On 2017-04-11 08:19:31 +, Steven D'Aprano said: >> If we're going to talk about speeding up Python, we ought to talk about >> *serious* approaches to the problem, not the musing of random, ignorant >> bloggers and other naive commentators. > > Hey! This random, ignorant blogger has feelings too! :-) Hi, and welcome! Sorry, I wasn't *specifically* referring to you, except in the sense that you aren't a compiler expert. The truth is, all of us in this discussion -- including me -- are "random, ignorant commentators". I don't believe that any of us are experts at writing compilers. Bart is a possible exception, for some definition of "expert" -- he claims to have written a quite fast, moderately dynamic language, but nobody else (that I know of) has used it. And no offence to Bart, but from his comments and questions on the list, I think it is fair to say that whatever knowledge he has on language design was probably state of the art thirty years ago. Bart sometimes expresses surprise and confusion over concepts which are common in languages like Javascript, Python, Perl, Ruby etc. These are not young languages! Python is over 20 years old, Perl is even older. So I suspect Bart's knowledge is probably from the 70s or 80s? That doesn't mean it is irrelevant. But it does mean that there's a lot he is unfamiliar with. > I don't know much about interpreter or compiler design, but I never > claimed that speeding up CPython would simply be a matter of deleting > some code. No, that seems to be Chris' interpretation. My interpretation is that it is "common sense" that it needs more than just pressing delete on a few features to speed up an interpreter, and therefore for casual discussion (as in a blog post) it goes without saying that removing features is only the first step, not the only step. > I merely suggested that approaches different from PyPy and > other JIT compilers should be explored, since I do not feel that these > projects are delivering satisfactory results. I am glad to see it got > this discussion started, at the very least. I agree! I think that its wonderful that people and companies are willing to invest time and money exploring the options. But I also think that while making Python faster is a good goal to have, it seems that for most people, and most companies, it isn't their priority. For a company, if it costs $30,000 to build an experimental TurboPython which may or may not solve your problems, and $40,000 to migrate to Go or Javascript or something which definitely will (you hope...) solve your problem, why wouldn't you do so? Well, maybe because your development costs for using Go will be higher. Maybe. But will they be higher than your maintenance costs for TurboPython? >> some are actively maintained and >> used in production by many people (cython, PyPy). > > Are there any statistics on PyPy usage? I'm not convinced it is being > used widely. As far as I can tell, it really is only useful for server > applications because of the long JIT warm-up time. You are correct: PyPy is not designed for short scripts and other applications. The JIT warm-up is significant. >> The Python ecosystem is actually quite healthy, if you need to speed up >> code there are lots of solutions, and some of them are even good >> solutions. > > There seem to be no solutions for my use case (rinohtype). Have you tried Nuitka? > DropBox and > Google seem to agree that there are no good solutions, since they are > moving to Go. That's a good solution! Maybe we should be writing extensions in Go, instead of C. Or for maths-heavy work, using extensions written in Julia. While there are advantages to using a single language, it is silly to artificially limit yourself to a single language if you don't need to. Python started life as a "glue language" for C and Fortran, and there are projects and implementations like Jython for example that specifically exist so people can call Java libraries from Python. A hybrid code base where the heavy lifting is done in a fast but annoying language, and the glue and infrastructure is written in Python, is a good solution for many problems. >> Nevertheless, it is interesting to discuss whether or not any >> of these features will go mainstream or make it into CPython. > > Indeed! I initially wanted to include the following in the article, but > decided it would be too controversial. But now that I've been exposed > as an ignorant and naive blogger, I might as well share these thoughts. > > I have the feeling that a faster Python will never materialise unless > the CPython core developers make performance a high priority. I think you are both right and wrong. You are right in the sense that none of the companies exploring Python optimizers have wanted to carry the maintenance burden themselves. Their aim is to prove the concept, then push it back into CPython and have the core devs main
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 2:32:34 PM UTC+1, Steve D'Aprano wrote: > On Tue, 11 Apr 2017 07:00 pm, breamoreboy wrote: > > > While we're at it how do we go about changing this > > https://www.python.org/community/lists/ which states that > > "comp.lang.python is a high-volume Usenet open (not moderated) newsgroup > > for general discussions and questions about Python."? > > Change it to what, and why? > > As it is, it is correct. comp.lang.python is a high-volume Usenet > unmoderated newsgroup for general discussions related to Python. > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. So we should be welcoming back the RUE who I see is still spewing his bile? What exactly do Tim Golden and Ethan Furman moderate on? You can be pedantic about what is a newsgroup, or mailing list, or whatever, but to me they're one and the same thing. Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
ldap search and Tuple
Dear,
I am writing to ask you which is the most profitable way, to get the last
uidNumber.
With ldap search create a tuple with a lot of values as follows:
('dc=xxx,dc=xxx,dc=xx', {'uid': ['pepe'], 'objectClass': ['inetOrgPerson',
'mailUser', 'shadowAccount', 'amavisAccount', 'shell', 'wiki'],'uidNumber':
['']}]
I hope you can guide me and suggest any method.
Thank you
--
https://mail.python.org/mailman/listinfo/python-list
Mcidas format
Hi, I have some data from the https://ghrc.nsstc.nasa.gov/hydro/search.pl. These data are the Infrared Global Geostationary Composite and the format of this is data is Mcidas. Please anyone know how I can read this data using Python. Thanks, Conrado -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
Steve D'Aprano wrote: > On Tue, 11 Apr 2017 12:50 am, Lew Pitcher wrote: > >> David Shi wrote: >> >>> In the data set, pound sign escape appears: >>> u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000', > > That looks like David is using Python 2. > >>> When using table.to_csv after importing pandas as pd, an error message >>> persists as follows: UnicodeEncodeError: 'ascii' codec can't encode >>> character u'\xa3' in position 0: ordinal not in range(128) >> >> There is no "pound sign" in ASCII[1]. Try changing your target encoding >> to something other than ASCII. > > Please don't encourage the use of old legacy encodings. I wonder if you actually read my reply. What in "Try changing your target encoding to something other than ASCII" is encouragement to use "old legacy encodings"? > In 2017, unless you are reading from old legacy files created using a > non-Unicode encoding, you should just use UTF-8. Thanks for your opinion. My opinion differs. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Moderating the list [was: Python and the need for speed]
On 11/04/2017 15:20, [email protected] wrote: On Tuesday, April 11, 2017 at 2:32:34 PM UTC+1, Steve D'Aprano wrote: On Tue, 11 Apr 2017 07:00 pm, breamoreboy wrote: While we're at it how do we go about changing this https://www.python.org/community/lists/ which states that "comp.lang.python is a high-volume Usenet open (not moderated) newsgroup for general discussions and questions about Python."? Change it to what, and why? As it is, it is correct. comp.lang.python is a high-volume Usenet unmoderated newsgroup for general discussions related to Python. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. What exactly do Tim Golden and Ethan Furman moderate on? We (and the other moderators) exactly moderate the mailing list. I have no authority over the newsgroup, and I don't know who does. You can be pedantic about what is a newsgroup, or mailing list, or whatever, but to me they're one and the same thing. This is something which can cause contention as people from either side (mailing list <-> newsgroup) can be completely unaware that they're being copied to the other. However, it's simply a technical fact: the thing which we moderate is the mailing list. We can control which posts make it through from the newsgroup by blocking them at the gateway. But the posts will continue to appear on comp.lang.python which is, as the description says, unmoderated. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On Wed, Apr 12, 2017 at 1:24 AM, Lew Pitcher wrote: > > What in "Try changing your target encoding to something other than ASCII" is > encouragement to use "old legacy encodings"? > >> In 2017, unless you are reading from old legacy files created using a >> non-Unicode encoding, you should just use UTF-8. > > Thanks for your opinion. My opinion differs. So what encoding *do* you recommend, and why is it better than UTF-8? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 11/04/2017 15:56, Steve D'Aprano wrote: The truth is, all of us in this discussion -- including me -- are "random, ignorant commentators". I don't believe that any of us are experts at writing compilers. Bart is a possible exception, for some definition of "expert" -- he claims to have written a quite fast, moderately dynamic language, but nobody else (that I know of) has used it. And no offence to Bart, but from his comments and questions on the list, I think it is fair to say that whatever knowledge he has on language design was probably state of the art thirty years ago. Bart sometimes expresses surprise and confusion over concepts which are common in languages like Javascript, Python, Perl, Ruby etc. These are not young languages! Python is over 20 years old, Perl is even older. So I suspect Bart's knowledge is probably from the 70s or 80s? Yes, about then. But it means I have a lot of experience getting this stuff to work briskly on limited hardware, and I can identify bloat and inefficiency. (My latest project is a C compiler, which currently generates asm source (later it will run from source like Python). But it takes 50ms to process a 30Kloc file that then takes 90 seconds, nearly 2000 times longer, to assemble into .obj. That sounds like there's something wrong to me with that assembler. So I think I can question the efficiency of other people's software. My experience may be out of date but that 50ms - half of which is generating that damned asm source - was from yesterday!) However, when the obstacle is a particular language design then the options are more limited. I think CPython does remarkably well given the language. And the official byte-code (which can do with tweaking as that Wpython project demonstrated). -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Mcidas format
Can you provide a sample of the data and its format, please? -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
Chris Angelico wrote: > On Wed, Apr 12, 2017 at 1:24 AM, Lew Pitcher > wrote: >> >> What in "Try changing your target encoding to something other than ASCII" >> is encouragement to use "old legacy encodings"? >> >>> In 2017, unless you are reading from old legacy files created using a >>> non-Unicode encoding, you should just use UTF-8. >> >> Thanks for your opinion. My opinion differs. > > So what encoding *do* you recommend, and why is it better than UTF-8? I recommend whatever encoding is appropriate for the output. That's not up to you or me to decide; that's a question that only the OP can answer. (Imagine, python on an IBM Zseries running ZOS; the "native" characterset is one of the EBCDIC variants. Would UTF-8 be a better choice there? ) -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On Wed, 12 Apr 2017 01:24 am, Lew Pitcher wrote: [...] >>> There is no "pound sign" in ASCII[1]. Try changing your target encoding >>> to something other than ASCII. >> >> Please don't encourage the use of old legacy encodings. > > I wonder if you actually read my reply. Of course I did. > What in "Try changing your target encoding to something other than ASCII" > is encouragement to use "old legacy encodings"? The fact that "something other than ASCII" includes dozens of old legacy encodings, including the most obvious one for Western Europeans coming from a Windows environment: Latin-1. There are only three practical choices for text: ASCII, Unicode, and legacy encodings (or "code pages", as many people know them). TRON is effectively only available in Japan, and even there hardly anyone uses it. (And besides, Python doesn't support TRON.) You've (rightly) eliminated ASCII, as the pound sign isn't available. Python doesn't support TRON, so your instruction to the OP is logically equivalent to "use Unicode or a legacy encoding". Its the second half of that which I am objecting to. >> In 2017, unless you are reading from old legacy files created using a >> non-Unicode encoding, you should just use UTF-8. > > Thanks for your opinion. My opinion differs. What would you suggest then, if not UTF-8? My personal favourite legacy encoding is MacRoman, but I wouldn't recommend anyone use it except to interoperate with legacy Mac applications and/or data from the 80s and 90s. What's your recommendation? "Anything but ASCII"? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, 12 Apr 2017 12:20 am, [email protected] wrote: > So we should be welcoming back the RUE who I see is still spewing his > bile? The only one I see "spewing bile" is you. wxjmfauth's ignorant, stupid opinions about Python's handling of Unicode are just silly. Why are you taking it so personally? There's no need to invent a sarcastic name for him, or to falsely accuse him of "spewing bile", or to keep going on and on and on about him every time he pops his head up. > You can be pedantic about what is a newsgroup, or mailing list, or > whatever, but to me they're one and the same thing. Like wxjmfauth, we're all entitled to hold whatever ignorant and silly opinions we like, there's no law against it. (Acting on, or expressing, those opinions may be treated differently.) But the fact is that the mailing list and newsgroup are NOT one and the same thing, and never will be. This is a true fact, not a false fact. They cannot be the same thing: they use different technologies, with different organising principles, and are controlled by different people. The mailing list is controlled by the PSF; the newsgroup is not. (It's arguable whether *anyone* controls the newsgroup, except in the sense that individual system administrators on individual News servers have some power over what passes through their own server. But that's it.) http://www.ou.edu/research/electron/internet/use-faq.htm I don't know why you're so uptight over jmf, but like it or not, there's nothing you can do to keep him of Usenet. Deal with it. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
On 11-4-2017 14:30, LnT wrote: > Hi, > > version information > > python 27 Please be more precise, there is no Python 27. (Yeah it is clear you meant 2.7 but still) > java version "1.8.0_111" That should not be relevant > OS -Win 10 , 64Bit , 8GB RAM , 60GB HD 60 GB is not a lot of space for windows... > executing python test script (robotframework) for a we bapplication > Application url will be invoked by Firefox 38.0 > > Please find below log: > > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: No > browser is open > | FAIL | > IOError: [Errno 12] Not enough space > That's not much information. Is there really not anything else in the log? Like a traceback, that may give some clues what the application is doing when it is running out of disk space? > > I have cleared %TEMP% and reran the script. > But still I see this. > > Could you please show me some Light ? > Based on the info you provided, the only solution I can think of is: free more space. Something in your application is trying to write stuff and there's simply not enough space on the disk to do so. -i -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On Wed, Apr 12, 2017 at 2:23 AM, Lew Pitcher wrote: > Chris Angelico wrote: > >> On Wed, Apr 12, 2017 at 1:24 AM, Lew Pitcher >> wrote: >>> >>> What in "Try changing your target encoding to something other than ASCII" >>> is encouragement to use "old legacy encodings"? >>> In 2017, unless you are reading from old legacy files created using a non-Unicode encoding, you should just use UTF-8. >>> >>> Thanks for your opinion. My opinion differs. >> >> So what encoding *do* you recommend, and why is it better than UTF-8? > > I recommend whatever encoding is appropriate for the output. That's not up > to you or me to decide; that's a question that only the OP can answer. > > (Imagine, python on an IBM Zseries running ZOS; the "native" characterset is > one of the EBCDIC variants. Would UTF-8 be a better choice there? ) So if the OP needed to print out a number, would you take a similarly spineless approach and say that only the OP can decide what numeric base to use? Does every fledgeling programmer need to understand about archaic systems where you needed to use BCD for your numbers? EBCDIC derives from BCD, where a single decimal digit was encoded in four bits... and I'm sure you could name systems even less popular, used on important systems back in the 1960s or so. Does a modern Python programmer need to look through all of those possible ways to represent numbers? NO. Today's programmer should need to know about very few ways to represent numbers, in priority order: 1) Decimal digits represented in ASCII 2) Packed binary, network byte order 3) Packed binary, little-endian. A new programmer shouldn't need to worry about anything other than decimal digits, in fact. Of course other systems do exist, like the MIDI "variable length integer" that packs seven bits into a byte and then uses the high bit as a continuation marker; or IEEE 80-bit floating point, or a multi-limb format like GMP uses, but until you actually need to work with it, you don't need to know about it. Just use the one most obvious encoding. UTF-8 for all text. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mcidas format
On 4/11/2017 7:57 AM, [email protected] wrote: I have some data from the https://ghrc.nsstc.nasa.gov/hydro/search.pl. These data are the Infrared Global Geostationary Composite and the format of this is data is Mcidas. Please anyone know how I can read this data using Python. Search 'python mcidas'. Google's first few responses suggest two approaches: 1. Python interface to existing mcidas viewers. 2. Mcidas plugin for pillow (image manipulation package) that defines class McIdasImageFile(ImageFile.ImageFile) https://github.com/python-pillow/Pillow/blob/master/PIL/McIdasImagePlugin.py It reads and decodes the 256 byte header and defines attributes needed for pillow to read the data. It handles three different mcidas formats. There appears to be an mcidas user group. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Steven D'Aprano writes: > If we're going to talk about speeding up Python, we ought to talk about > *serious* approaches to the problem, not the musing of random, ignorant > bloggers and other naive commentators. So let's look at what the experts > have done: [list snipped] You might look at MicroPython too (micropython.org). A fairly complete Python 3 implementation with some ahead-of-time compiling, no fancy JIT. Completely breaks the Python C API though. Or you could look at the past 50 years(!) of Lisp and Scheme compilers some of which produce very good code, ask what Python features can't be straightforwardly transliterated into Lisp to use those compilers, then ask whether those features are really important to the average Python user. I don't even think eval is an obstacle. Lots of Lisp systems implement eval by handing expression off to the compiler and then running the compiled code, maybe with a bit of caching like Python and compiled regexps. I remember thinking PyPy made a mistake in trying to preserve all of Python's dynamism, and Python 3 made a mistake in trying to preserve so much compatibility with Python 2 while still breaking minor things. I thought PyPy should have been "TurboPython" that broke lots more Python 2 stuff than Python 3 did, but was as you say maybe 20x faster. Then Python 3 could have been skipped. For a while I thought something like that could become Python 4, but the readout of Python 3 seems to be that its slow uptake came from those minor breaks, so Python 4 won't have even the slightest incompatibility with Python 3 code. I still do my everyday stuff in Python and I'd like to get more conversant with stuff like numpy, but it feels like an old-fashioned language these days. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On Wed, 12 Apr 2017 02:23 am, Lew Pitcher wrote: > I recommend whatever encoding is appropriate for the output. There are multiple encodings that are appropriate for ASCII + pound sign. How should the OP choose between them without guidance? If he understood the issue well enough to make an informed decision, he wouldn't have needed to ask for help. > That's not up > to you or me to decide; that's a question that only the OP can answer. Nobody is asking you to *decide*. But you can make a recommendation. Do you really think that the OP is capable of making an informed decision about this issue on his own? If he was, he wouldn't have needed to ask for help solving this problem in the first place. If you're going to help, actually *help*, and don't just pretend to help: "Hi, I'm a stranger in town and I'm trying to get to the post office. What's the best way for me to get there please?" "Well, that depends on whether you're flying the Space Shuttle, travelling by sailing ship, dog sled, or advanced alien hyperdrive. You should take whatever route is most appropriate for your transportation. You're welcome." I'm sorry to be so negative when you're only trying to be helpful, but I too have been on the receiving end of poor-quality "advice" that leaves me just as much in the dark as before I asked the question, so I'm quite sensitive to it. "What should I do here?" "Do whatever you see fit." (I'm not specifically referring to this community, just making a general observation.) > (Imagine, python on an IBM Zseries running ZOS; I can imagine many unlikely things that have come to pass, but that's not one of them. The OP is using Pandas, which requires Python 2.7 or better. https://pypi.python.org/pypi/pandas There is an unofficial, unmaintained(?), third-party port of Python 2.4 to Z/OS, which appears to have had no attention for more than a decade. http://www.teaser.fr/~jymengant/mvspython/mvsPythonPort.html I suppose it is just barely within the realm of possibility that the OP has hacked together his own port of Python 2.7 and Pandas to Z/OS. If so, he'd have already had to deal with some much bigger problems relating to ASCII versus EBCDIC, and if he managed to solve that, it's unlikely that he'd be puzzled by a pound sign in his data. But... even if I grant you your scenario that he's running on Big Iron, that is irrelevant! Using Unicode for his data files is still the better idea. > the "native" characterset > is one of the EBCDIC variants. Would UTF-8 be a better choice there? ) Yes it would. The OP is using Unicode strings so regardless of the OS's native character set, it is better to use Unicode rather than some 8-bit encoding. Today the OP needs a pound sign. Tomorrow he may need a Greek Σ, yen sign, CJK ideograph, or Arabic character. Possibly all in the same document. Using legacy encodings, whether based on EBCDIC or ASCII, should be avoided. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11, Paul Rubin wrote: > You might look at MicroPython too (micropython.org). A fairly complete > Python 3 implementation with some ahead-of-time compiling, no fancy > JIT. Completely breaks the Python C API though. I didn't know there was such a thing as "The Python C API". Or do you just mean that the C API is different than that chosen by the developers of https://github.com/python/cpython? -- Grant Edwards grant.b.edwardsYow! I'm DESPONDENT ... I at hope there's something gmail.comDEEP-FRIED under this miniature DOMED STADIUM ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, Apr 12, 2017 at 4:42 AM, Grant Edwards wrote: > On 2017-04-11, Paul Rubin wrote: > >> You might look at MicroPython too (micropython.org). A fairly complete >> Python 3 implementation with some ahead-of-time compiling, no fancy >> JIT. Completely breaks the Python C API though. > > I didn't know there was such a thing as "The Python C API". > > Or do you just mean that the C API is different than that chosen by > the developers of https://github.com/python/cpython? Do you mean this? https://docs.python.org/3/c-api/intro.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11, Chris Angelico wrote: > On Wed, Apr 12, 2017 at 4:42 AM, Grant Edwards > wrote: >> On 2017-04-11, Paul Rubin wrote: >> >>> You might look at MicroPython too (micropython.org). A fairly complete >>> Python 3 implementation with some ahead-of-time compiling, no fancy >>> JIT. Completely breaks the Python C API though. >> >> I didn't know there was such a thing as "The Python C API". >> >> Or do you just mean that the C API is different than that chosen by >> the developers of https://github.com/python/cpython? > > Do you mean this? > > https://docs.python.org/3/c-api/intro.html I think so. That's the C API for one particlar implementation of Python "CPython", right? There is no "Python" C API specified as part of the language definition is there? -- Grant Edwards grant.b.edwardsYow! LOOK!! Sullen at American teens wearing gmail.comMADRAS shorts and "Flock of Seagulls" HAIRCUTS! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, Apr 12, 2017 at 5:19 AM, Grant Edwards wrote: > On 2017-04-11, Chris Angelico wrote: >> On Wed, Apr 12, 2017 at 4:42 AM, Grant Edwards >> wrote: >>> On 2017-04-11, Paul Rubin wrote: >>> You might look at MicroPython too (micropython.org). A fairly complete Python 3 implementation with some ahead-of-time compiling, no fancy JIT. Completely breaks the Python C API though. >>> >>> I didn't know there was such a thing as "The Python C API". >>> >>> Or do you just mean that the C API is different than that chosen by >>> the developers of https://github.com/python/cpython? >> >> Do you mean this? >> >> https://docs.python.org/3/c-api/intro.html > > I think so. That's the C API for one particlar implementation of > Python "CPython", right? > > There is no "Python" C API specified as part of the language > definition is there? Oh, I see what you mean. That is indeed correct - there is no language-level API specification - but it's linguistically redundant to say "the CPython C API", so it's often not said that way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11, Chris Angelico wrote: >>> Do you mean this? >>> >>> https://docs.python.org/3/c-api/intro.html >> >> I think so. That's the C API for one particlar implementation of >> Python "CPython", right? >> >> There is no "Python" C API specified as part of the language >> definition is there? > > Oh, I see what you mean. > > That is indeed correct - there is no language-level API specification > - but it's linguistically redundant to say "the CPython C API", so > it's often not said that way. If there are now other Python implementations (e.g. MicroPython) with C APIs that differ from CPython, then it seems like it is no longer redundant to say "the CPython API". -- Grant Edwards grant.b.edwardsYow! I know how to do at SPECIAL EFFECTS!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, Apr 12, 2017 at 5:47 AM, Grant Edwards wrote: > > If there are now other Python implementations (e.g. MicroPython) with > C APIs that differ from CPython, then it seems like it is no longer > redundant to say "the CPython API". I don't think there are. They either implement (some subset of) the CPython API, or they're not in C (eg Jython), or they don't offer an extension API. I don't know of anything else that offers a C API. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
Hello, I tried finding the answer but even the lawyers in my town have no idea about it and searching the web leaved me puzzled. I am planning to make a software in python which will include libraries licensed under BSD- 3 clause. Can I sell this software under proprietary license and legally inhibit redistribution by users under my own license. Also if you know anyone who holds knowledge in this field then please do let me know.. Your response will be really helpful. Regards, Abhishek Kumar ᐧ -- https://mail.python.org/mailman/listinfo/python-list
Re: Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
On Wed, Apr 12, 2017 at 6:35 AM, Abhishek Kumar wrote: > I tried finding the answer but even the lawyers in my town have no idea > about it and searching the web leaved me puzzled. > I am planning to make a software in python which will include libraries > licensed under BSD- 3 clause. Can I sell this software under proprietary > license and legally inhibit redistribution by users under my own license. > Also if you know anyone who holds knowledge in this field then please do let > me know.. > Your response will be really helpful. Firstly, if you're simply writing a Python program, the license terms of the Python interpreter don't matter. Your code is completely independent, and you can closed-source it while still running it under Python itself. Similarly, if all you're doing with those BSD-licensed libraries is importing them, there's no problem there. Things become a bit more complicated if you're *distributing* the overall package - if you're creating a single installer that installs Python, these third-party libraries, and your proprietary software. If that bothers you, the easiest way is to simply provide installation instructions that say "install Python from python.org yada yada", or check with a lawyer about exactly how you're packaging everything up. But mainly, you don't have to worry too much about the license terms of the language interpreter, because you can run your code on a different interpreter perfectly easily. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 11 April 2017 at 16:56, Steve D'Aprano wrote: > On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: > >[...] > >> DropBox and >> Google seem to agree that there are no good solutions, since they are >> moving to Go. > > That's a good solution! Maybe we should be writing extensions in Go, instead > of C. Or for maths-heavy work, using extensions written in Julia. Just my curiosity, I've always been intersted in such question: are devs still writing extensions in C, I mean type in C code? Aren't they using some translator or IDE which at lest hides the brackets and semicolons? I personally don't have problems with understanding low-level concepts of programming, but I find it pretty hard to see through the mangroves of brackets, asterisks and Co. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
On Wednesday, 12 April 2017 02:23:53 UTC+5:30, Chris Angelico wrote: > On Wed, Apr 12, 2017 at 6:35 AM, Abhishek Kumar > wrote: > > I tried finding the answer but even the lawyers in my town have no idea > > about it and searching the web leaved me puzzled. > > I am planning to make a software in python which will include libraries > > licensed under BSD- 3 clause. Can I sell this software under proprietary > > license and legally inhibit redistribution by users under my own license. > > Also if you know anyone who holds knowledge in this field then please do > > let me know.. > > Your response will be really helpful. > > Firstly, if you're simply writing a Python program, the license terms > of the Python interpreter don't matter. Your code is completely > independent, and you can closed-source it while still running it under > Python itself. Similarly, if all you're doing with those BSD-licensed > libraries is importing them, there's no problem there. > > Things become a bit more complicated if you're *distributing* the > overall package - if you're creating a single installer that installs > Python, these third-party libraries, and your proprietary software. If > that bothers you, the easiest way is to simply provide installation > instructions that say "install Python from python.org yada yada", or > check with a lawyer about exactly how you're packaging everything up. > > But mainly, you don't have to worry too much about the license terms > of the language interpreter, because you can run your code on a > different interpreter perfectly easily. > > ChrisA thanks for your response I am planning to distribute as a stand alone package (fro windows .exe). Should I worry about the license in this case?! Like I mentioned lawyers in my town have little or no idea about open source .. regards, Abhishek -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11, Chris Angelico wrote: > On Wed, Apr 12, 2017 at 5:47 AM, Grant Edwards > wrote: >> >> If there are now other Python implementations (e.g. MicroPython) with >> C APIs that differ from CPython, then it seems like it is no longer >> redundant to say "the CPython API". > > I don't think there are. They either implement (some subset of) the > CPython API, or they're not in C (eg Jython), or they don't offer an > extension API. I don't know of anything else that offers a C API. Now I'm really confused. If micropython doesn't have a C API that differs from the CPython C API, then how does it "break the C API"? -- Grant Edwards grant.b.edwardsYow! I smell like a wet at reducing clinic on Columbus gmail.comDay! -- https://mail.python.org/mailman/listinfo/python-list
Re: Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
On Wed, Apr 12, 2017 at 7:03 AM, Abhishek Kumar wrote: > thanks for your response I am planning to distribute as a stand alone package > (fro windows .exe). Should I worry about the license in this case?! > Like I mentioned lawyers in my town have little or no idea about open source > .. Yes, in the sense that you should talk to a lawyer. It's going to depend on how clearly you separate your code from other people's code. You can get further advice from this list, but be aware that this is NOT binding legal advice. I am not a lawyer, nor are most of the people here, and even if one of us is, we're not _your_ lawyer and may not be in your jurisdiction. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On 2017-04-12 02:29, Steve D'Aprano wrote: > >> In 2017, unless you are reading from old legacy files created > >> using a non-Unicode encoding, you should just use UTF-8. > > > > Thanks for your opinion. My opinion differs. > > What would you suggest then, if not UTF-8? > > My personal favourite legacy encoding is MacRoman, but I wouldn't > recommend anyone use it except to interoperate with legacy Mac > applications and/or data from the 80s and 90s. > > What's your recommendation? "Anything but ASCII"? Heh, how about "Unicode as ASCII-compatible-Python-strings"? ;-) Got this from Peter Otten a while back in response to my request for functionality something like this. http://www.mail-archive.com/[email protected]/msg420100.html -tkc $ cat codecs_mynamereplace.py # -*- coding: utf-8 -*- import codecs import unicodedata try: codecs.namereplace_errors except AttributeError: print("using mynamereplace") def mynamereplace(exc): return u"".join( "\\N{%s}" % unicodedata.name(c) for c in exc.object[exc.start:exc.end] ), exc.end codecs.register_error("namereplace", mynamereplace) print(u"mañana".encode("ascii", "namereplace").decode()) $ python3.5 codecs_mynamereplace.py ma\N{LATIN SMALL LETTER N WITH TILDE}ana $ python3.4 codecs_mynamereplace.py using mynamereplace ma\N{LATIN SMALL LETTER N WITH TILDE}ana $ python2.7 codecs_mynamereplace.py using mynamereplace ma\N{LATIN SMALL LETTER N WITH TILDE}ana -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
On 10 April 2017 at 15:17, David Shi via Python-list wrote: > In the data set, pound sign escape appears: > u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000', > When using table.to_csv after importing pandas as pd, an error message > persists as follows: > UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position > 0: ordinal not in range(128) > The error indicates clearly that you have a character which is not part of the standard ASCII range, hence the message : "ordinal not in range(128)" To understand it better, try to imagine characters as numbers and that basic ASCII defines characters in this range. see http://www.ascii-code.com/ So the pound character is out this range, its ordinal is being read by your program as #a3 in hex (#163 in decimal). So *probably* your data originally is in Latin-1 encoding, First , you should find out where the data comes from: is it text file, or some input, then in which application and encoding was it created. To get rid of errors, I'd say there are 2 common strategies: ensure that all source data is saved in Unicode (save as UTF-8) Or, replace the pound sign with something which is representable in standard ASCII, e.g. replace the pound sign with "GBP" in sources. Otherwise, you must find out which encoding is used in source data and apply re-encoding accordingly to input-output format specification. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-11 21:58, Mikhail V wrote: On 11 April 2017 at 16:56, Steve D'Aprano wrote: On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: [...] DropBox and Google seem to agree that there are no good solutions, since they are moving to Go. That's a good solution! Maybe we should be writing extensions in Go, instead of C. Or for maths-heavy work, using extensions written in Julia. Just my curiosity, I've always been intersted in such question: are devs still writing extensions in C, I mean type in C code? Aren't they using some translator or IDE which at lest hides the brackets and semicolons? I personally don't have problems with understanding low-level concepts of programming, but I find it pretty hard to see through the mangroves of brackets, asterisks and Co. The regex module does the matching using code written in C. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Monday, April 10, 2017 at 4:43:52 AM UTC-5, bartc wrote: > On 10/04/2017 03:40, Rick Johnson wrote: > > On Sunday, April 9, 2017 at 1:34:39 PM UTC-5, bartc wrote: > > > > I have my own interpreted language which I call > > > 'dynamic', but compared with Python, code in it might as > > > well be set in concrete. > > > > Is this a personal toy, or something that you can share a > > link to? > > It's a personal thing but not a toy. Some more info here: Thanks for link bartc, i'll have a look. > Yes. I suppose when it gets to a point where there are so > many features anyway, adding a few more makes little > difference! Indeed. "A drop in the bucket" comes to mind. ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote: > Still I miss some old school features in Python, e.g. > "goto" statement would be very useful in some cases. Are you serious? > I know it is considered bad style to use goto, but in some > cases it is just most natural thing to use. "Natural"? If you're programming from inside a spaghetti bowl, i suppose. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Monday, April 10, 2017 at 5:48:30 PM UTC-5, Erik wrote: > On 10/04/17 03:23, Chris Angelico wrote: > > Okay, I have a pretty thick skin, but this is getting a > > bit obnoxious. Can you PLEASE post something that isn't > > just insulting me? Thanks. > > Are you suggesting he should post something that insults > you *and* others? Oh, don't take Chris so seriously. He's not offended. He's just one of those infants who utilizes pity in hopes that mummy will come save him from the scary world of free speech. Perhaps Chris would be happier if we created a py- safe-zone for him: complete with coloring books, a petting zoo and CNN running fake news stories that Hillary actually won the election. Yep, that should pacify him for a while. > If so, I'm up for being insulted too ;) Sorry, but i don't insult people unless they deserve it. (psst: try to be less nice and less intelligent, and then _maybe_ i'll insult you.) Of course, in the end, you must decide whether you have been insulted, or not. As a third party, i have no control over other people's emotions. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 4:56:27 AM UTC-5, Brecht Machiels wrote: > On 2017-04-11 08:19:31 +, Steven D'Aprano said: > > > On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote: [...] > > The Python ecosystem is actually quite healthy, if you > > need to speed up code there are lots of solutions, and > > some of them are even good solutions. > > There seem to be no solutions for my use case (rinohtype). > DropBox and Google seem to agree that there are no good > solutions, since they are moving to Go. Yup! > > Nevertheless, it is interesting to discuss whether or not > > any of these features will go mainstream or make it into > > CPython. > > Indeed! I initially wanted to include the following in the > article, but decided it would be too controversial. But now > that I've been exposed as an ignorant and naive blogger, I > might as well share these thoughts. I love this guy! ;-) > I have the feeling that a faster Python will never > materialise unless the CPython core developers make > performance a high priority. I understand that high > performance was never a goal in CPython development (and > Python language design!), but recent events (DropBox, > Google) might help to reconsider that standpoint. The fact that both Google *AND* DropBox are ignoring Python, must be devastating to GvR, however, for us at least, this emotional devastation may help to explain why Python is evolving in such a strange direction. > Here's a wild idea: consider Python 3 feature-complete. > Similar to how Python 3 cleaned up the unicode and other > warts of Python 2, Python 4 could clean up the performance > warts, but retaining the "soul" of the language. But that > last part is a diffucult one, because it would lead to > endless discussions of what would still be Python. So it's > better to define an official "TurboPython" subset. This > would also ensure backwards compatibility, but of course > complicate the implementation. I've been hinting at that for years, to no avail. > But who am I (or anyone) to suggest what the CPython core > developers should do? Do you write Python code? If so, then you have a right to both speak and to be heard. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 11 April 2017 at 23:45, MRAB wrote: > On 2017-04-11 21:58, Mikhail V wrote: >> >> On 11 April 2017 at 16:56, Steve D'Aprano >> wrote: >>> >>> On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: >>> >>> [...] >>> DropBox and Google seem to agree that there are no good solutions, since they are moving to Go. >>> >>> >>> That's a good solution! Maybe we should be writing extensions in Go, >>> instead >>> of C. Or for maths-heavy work, using extensions written in Julia. >> >> >> Just my curiosity, I've always been intersted in such question: are devs >> still writing extensions in C, I mean type in C code? Aren't they using >> some translator or IDE which at lest hides the brackets and semicolons? >> I personally don't have problems with understanding low-level >> concepts of programming, but I find it pretty hard to see >> through the mangroves of brackets, asterisks and Co. >> > The regex module does the matching using code written in C. That is tough... I feel like a sissy with my humanistic readability ideas. And those monospaced, green-on-black texts... (not trolling, I just have have rich imagination) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 9:56:45 AM UTC-5, Steve D'Aprano wrote: > On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: > > On 2017-04-11 08:19:31 +, Steven D'Aprano said: > > > > I understand that high performance was never a goal in > > CPython development (and Python language design!), but > > recent events (DropBox, Google) might help to reconsider > > that standpoint. > > *shrug* It isn't as if high-performance is a requirement > for all code. But given the choice, no prospective "language shopper" is going to choose the slower language over a faster language -- at least not from a pool of similar languages with similar features (no comparing Python to C, please!). So even if you don't need the speed _today_, you may need it _tomorrow_. And once you've written a few hundred thousand lines of code, well, you're committed to the language you chose yesterday. > And it isn't as if Python is in any serious risk of losing > popularity. No language can expect to be popular forever. > Eventually Python will be as obsolete as or niche as COBOL, > Tcl or ABC. But that day is not now. But considering (as you pointed out) that Python is 20 years old now, and has also recently suffered a major community fracturing with the release of Py3000, that day is getting ever closer. I don't see how Python can survive when a small core of language devs consistently ignore the wider community. > > > > Here's a wild idea: consider Python 3 feature-complete. > > I think that will conflict with the many, many people who > want Python to have more features, and care more about them > than speed. Python-ideas and Python-dev do not represent the majority of the Python community. They are out there, right now, writing code and solving problems. But when Python fails to aid in this endeavor, they will not come here to complain, no, they will search for a new language. In other words: they will vote with their feet. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 10:31:16 AM UTC-5, bartc wrote: > On 11/04/2017 15:56, Steve D'Aprano wrote: > > > The truth is, all of us in this discussion -- including me > > -- are "random, ignorant commentators". I don't believe > > that any of us are experts at writing compilers. Bart is > > a possible exception, for some definition of "expert" -- > > he claims to have written a quite fast, moderately dynamic > > language, but nobody else (that I know of) has used it. > > And no offence to Bart, but from his comments and > > questions on the list, I think it is fair to say that > > whatever knowledge he has on language design was probably > > state of the art thirty years ago. Bart sometimes > > expresses surprise and confusion over concepts which are > > common in languages like Javascript, Python, Perl, Ruby > > etc. These are not young languages! Python is over 20 > > years old, Perl is even older. So I suspect Bart's > > knowledge is probably from the 70s or 80s? > > Yes, about then. But it means I have a lot of experience > getting this stuff to work briskly on limited hardware, and > I can identify bloat and inefficiency. A _very_ good point, and kudoes to you for having a thick skin. The truth is, our modern hardware masks the inefficacy of our modern high level languages. Heck, Python could have never survived on 1970s hardware. It would have been laughable to even suggest something as inefficient as Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 12 April 2017 at 00:02, Rick Johnson wrote: > On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote: >> Still I miss some old school features in Python, e.g. >> "goto" statement would be very useful in some cases. > > Are you serious? Not so serious to think it is needed much. And it easy enough to imagine where it would be more readable than setting up flags and if-blocks just to jump along the script. n.d., it reminds me also about the discussion about exiting from nested loops. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
I used to write Python modules in C++. Well, more accurately, wrapped already-written C++ APIs to expose to Python using Boost Python. This wasn't due to performance issues, but to avoid reimplementing APIs. That said, I believe Python gets a bad wrap in regards to performance for a variety of reasons, chief among them being: Python's prime audience tends to be mathematical/scientific/statistical/financial first and are developers by happen stance (I know this is a large generalization). Point is, for these audiences, the prime driver is to get a result. Efficiency is secondary. For instance, in a separate thread in the last week, someone was asking if there was a faster way of doing something along these lines: result = [(expensive_calc(x) + 1, expensive_calc(x) for x in some_data] A valid, yet sub-optimal response was suggested: temp = [expensive_calc(x) for x in some_data] result = [(x + 1, x) for x in temp] A better result would have been: temp = (expensive_calc(x) for x in some_data) result = [(x + 1, x) for x in temp] Note: the difference is subtle, but significant. The first example creates a list with the entire temporary result, while the second uses a generator. For small sizes of "some_data", you're not likely to notice. For large sizes of "some_data", this is huge. Writing performant Python code is possible, but like writing performant code in any other language, you need to be aware of what's happening. This means paying attention to things that may cause memory allocations (which are largely hidden from you in Python). I worked on http://www.marketswiki.com/wiki/CMDX - in particular I wrote most of the Migration Utility mentioned to migrate paper CDS trades to standardized CDS contracts against CME. Most of the migration util was written in native Python 2.5 (it was written in 2008) using a single thread. Performance wasn't super critical, but desired. At the end of the project, I was processing ~100K positions per second. Memory usage of the app was constant and processing time of a portfolio was directly linear to the number of positions in the portfolio. Python wasn't the limiting factor for the app - it was the write speed to the database (and we were using the bcp interface of pysybase to write to a Sybase DB). Basically, what I'm getting at is Python *can* be performant. It's also easy to screw up and introduce non-obvious slowness. Threading in Python is bad - don't bother (until we can get rid of the GIL, I doubt the situation will improve). If you have a performance problem with Python, before you blame Python, take a step back and look at your own code (or libraries you're using) and ask yourself: "Is my code optimal?" Yes, Python is not the faster language/runtime in existence. But for probably 99% of the people out there that complain about Python's speed, there's probably plenty of suboptimal or outright wasteful code that they should fix first, before complaining. For the other 1%, Python was probably the wrong choice to begin with. I don't intend this to be seen or implied as an attack or criticism of anyone. I'm just trying to provide an insight into my experience of using Python. Regards, Nate On Tue, Apr 11, 2017 at 3:58 PM, Mikhail V wrote: > On 11 April 2017 at 16:56, Steve D'Aprano > wrote: > > On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: > > > >[...] > > > >> DropBox and > >> Google seem to agree that there are no good solutions, since they are > >> moving to Go. > > > > That's a good solution! Maybe we should be writing extensions in Go, > instead > > of C. Or for maths-heavy work, using extensions written in Julia. > > Just my curiosity, I've always been intersted in such question: are devs > still writing extensions in C, I mean type in C code? Aren't they using > some translator or IDE which at lest hides the brackets and semicolons? > I personally don't have problems with understanding low-level > concepts of programming, but I find it pretty hard to see > through the mangroves of brackets, asterisks and Co. > > > Mikhail > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Swiss Ephemeris
On Monday, April 10, 2017 at 12:56:47 AM UTC-5, Deborah Swanson wrote: > Fully recognizing that most of what you wrote was tongue- > in-cheek, I just want to say that regardless of the wonders > of modern medicine, it's a pity they learn so little about > successful medicines other than their own. In other > academic scientific disciplines such as physics and > chemistry it's not uncommon to see history of science > courses in the curriculum. But not in medicine. I learned > what I know about ancient Greek science from a university > physics professor, though I doubt he would ever have > guessed that one of his students would someday breathe new > life into that ancient science by attempting to ressurrect > it. The great ancients were no less endowed with > intelligence than we are, they simply directed it to > different ends. Hmm. I would say the ancients had a relatively "equal intellectual capacity" as we moderns, but with far less empirical evidence from which to theorize from. Personally. i'm highly skeptical of astrology -- but being that you're writing an application to categorize and present this raw data in an intuitive form for study -- based purely on the learing experience _alone_, i think the project has merit. Hopefully your constantly pushing your technical boundaries: learning new libraries; learning new languages; experimenting with cutting-edge algorithms, etc. I'm firmly convinced that time spent writing code is never wasted, because programming is perpetual problem solving and honing your problem solving skills can be beneficial to all aspects of life. Many times you'll find the answer to one problem while trying to solve another. Problem solving is the task that consistently bears intellectual fruit. And that's why i love writing code. It always presents me with a challenge to overcome, or a riddle to solve. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Grant Edwards writes: > I didn't know there was such a thing as "The Python C API". It's described in this document: https://infohost.nmt.edu/tcc/help/lang/python/2_6_3/c-api.pdf You can tell that the document is about the Python/C API (ok, with a slash) because it says so at the top of the title page. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Chris Angelico writes: > Do you mean this? > https://docs.python.org/3/c-api/intro.html Correct, smart guy ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Grant Edwards writes: > If there are now other Python implementations (e.g. MicroPython) with > C APIs that differ from CPython, then it seems like it is no longer > redundant to say "the CPython API". Perhaps there should be an attempt to define a unified API like the Java JNI, Lisp FFI's, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
goto is a misunderstood and much misaligned creature. It is a very useful
feature, but like nearly any programming construct can be abused.
Constructs like 'break', 'continue' or 'next' in languages like Python or
C/C++ are goto's with implied labels.
As Mikhail said, goto's can be great to break out of nested loops (only a
handful of languages support named 'breaks').
So, instead of:
bool found = false;
for (int i = 0; i = ...; ++i)
{
for (int h = 0; h = ...; ++h)
{
if (some_condition)
found = true;
}
if (found) break;
}
You can have:
for (int i = 0; i = ...; ++i)
{
for (int h = 0; h = ...; ++h)
{
if (some_condition)
goto found;
}
}
// not found
found:
// handle found
The second is better for a number of reasons: it's clearer. It has fewer
variables (smaller stack), it has fewer branches (better for the CPU's
branch prediction), and it has fewer instructions (better for CPU
instruction cache). This is a trivial, contrived example, but I've seen
more than 4x nested loops using an exit flag like this (at every level of
the loops) that could have been replaced with a lot less code.
People need to stop drinking "X is considered harmful." Even Dijkstra later
lamented that his "Goto considered harmful" paper was misinterpreted and
misrepresented as advocating that goto should never be used.
Additionally, I'd recommend everyone read '"Considered Harmful" Essays
Considered Harmful': http://meyerweb.com/eric/comment/chech.html
Regards,
Nate
On Tue, Apr 11, 2017 at 6:04 PM, Mikhail V wrote:
> On 12 April 2017 at 00:02, Rick Johnson
> wrote:
> > On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote:
> >> Still I miss some old school features in Python, e.g.
> >> "goto" statement would be very useful in some cases.
> >
> > Are you serious?
>
> Not so serious to think it is needed much.
> And it easy enough to imagine where it
> would be more readable than setting up flags and if-blocks
> just to jump along the script.
>
> n.d., it reminds me also about the discussion about
> exiting from nested loops.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Mikhail V writes: > Just my curiosity, I've always been intersted in such question: are devs > still writing extensions in C, I mean type in C code? Yes. > Aren't they using some translator or IDE which at lest hides the > brackets and semicolons? I don't know of anyone who does that. I don't think anyone minds C's brackets and semicolons, and lots of other languages like Java and Perl use them too, for programmer familiarity. The actual difficulty with C is that it gives rise to a high incidence of hard-to-diagnose bugs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 2017-04-12 01:28, Nathan Ernst wrote: [snip] I worked on http://www.marketswiki.com/wiki/CMDX - in particular I wrote most of the Migration Utility mentioned to migrate paper CDS trades to standardized CDS contracts against CME. Most of the migration util was written in native Python 2.5 (it was written in 2008) using a single thread. Performance wasn't super critical, but desired. At the end of the project, I was processing ~100K positions per second. Memory usage of the app was constant and processing time of a portfolio was directly linear to the number of positions in the portfolio. Python wasn't the limiting factor for the app - it was the write speed to the database (and we were using the bcp interface of pysybase to write to a Sybase DB). Basically, what I'm getting at is Python *can* be performant. It's also easy to screw up and introduce non-obvious slowness. Threading in Python is bad - don't bother (until we can get rid of the GIL, I doubt the situation will improve). Threading is OK if you're waiting for I/O where the main limiting factor is the speed of the I/O, e.g. transferring stuff to/from the internet. If you have a performance problem with Python, before you blame Python, take a step back and look at your own code (or libraries you're using) and ask yourself: "Is my code optimal?" Yes, Python is not the faster language/runtime in existence. But for probably 99% of the people out there that complain about Python's speed, there's probably plenty of suboptimal or outright wasteful code that they should fix first, before complaining. For the other 1%, Python was probably the wrong choice to begin with. I don't intend this to be seen or implied as an attack or criticism of anyone. I'm just trying to provide an insight into my experience of using Python. [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
I think that's fair (and I had intended to mention it). Although, I'm curious how threading with IO compares to using async/awai (I've not experience with async/await in Python, just in C#). Regards, Nate On Tue, Apr 11, 2017 at 8:04 PM, MRAB wrote: > On 2017-04-12 01:28, Nathan Ernst wrote: > [snip] > > I worked on http://www.marketswiki.com/wiki/CMDX - in particular I wrote >> most of the Migration Utility mentioned to migrate paper CDS trades to >> standardized CDS contracts against CME. Most of the migration util was >> written in native Python 2.5 (it was written in 2008) using a single >> thread. Performance wasn't super critical, but desired. At the end of the >> project, I was processing ~100K positions per second. Memory usage of the >> app was constant and processing time of a portfolio was directly linear to >> the number of positions in the portfolio. Python wasn't the limiting >> factor >> for the app - it was the write speed to the database (and we were using >> the >> bcp interface of pysybase to write to a Sybase DB). >> >> Basically, what I'm getting at is Python *can* be performant. It's also >> easy to screw up and introduce non-obvious slowness. Threading in Python >> is >> bad - don't bother (until we can get rid of the GIL, I doubt the situation >> will improve). >> >> Threading is OK if you're waiting for I/O where the main limiting factor > is the speed of the I/O, e.g. transferring stuff to/from the internet. > > If you have a performance problem with Python, before you blame Python, >> take a step back and look at your own code (or libraries you're using) and >> ask yourself: "Is my code optimal?" >> >> Yes, Python is not the faster language/runtime in existence. But for >> probably 99% of the people out there that complain about Python's speed, >> there's probably plenty of suboptimal or outright wasteful code that they >> should fix first, before complaining. For the other 1%, Python was >> probably >> the wrong choice to begin with. >> >> >> >> I don't intend this to be seen or implied as an attack or criticism of >> anyone. I'm just trying to provide an insight into my experience of using >> Python. >> >> [snip] > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, 12 Apr 2017 08:42 am, Rick Johnson wrote: > The fact that both Google AND DropBox are ignoring Python, > must be devastating to GvR Fact check: liar, liar, pants on fire. Neither Google nor DropBox are "ignoring Python". From two randomly selected technical job positions currently offered: "Strong coding skills in an object-oriented language (Python preferred)" https://www.dropbox.com/jobs/listing/184604 "Your knowledge of Python a plus" https://www.dropbox.com/jobs/listing/91407 Google likewise has a huge investment in Python code. *Even if* they decide to move entirely to Go for new code (unlikely), Python will still have a role to play at Google for years, possibly decades. Rick, you must be really insecure about your choice of language, given how much you obsess about other people leaving Python for other languages. You're constantly writing about (imaginary) other people leaving Python, or being unhappy with Python, or "voting with their feet". Well, people do vote with their feet, and Python is consistently in the most popular handful of languages. http://redmonk.com/sogrady/2017/03/17/language-rankings-1-17/ https://blog.newrelic.com/2016/08/18/popular-programming-languages-2016-go/ http://pypl.github.io/PYPL.html https://www.tiobe.com/tiobe-index/ I still remember your first, or at least a very early, post as Ranting Rick where you were *terrified* that unless GvR did exactly what you said, the entire Python community was going to pack up and move to Ruby. It was real Chicken Little "The Sky Is Falling" stuff. Well, GvR didn't pay the least bit of attention to your "advice", in fact he has continued to move Python in directions that you hate -- Unicode as the default string type, type annotations, Python 3 -- and far from suffering for it, the Python community is bigger and stronger than ever. How is your "Rick Python" coming along? Its been, what, ten years, fifteen years since you promised to give the "silent majority" exactly the Python language they wanted, and we're still waiting for you to publish a single line of code. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, 12 Apr 2017 10:28 am, Nathan Ernst wrote: [...] > If you have a performance problem with Python, before you blame Python, > take a step back and look at your own code (or libraries you're using) and > ask yourself: "Is my code optimal?" > > Yes, Python is not the faster language/runtime in existence. But for > probably 99% of the people out there that complain about Python's speed, > there's probably plenty of suboptimal or outright wasteful code that they > should fix first, before complaining. For the other 1%, Python was > probably the wrong choice to begin with. Thanks for your perspective Nate, that's a really good point and I wish more people would remember that you can write slow code in any language. There's a whole *universe* of use-cases, ranging from code where speed doesn't matter one bit to absolutely performance critical code. No single language can be ideal for all tasks, that's why we have so many languages to choose from. Not just dozens, but hundreds! They all make different tradeoffs between functionality, style, performance and memory use. That's okay! Diversity in language design is a good thing. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Inclusion of of python and python libraries licensed with BSD- 3 clause license in proprietary software
On Wed, 12 Apr 2017 06:35 am, Abhishek Kumar wrote: > Hello, > > I tried finding the answer but even the lawyers in my town have no idea Where is your town? > about it and searching the web leaved me puzzled. What have you tried? The first few links found here: https://duckduckgo.com/?q=BSD-3+licence+faqs seem pretty easy to understand. It's a very short and simple licence, precisely because it puts very few requirements on you. If you are using Library X (which is under the BSD-3 licence) then all you need do to meet the licence requirements is to include Library X's copyright notice and licence. You don't have to provide the source code to Library X, or to your own application. > I am planning to make a software in python which will include libraries > licensed under BSD- 3 clause. Can I sell this software under proprietary > license Yes. > and legally inhibit redistribution by users under my own license. Yes. > Also if you know anyone who holds knowledge in this field then please do > let me know.. Your response will be really helpful. > > Regards, > Abhishek Kumar > ᐧ -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: > I still do my everyday stuff in Python and I'd like to get more > conversant with stuff like numpy, but it feels like an old-fashioned > language these days. "Old fashioned"? With await/async just added to the language, and type annotations? And comprehensions and iterators? Admittedly type annotations are mostly of interest to large projects with many developers and a huge code base. But the rest? Comprehensions may have been around for a decade or two in Haskell, but most older languages don't have them. I'm pretty sure Java doesn't. Does Javascript? Comprehensions feel like a fancy new language feature to me. The whole asynchronous programming features are extremely new and "hip". What sort of things do you consider "new-fashioned" if Python is old-fashioned? I'm reminded of this quote from the timbot: In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it. -- Tim Peters, 16 Sep 1993 -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, April 12, 2017 at 3:32:57 AM UTC+5:30, Rick Johnson wrote: > On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote: > > Still I miss some old school features in Python, e.g. > > "goto" statement would be very useful in some cases. > > Are you serious? > > > I know it is considered bad style to use goto, but in some > > cases it is just most natural thing to use. > > "Natural"? If you're programming from inside a spaghetti > bowl, i suppose. Try coding up an automaton (synonyms DFA, FSM) by hand With state = goto-label [And the stuff 'under' it] transition = goto-statement is a mapping that is hard to beat -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, April 12, 2017 at 7:38:12 AM UTC+5:30, Steve D'Aprano wrote: > On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: > > > I still do my everyday stuff in Python and I'd like to get more > > conversant with stuff like numpy, but it feels like an old-fashioned > > language these days. > > "Old fashioned"? With await/async just added to the language, and type > annotations? I wonder if you notice Steven, that people use these examples to make the opposite case? When you see "python is sweet... almost as sweet as javascript" you know you are in trouble and need to start running (at least I do) http://stackabuse.com/python-async-await-tutorial/ [last para] -- https://mail.python.org/mailman/listinfo/python-list
Re: read in a list in a file to list
On Sunday, April 9, 2017 at 4:22:59 PM UTC-5, john polo wrote: > On 4/8/2017 3:21 PM, [email protected] wrote: > > On Saturday, April 8, 2017 at 7:32:52 PM UTC+1, john polo wrote: > > I'll start you off. > > > > with open("apefile.txt") as apefile: > > for line in apefile: > > doSomething(line) > > > > String methods and/or the csv module might be used here in > > doSomething(line), but I'll leave that to you so that you > > can learn. If you get stuck please ask again, we don't > > bite :) > Mark, Thanks for the reply. I looked back through the > methods for strings. I also looked at the csv module, but I > couldn't tell which one of those would help. Well, if you plan to write much code in Python you'd be wise to memorize every string method ASAP. And if you cannot, or are not willing to do that, then your programming adventures are going to be very painful. My advice would be to forget about the csv module for now, and do some major studying of all the string methods. And please, use the interactive interpreter to play around with each one of these methods. Here is a sample of me playing... ## START INTERACTIVE SESSION (Python2.x) ## >>> myStr = 'Rick is awesome!' >>> type(myStr) >>> len(myStr) 16 >>> dir(myStr) ['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '_formatter_field_name_split', '_formatter_parser', 'capitalize', 'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find', 'format', 'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'partition', 'replace', 'rfind', 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill'] >>> help(myStr.split) Help on built-in function split: split(...) S.split([sep [,maxsplit]]) -> list of strings Return a list of the words in the string S, using sep as the delimiter string. If maxsplit is given, at most maxsplit splits are done. If sep is not specified or is None, any whitespace string is a separator and empty strings are removed from the result. ## END INTERACTIVE SESSION (Python2.x) ## > The small .txt file does have commas, but with the weird > form of listname = [1] , [2], [3], etc. for a .csv, I don't > know how that would be read in a like a .csv. But now that > I think about it, datObj2 in my script prints just the list > elements, so maybe the 'listname=' part wouldn't affect > it... Again, forget about the csv module for now, it will only confuse you. Focus on learning Python String methods first. I can assure you, you might could get by without knowing jack about the csv module, but you won't get anywhere until you become intimately familiar with Python String methods. > Anyway, after reviewing string methods some more, I came up > with this. If I understood your hint, the loop was supposed > to somehow break up the long string that came from the > apelist file, Mark's code sample iterates over the lines of a file and passes each line to a function named "doSomething". His hope was that you would replace the call to doSomething with code that actually, well, does something. > but it seemed that trying to use the split method in a loop > wouldn't work, Where's your code proving it "would not work"? I can assure you, a string can be split inside a loop. > especially since one of my attempts started a list and then > the interpreter said there were no split methods for list. Of course, because there is no split method for a list. Don't believe me? Okay, let's conduct an experiment... ## START INTERACTIVE SESSION (Python2.x) ## >>> aList = [1,2,3] >>> 'split' in dir(aList) False ## END INTERACTIVE SESSION (Python2.x) ## > The new attempt gives me a list, now I have to figure out > how to deal with unwanted quotation marks and spaces. Then stop trying to solve 10 problems at once and open your interactive Python interpreter and do some testing until your confident that you can remove unwanted chars from a string. > Can you make two replacements in the same statement, for > example 'datObj=datFil.read().replace('"','').replace('"','')? i dunno, did you try testing the code yourself in an interactive session like i asked? Here, once more... ## START INTERACTIVE SESSION (Python2.x) ## >>> myStr 'Rick is awesome!' >>> myStr.replace('Rick', "Rick's patience").replace('awesome', 'wearing thin')
Re: IOError: [Errno 12] Not enough space
On Tue, Apr 11, 2017 at 12:30 PM, LnT wrote: > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: > No browser is open > | FAIL | > IOError: [Errno 12] Not enough space > > > I have cleared %TEMP% and reran the script. Errno 12 is ENOMEM. It's a memory error and has nothing to do with disk space. The fact that you're getting this error while doing I/O seems odd if you're really using Windows 10. In Windows 7 this error is not uncommon with console I/O, since a small 64K heap of shared memory is used for IPC between the client and the console host (conhost.exe). Buffers for reading from and writing to the console can be no larger than the largest contiguous block in this shared heap. Otherwise the request fails with ERROR_NOT_ENOUGH_MEMORY, which the CRT translates to the errno value ENOMEM. Windows 8+ uses a kernel device (ConDrv) for IPC between the client and console host, so it doesn't have this limitation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, Apr 12, 2017 at 12:29 PM, Rustom Mody wrote:
>
> I wonder if you notice Steven, that people use these examples to make
> the opposite case?
>
> When you see "python is sweet... almost as sweet as javascript"
>
> you know you are in trouble and need to start running (at least I do)
>
> http://stackabuse.com/python-async-await-tutorial/
> [last para]
Ah, yes, because JS's generators are so smooth compared to Python's.
The fact that yielded values get packaged up into {value: ..., done:
false} makes so much more sense, plus it's hugely advantageous that
you need to transpile your code to be able to actually use async
functions in anything other than the latest Chrome/Safari/Firefox.
There are two areas where JS has a really significant advantage over Python:
1) Invoking a JS async function is as simple as calling it, because
you already are running everything through an event loop. I don't
think Python should do the same, but maybe a more obvious way to do
this than ensure_future would help.
2) If you have existing code that is built on JS's promises (of which
there's a lot, but by no means all), async functions cleanly interface
with them. You can await any promise, and an async function
automatically returns a promise. So they're better integrated with the
rest of the ecosystem - or at least, that portion of the ecosystem
that jumped on the promise bandwagon. Got something that only uses
callbacks? Sorry, mate, you're out of luck.
Both of them come from the fact that JS has always been intended as an
asynchronous language - right back in the 90s, before it was all
standardized as ECMAScript, you had a setTimeout() function rather
than a sleep(). Python, meanwhile, has made it easy to write blocking
I/O in a single-threaded program, and then adds async'ness to it. So
with JS, you're adding smoothness to functionality that already
exists, but with Python, you're adding functionality to a smooth and
clean language.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 7:10:00 PM UTC-5, Mikhail V wrote: > On 12 April 2017 at 00:02, Rick Johnson wrote: > > On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote: > > > Still I miss some old school features in Python, e.g. > > > "goto" statement would be very useful in some cases. > > > > Are you serious? > > Not so serious to think it is needed much. And it easy > enough to imagine where it would be more readable than > setting up flags and if-blocks just to jump along the > script. Oh, you mean a goto that is confined to the realms of conditional logic? I see... Hmm... perhaps i'm more supportive of the idea after all. Do you have any Python- centric code (or pseudo code) examples you can provide that showcase the power of this proposed feature over the legacy features? > n.d., it reminds me also about the discussion about exiting > from nested loops. Do you have a link? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 7:28:46 PM UTC-5, Nathan Ernst wrote: > > [...] > > Writing performant Python code is possible, but like > writing performant code in any other language, you need to > be aware of what's happening. This means paying attention > to things that may cause memory allocations (which are > largely hidden from you in Python). But what you're asking people to do is not unlike reinventing wheels. Some are not aware of every subtle case that will cause a bottleneck. For this reason, it would be wise to create a database where these bottlenecks can be logged, with the intention of creating a python optimizing tool at some time in the future. Like you said, since a large subset of python coders are not CS majors, we cannot expect them to understand Python at such a fundamental level as someone such as GvR. That is the price of creating a language that abstracts away all the dirty details so that laymen can wield it. But just as Python should _never_ seg- fault (but it does!), high level languages like Python should make it difficult, if not impossible, to write sub- optimal code (at least in the blatantly obvious cases). The whole fundamental nature of Python is to relieve the programmer of all the onerous tedium and drudgery (memory management, cryptic syntaxes, etc...), so that the programmer's mental energy can be devoted solely to the creative demands of logic and interfaces. > I worked on http://www.marketswiki.com/wiki/CMDX - in > particular I wrote most of the Migration Utility mentioned > to migrate paper CDS trades to standardized CDS contracts > against CME. Most of the migration util was written in > native Python 2.5 (it was written in 2008) using a single > thread. Performance wasn't super critical, but desired. At > the end of the project, I was processing ~100K positions > per second. Yeah, but what kind of hardware were you running it on? It seems in this case, that you wrote up a utility and ran it on a machine of your choosing, but not all developers have the advantage of choosing which machine their code executes on. Most code is written and released for mass consumption on client machines which come in all shapes and sizes. Sure, you can write sloppy code on a top-of-the-line hardware and not notice, but try the same code on a windoze 95 box and see what happens... > Threading in Python is bad - don't bother (until we can get > rid of the GIL, I doubt the situation will improve). If you search the archives (and internet) for "remove GIL", you'll find more hits than you could parse in a lifetime. Basically, the community has been begging for the GIL to be removed since the early 90s, but the Python royalty have no interest to do so. And the reasons for this could be many. I have my personal suspicions... > If you have a performance problem with Python, before you > blame Python, take a step back and look at your own code > (or libraries you're using) and ask yourself: "Is my code > optimal?" > > Yes, Python is not the faster language/runtime in > existence. But for probably 99% I don't think it's fair to make broad-brushed assertions as to the technical prowess of everyday Python programmers. Perhaps the incidents of non-optimal code are high, but 99% is difficult to swallow and sounds an awful lot like hyperbole. And although i'm sure some folks here will lap-up such gross exaggerations with prideful glee, sorry, but i'm not one of them. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Chris Angelico writes: > Python, meanwhile, has made it easy to write blocking > I/O in a single-threaded program, and then adds async'ness to it. I'd be interested to know how to open a disk file asynchronously in a single-threaded Python program under Linux. As far as I can tell there is no way to do it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tuesday, April 11, 2017 at 7:44:49 PM UTC-5, Nathan Ernst wrote:
> goto is a misunderstood and much misaligned creature. It is
> a very useful feature, but like nearly any programming
> construct can be abused. Constructs like 'break',
> 'continue' or 'next' in languages like Python or C/C++ are
> goto's with implied labels. As Mikhail said, goto's can be
> great to break out of nested loops (only a handful of
> languages support named 'breaks'). So, instead of:
>
> bool found = false;
> for (int i = 0; i = ...; ++i)
> {
> for (int h = 0; h = ...; ++h)
> {
>if (some_condition)
> found = true;
> }
> if (found) break;
> }
>
> You can have:
>
> for (int i = 0; i = ...; ++i)
> {
> for (int h = 0; h = ...; ++h)
> {
>if (some_condition)
> goto found;
> }
> }
> // not found
>
> found:
> // handle found
>
I'll admit, that in a few cases of deeply nested loops, i
have purposely stripped out the nested code and wrapped it
in a function so i could take advantage of return, because
indeed, flags are distracting. However, i don't think this
one example is enough to warrent a goto. Unless you can
provide more than one legitimate use for goto, i'd rather
support a new keyword like "breakall". In fact, the more i
think about it, the more i realize that it should have been
"breaklocal" and "breakglobal" all along! Hmm, how would goto
handle a logic that required both a local and a global
break within the same nested loop structure?
> The second is better for a number of reasons: it's clearer.
> It has fewer variables (smaller stack), it has fewer
> branches (better for the CPU's branch prediction), and it
> has fewer instructions (better for CPU instruction cache).
> This is a trivial, contrived example, but I've seen more
> than 4x nested loops using an exit flag like this (at every
> level of the loops) that could have been replaced with a
> lot less code.
But it also requires a named target. (Although i'll admit,
goto does offer more _flexibility_ over a single
"breakglobal" keyword)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wed, Apr 12, 2017 at 2:32 PM, Paul Rubin wrote: > Chris Angelico writes: >> Python, meanwhile, has made it easy to write blocking >> I/O in a single-threaded program, and then adds async'ness to it. > > I'd be interested to know how to open a disk file asynchronously in a > single-threaded Python program under Linux. As far as I can tell there > is no way to do it. I'm not sure how Node does it. But most of JavaScript/ECMAScript has historically been aimed at web browsers, where you're not allowed to open files as such, but you _can_ make HTTP requests. It's also entirely possible to have a single "application thread" and then a "file opening thread" that does nothing but open files; your app is still single threaded (thus you don't have concurrency concerns), but file opening becomes truly asynchronous. Oh, and Python also has to cope with a bit more complexity because it's possible to start multiple application threads in Python. It's not in JS. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Chris Angelico writes: > It's also entirely possible to have a single "application thread" and > then a "file opening thread" that does nothing but open files; Thanks. I think GHC and Erlang BEAM both do that. I hoped there was a better way. Note you potentially need multiple file opening threads. > your app is still single threaded (thus you don't have concurrency > concerns), but file opening becomes truly asynchronous. Of course you still have concurrency concerns, plus you have to be very very careful that nothing ever blocks. I've generally preferred in Python to use threads communicating by message passing through queues. This is pretty safe if you remember to not having any mutable objects shared between threads. Of course I like the way Erlang does it even more, with isolated lightweight processes. > Oh, and Python also has to cope with a bit more complexity because > it's possible to start multiple application threads in Python. It's > not in JS. Yeah I'm not sure of the JS situation. C++11 has futures and promises and I've been wanting to try to use them, but it's still on my infinitely deep stack of stuff to do. This looks amazing though: http://www.seastar-project.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
Hello eryk sun, Thanks so much for your input. could you please advice. 1) Any workaround for this issue ? 2) is it good to report issue in Windows OS help desk ? Regards, LnT On Wednesday, April 12, 2017 at 8:18:11 AM UTC+5:30, eryk sun wrote: > On Tue, Apr 11, 2017 at 12:30 PM, LnT wrote: > > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: > > No browser is open > > | FAIL | > > IOError: [Errno 12] Not enough space > > > > > > I have cleared %TEMP% and reran the script. > > Errno 12 is ENOMEM. It's a memory error and has nothing to do with > disk space. The fact that you're getting this error while doing I/O > seems odd if you're really using Windows 10. In Windows 7 this error > is not uncommon with console I/O, since a small 64K heap of shared > memory is used for IPC between the client and the console host > (conhost.exe). Buffers for reading from and writing to the console can > be no larger than the largest contiguous block in this shared heap. > Otherwise the request fails with ERROR_NOT_ENOUGH_MEMORY, which the > CRT translates to the errno value ENOMEM. Windows 8+ uses a kernel > device (ConDrv) for IPC between the client and console host, so it > doesn't have this limitation. -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
Hi Irmen, 1) yes. its Python 2.7 2) Since windows 10 machine is a VM ,Only drive is available C and is provided 60GB for both OS and other softwares like java and python. And still 20GB free space is available. This python script does - open web application and capture the screenshot of the webpage incase any functionality Fail? Hope this information is suffice. Let me know , if you need more specific logs to be captured ? Regards, LnT On Tuesday, April 11, 2017 at 10:41:36 PM UTC+5:30, Irmen de Jong wrote: > On 11-4-2017 14:30, LnT wrote: > > Hi, > > > > version information > > > > python 27 > > Please be more precise, there is no Python 27. (Yeah it is clear you meant > 2.7 but still) > > > java version "1.8.0_111" > That should not be relevant > > > OS -Win 10 , 64Bit , 8GB RAM , 60GB HD > > 60 GB is not a lot of space for windows... > > > > executing python test script (robotframework) for a we bapplication > > Application url will be invoked by Firefox 38.0 > > > > Please find below log: > > > > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: No > > browser is open > > | FAIL | > > IOError: [Errno 12] Not enough space > > > > That's not much information. Is there really not anything else in the log? > Like a > traceback, that may give some clues what the application is doing when it is > running out > of disk space? > > > > > > I have cleared %TEMP% and reran the script. > > But still I see this. > > > > Could you please show me some Light ? > > > > Based on the info you provided, the only solution I can think of is: free > more space. > Something in your application is trying to write stuff and there's simply not > enough > space on the disk to do so. > > > -i -- https://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 12] Not enough space
Hi Irmen, you may please find full log @ https://pastebin.mozilla.org/9018753 Regards, LnT On Tuesday, April 11, 2017 at 10:41:36 PM UTC+5:30, Irmen de Jong wrote: > On 11-4-2017 14:30, LnT wrote: > > Hi, > > > > version information > > > > python 27 > > Please be more precise, there is no Python 27. (Yeah it is clear you meant > 2.7 but still) > > > java version "1.8.0_111" > That should not be relevant > > > OS -Win 10 , 64Bit , 8GB RAM , 60GB HD > > 60 GB is not a lot of space for windows... > > > > executing python test script (robotframework) for a we bapplication > > Application url will be invoked by Firefox 38.0 > > > > Please find below log: > > > > Opening browser 'firefox' to base url 'https://onbdev.nbpa.com/zae' > > [ WARN ] Keyword 'Capture Page Screenshot' could not be run on failure: No > > browser is open > > | FAIL | > > IOError: [Errno 12] Not enough space > > > > That's not much information. Is there really not anything else in the log? > Like a > traceback, that may give some clues what the application is doing when it is > running out > of disk space? > > > > > > I have cleared %TEMP% and reran the script. > > But still I see this. > > > > Could you please show me some Light ? > > > > Based on the info you provided, the only solution I can think of is: free > more space. > Something in your application is trying to write stuff and there's simply not > enough > space on the disk to do so. > > > -i -- https://mail.python.org/mailman/listinfo/python-list
Re: download redtube video - Free
在 2008年9月22日星期一 UTC+8下午6:39:10，[email protected]写道： > download redtube video > . > . > . > ***CLICK HERE > http://vids365.cn/download-redtube-video > * > . > . > . > . > . > . > . > . > . > . > . > . > download redtube video You may also try Allavsoft to download from Redtube, Pornhub, Youporn, etc Here is the easy guide http://www.allavsoft.com/how-to/redtube-downloader.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
Paul Rubin wrote: Or you could look at the past 50 years(!) of Lisp and Scheme compilers some of which produce very good code, ask what Python features can't be straightforwardly transliterated into Lisp to use those compilers, Lisp and Scheme are much less dynamic than Python. The problem of translating Python code into efficient Lisp or Scheme isn't really much different from translating it into efficient machine code, or Java bytecode, or whatever. Type information is needed, either explicitly written in, or inferred, or JITted. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 4/11/2017 8:40 PM, Paul Rubin wrote: Mikhail V writes: Just my curiosity, I've always been intersted in such question: are devs still writing extensions in C, I mean type in C code? Yes. Aren't they using some translator or IDE which at lest hides the brackets and semicolons? I don't know of anyone who does that. I don't think anyone minds C's brackets and semicolons, and lots of other languages like Java and Perl People who do, like me, may avoid using C. I am really grateful that there are people willing to maintain the C code for CPython ;-). use them too, for programmer familiarity. The actual difficulty with C is that it gives rise to a high incidence of hard-to-diagnose bugs. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote: > high level languages like Python should make it difficult, if not > impossible, to write sub- > optimal code (at least in the blatantly obvious cases). You mean that Python should make it impossible to write: near_limit = [] near_limit.append(1) near_limit = len(near_limit) instead of: near_limit = 1 ? I look forward to seeing your version of RickPython that can enforce that rule. Oh, in case you think I'm making this up, this example came from some real-life code: https://mail.python.org/pipermail//python-list/2016-August/712673.html Here's another example: answer = 0 for i in range(10): answer += 1 instead of answer = 10 So... how exactly does the compiler prohibit stupid code? -- Steve -- https://mail.python.org/mailman/listinfo/python-list
