Re: An educational site written in Python (from YCombinator's RFS)
On Tue, May 10, 2016 at 2:13 AM, Cai Gengyang wrote: > Ok, so after reading YCombinator's RFS, I have decided that I want to work on > this : > > > --- > > EDUCATION > > If we can fix education, we can eventually do everything else on this list. > The first attempts to use technology to fix education have focused on using > the Internet to distribute traditional content to a wider audience. This is > good, but the Internet is a fundamentally different medium and capable of > much more. > > Solutions that combine the mass scale of technology with one-on-one in-person > interaction are particularly interesting to us. > > This may not require a "breakthrough" technology in the classical sense, but > at a minimum it will require very new ways of doing things. > > --- > > I want to create such a site using Python. What are the various steps I need > to take to create such a site ? This is a big project, but one that is worth > doing ... Any suggestions / help appreciated ? Thanks alot > > > Gengyang > -- > https://mail.python.org/mailman/listinfo/python-list I'm not sure there is a question here. Good luck with your quest -- Joel Goldstick http://joelgoldstick.com/blog http://cc-baseballstats.info/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Re: String concatenation
Steven D'Aprano writes: > Australia's naming laws almost certainly wouldn't allow such a name. https://en.wikipedia.org/wiki/Facebook_real-name_policy_controversy#Vietnamese -- https://mail.python.org/mailman/listinfo/python-list
Re: String concatenation
On Tuesday 10 May 2016 17:13, Paul Rubin wrote: > Steven D'Aprano writes: >> Australia's naming laws almost certainly wouldn't allow such a name. > > https://en.wikipedia.org/wiki/Facebook_real- name_policy_controversy#Vietnamese "Phuc Dat Bich" was a hoax, but it probably would be allowed in Australia. I'm surprised that Spanish names are not affected. Consider a woman who goes by the personal name of Maria Teresa, whose father's first surname was García and mother's first surname was Ramírez. Her name would therefore be Maria Teresa García Ramírez. If she marries Elí Arroyo López, then she might change her name to Maria Teresa García Ramírez de Arroyo. With six words, that would fall foul of Facebook's foul naming policy. http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: String concatenation
2016-05-10 9:54 GMT+02:00 Steven D'Aprano : > On Tuesday 10 May 2016 17:13, Paul Rubin wrote: > >> Steven D'Aprano writes: >>> Australia's naming laws almost certainly wouldn't allow such a name. >> >> https://en.wikipedia.org/wiki/Facebook_real- > name_policy_controversy#Vietnamese > > "Phuc Dat Bich" was a hoax, but it probably would be allowed in Australia. > > I'm surprised that Spanish names are not affected. Consider a woman who goes > by > the personal name of Maria Teresa, whose father's first surname was García and > mother's first surname was Ramírez. Her name would therefore be Maria Teresa > García Ramírez. If she marries Elí Arroyo López, then she might change her > name > to Maria Teresa García Ramírez de Arroyo. With six words, that would fall foul > of Facebook's foul naming policy. > > > http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > > > -- > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list In Spain "de Arroyo" officially does not become part of the name. The same applies to other countries as well. Not 100% sure that it is true in every Spanish speaking country though. Best -- https://mail.python.org/mailman/listinfo/python-list
TypeError: unorderable types: function() < int()
I have created a program in class 'make a game that tests how good people are
at guessing when 10 seconds has elapsed.'
The following are the code I currently have and the error produced when I
attempt to run it. I have tried everything I can think of to resolve the issue,
and I have also run the code through a checker, which has said that there are
no mistakes. I have also shown a friend who is a programmer, and he cannot find
a problem with it. The teacher doesn't actually know the solution to the
problem so I was wondering if someone could point me in the right direction to
get this working please?
import time
def second(int):
time.strftime("%S")
start = input('Press enter when you are ready to start')
time1 = time.strftime("%S")
then = time.time()
end = input('Press enter when you think 10 seconds has passed')
time2 = time.strftime("%S")
def totaltime(int):
(time2-time1)
if totaltime == '10':
print ('YOU ACTUALLY DID IT')
if totaltime < 10:
print ('Haha you took too long! Your result was:', totaltime,'seconds')
if totaltime > 10:
print('Too early TRY AGAIN! Your result was:', totaltime, 'seconds')
Press enter when you are ready to start
Press enter when you think 10 seconds has passed
Traceback (most recent call last):
File "E:/Computing/Python/Little book of challenges/Challenge 6 10 seconds
experiment.py", line 20, in
if totaltime < 10:
TypeError: unorderable types: function() < int()
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unorderable types: function() < int()
George Molsom writes: > I have created a program in class 'make a game that tests how good > people are at guessing when 10 seconds has elapsed.' Welcome! You may want to join the dedicated beginners forum https://mail.python.org/mailman/listinfo/tutor> where we collaboratively teach foundational Python concepts. > Traceback (most recent call last): > File "E:/Computing/Python/Little book of challenges/Challenge 6 10 seconds > experiment.py", line 20, in > if totaltime < 10: > TypeError: unorderable types: function() < int() That's right. The ‘totaltime’ name refers to a function. To ask whether an integer object is less than a function object is not a meaningful comparison. If you want to *call* the function, use the “call this function” syntax:: totaltime() That will evaluate to the return value when you call it, so use the return value:: if totaltime() < 10: # … -- \ “There's a certain part of the contented majority who love | `\anybody who is worth a billion dollars.” —John Kenneth | _o__)Galbraith, 1992-05-23 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix pyOpenSSL Distribution 0.13.15
ANNOUNCING eGenix.com pyOpenSSL Distribution Version 0.13.15 An easy-to-install and easy-to-use distribution of the pyOpenSSL Python interface for OpenSSL - available for Windows, Mac OS X and Unix platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-pyOpenSSL-Distribution-0.13.15.html INTRODUCTION The eGenix.com pyOpenSSL Distribution includes everything you need to get started with SSL in Python. It comes with an easy-to-use installer that includes the most recent OpenSSL library versions in pre-compiled form, making your application independent of OS provided OpenSSL libraries: http://www.egenix.com/products/python/pyOpenSSL/ pyOpenSSL is an open-source Python add-on that allows writing SSL/TLS- aware network applications as well as certificate management tools: https://launchpad.net/pyopenssl/ OpenSSL is an open-source implementation of the SSL/TLS protocol: http://www.openssl.org/ NEWS This new release of the eGenix.com pyOpenSSL Distribution includes the following updates: New in OpenSSL -- * Switched the included OpenSSL libraries to 1.0.2h. The OpenSSL 1.0.2 branch will receive long term support (LTS), so is an ideal basis for development. See https://openssl.org/news/secadv/20160503.txt for a complete list of security fixes in 1.0.2h. The following fixes are relevant for pyOpenSSL applications: - CVE-2016-2108 Two bugs in the ASN.1 parser were found which could cause memory corruption issues. - CVE-2016-2107 A MITM attacker can use a padding oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server support AES-NI. This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). - Several low priority issues were fixed as well. * Updated the Mozilla CA root bundle to version 2016-04-16. Please see the product changelog for the full set of changes. http://www.egenix.com/products/python/pyOpenSSL/changelog.html pyOpenSSL / OpenSSL Binaries Included - In addition to providing sources, we make binaries available that include both pyOpenSSL and the necessary OpenSSL libraries for all supported platforms: Windows, Linux, Mac OS X and FreeBSD, for x86 and x64. To simplify installation, we have uploaded a web installer to PyPI which will automatically choose the right binary for your platform, so a simple pip install egenix-pyopenssl will get you the package with OpenSSL libraries installed. Please see our installation instructions for details: http://www.egenix.com/products/python/pyOpenSSL/#Installation We have also added .egg-file distribution versions of our eGenix.com pyOpenSSL Distribution for Windows, Linux and Mac OS X to the available download options. These make setups using e.g. zc.buildout and other egg-file based installers a lot easier. DOWNLOADS The download archives and instructions for installing the package can be found at: http://www.egenix.com/products/python/pyOpenSSL/ UPGRADING Before installing this version of pyOpenSSL, please make sure that you uninstall any previously installed pyOpenSSL version. Otherwise, you could end up not using the included OpenSSL libs. ___ SUPPORT Commercial support for these packages is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. MORE INFORMATION For more information about the eGenix pyOpenSSL Distribution, licensing and download instructions, please visit our web-site or write to sa...@egenix.com. About eGenix (http://www.egenix.com/): eGenix is a Python software project, consulting and product company delivering expert services and professional quality products for companies, Python users and developers. We specialize in database driven applications, large scale software designs and integration. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 10 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
Re: pygame easy create
On Tuesday, May 10, 2016 at 10:51:58 AM UTC+5:30, hariram...@gmail.com wrote: > On Monday, May 9, 2016 at 11:12:47 PM UTC+5:30, sohca...@gmail.com wrote: > > On Monday, May 9, 2016 at 3:15:45 AM UTC-7, hariram...@gmail.com wrote: > > > On Monday, May 9, 2016 at 10:50:47 AM UTC+5:30, hariram...@gmail.com > > > wrote: > > > > is there anyway (IDE/package) that allows me to create graphics/game > > > > just like that (by instructing..., if i say create hills on the screen, > > > > it should generate pygame code)Anyway :) :) > > > > > > Atleast i tried with pyglet,felt that it will be easier than pygame. > > > still again throwing me error some GL is missed, why they wont be > > > straight forward in working if we select the env we have... > > > > > > some sites says 2.7 and >=3(3.4+) will have pip module by default, but i > > > am using 3.4.3 where i dont have pip and also tried python get-pip.py > > > which also not worked.. > > > > "still again throwing me error some GL is missed" > > > > Can you say *EXACTLY* what the error is? And can you copy/paste the > > relevant lines of code that lead to that error? > > > > Also, judging from your other messages, it looks like you might be needing > > to read the Python or PyGame tutorials. Programming is problem solving. > > You can't just saying "Draw a hill" and PyGame (or whatever module you're > > using) will draw a hill. You need to write code that describes how to draw > > a hill. > > yeah coding is a problem solving as you said, its right but i have asked any > utility is there for easy design in the same fashion > > okay can you answser my question, using python modules (pygame/pyglet > whatever it may be) can we design games with higher graphics (like world of > tanks, freedom fighter, mission impossible:rouge nation, contract killer > etc) Traceback (most recent call last): File "./pyg.py", line 6, in window = pyglet.window.Window() File "_build/bdist.linux-x86_64/egg/pyglet/__init__.py", line 357, in __getattr__ File "_build/bdist.linux-x86_64/egg/pyglet/window/__init__.py", line 133, in File "_build/bdist.linux-x86_64/egg/pyglet/gl/__init__.py", line 97, in File "_build/bdist.linux-x86_64/egg/pyglet/gl/lib.py", line 142, in File "_build/bdist.linux-x86_64/egg/pyglet/gl/lib_glx.py", line 50, in File "_build/bdist.linux-x86_64/egg/pyglet/lib.py", line 160, in load_library ImportError: Library "GL" not found. -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unorderable types: function() < int()
On Tue, May 10, 2016 at 10:19 PM, Dennis Lee Bieber
wrote:
> You invoke strftime() [in default: use current time mode], but pass it
> a format that is not defined in the documentation (or wasn't in Python 2.7
> which I'm still running). #2
> %s (lowercase) formats the seconds field of the time of day. And worst,
> since you don't return the result, it just gets thrown away.#3
>
Sorry to nitpick, but this isn't the case. time.strftime("%S") is what
you're talking about (getting the "seconds since beginning of current
minute"). There is a "%s" format string, but it's not supported on all
platforms; it actually would be more useful here, as it represents the
time as seconds since 1970 (aka "Unix time").
Of course, time.time() would still be far more useful here, as you
subsequently recommended.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unorderable types: function() < int()
Hello George, and welcome!
On Tue, 10 May 2016 07:01 pm, George Molsom wrote:
> I have created a program in class 'make a game that tests how good people
> are at guessing when 10 seconds has elapsed.'
>
> The following are the code I currently have and the error produced when I
> attempt to run it. I have tried everything I can think of to resolve the
> issue, and I have also run the code through a checker, which has said that
> there are no mistakes. I have also shown a friend who is a programmer, and
> he cannot find a problem with it. The teacher doesn't actually know the
> solution to the problem so I was wondering if someone could point me in
> the right direction to get this working please?
Neither your friend who is a programmer nor the teacher can read an error
message?
> TypeError: unorderable types: function() < int()
In fairness, it is a bit of a rubbish error message. But what is it saying
it that you are trying to check whether a function is less than a number.
You are not comparing the *result* of calling the function with the number,
but the function itself.
For example, suppose we have a function that (to keep it simple) always
returns 3.
def func():
return 3
Now you go to check whether it is less than some other number:
if func() < 9:
print("smaller")
That's what you *meant* to do, but unfortunately you left off the round
brackets (parentheses), which means that instead of calling the function
and then comparing the result of that with 9, you compare the FUNCTION
itself with 9.
if func < 9: ...
Obviously this is nonsense. You can't compare functions with integers, the
question is ludicrous. So Python rightly complains with an error message.
The immediate fix is to add the brackets in so that you call the function
first to get a result, and then compare the result with the number.
Another comment about your game:
You are asking the player to hit enter at 10 seconds. *Exactly* ten seconds.
The computer can measure time to well under a millionth of a second, I'm
pretty sure that nobody, no matter how skillful, can be expected to hit
enter after exactly 10.00 seconds, not 10.01 or 9.99 seconds.
I think it is reasonable to give them a little bit of slack to be above or
under 10 seconds by a fraction of a second. So you should round the time to
one decimal place:
totaltime = round(totaltime, 1)
before checking whether it is equal to 10.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unorderable types: function() < int()
On Tue, May 10, 2016 at 11:40 PM, Steven D'Aprano wrote: > You are asking the player to hit enter at 10 seconds. *Exactly* ten seconds. > The computer can measure time to well under a millionth of a second, I'm > pretty sure that nobody, no matter how skillful, can be expected to hit > enter after exactly 10.00 seconds, not 10.01 or 9.99 seconds. > But the times were being calculated at one-second resolution, which solves that but raises its own issues. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On Sunday, May 8, 2016 at 4:41:02 AM UTC+3, Terry Reedy wrote: > On 5/7/2016 3:17 PM, Christopher Reimer wrote: > > > For my purposes, I'm using the list comprehension over filter to keep > > pylint happy. > > How sad. The pylint developers arrogantly take it on themselves to > revise Python, against the wishes of Guido and the other core > developers, and you and feel obligated to follow them. > > They should at least add a disclaimer "Using the default options, pylint > checks that your code complies with the pylint-approved subset of Python." > > -- > Terry Jan Reedy Hi, Thank you for letting us know. While pylint is indeed opinionated in some cases, we're not trying to be "arrogant", as you put it, towards Guido or the other core developers. What's sad in this particular case is that the feedback had to come in rather a harsh manner, on this group, instead of being reported as a bug or an enhancement on pylint's bug tracker. Anyway, I wanted to tell you that I agree with your opinion regarding that message and as such, it is removed and won't be emitted anymore in the next release (1.6) Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unorderable types: function() < int()
On Tue, 10 May 2016 11:47 pm, Chris Angelico wrote:
> On Tue, May 10, 2016 at 11:40 PM, Steven D'Aprano
> wrote:
>> You are asking the player to hit enter at 10 seconds. *Exactly* ten
>> seconds. The computer can measure time to well under a millionth of a
>> second, I'm pretty sure that nobody, no matter how skillful, can be
>> expected to hit enter after exactly 10.00 seconds, not 10.01 or
>> 9.99 seconds.
>>
>
> But the times were being calculated at one-second resolution, which
> solves that but raises its own issues.
Ah, I didn't realise that time.strftime("%S") was one-second resolution
(obvious in hindsight, duh!) and the call to time.time() is apparently
unused.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
Hi Claudiu, On Tue, 10 May 2016 11:51 pm, Claudiu Popa wrote: > Thank you for letting us know. While pylint is indeed > opinionated in some cases, we're not trying to be > "arrogant", as you put it, towards Guido or the other core > developers. What's sad in this particular case is that the > feedback had to come in rather a harsh manner, on this group, > instead of being reported as a bug or an enhancement on pylint's > bug tracker. > > Anyway, I wanted to tell you that I agree with your opinion > regarding that message and as such, it is removed and won't be > emitted anymore in the next release (1.6) Thanks for being so understanding! Speaking for myself, I think that the test for filter versus list comprehensions is a reasonable test to include, so long as it is disabled by default. Does PyLint support opt-in checks? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
A further comment: On Tue, 10 May 2016 11:51 pm, Claudiu Popa wrote: > Thank you for letting us know. While pylint is indeed > opinionated in some cases, we're not trying to be > "arrogant", And from the docs: "What Pylint says is not to be taken as gospel and Pylint isn’t smarter than you are: it may warn you about things that you have conscientiously done." https://docs.pylint.org/intro.html#what-pylint-is-not which has some nice advice for how to deal with pylint so the warnings are not overwhelming. I think it is time for me to check it out... -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On Tuesday, May 10, 2016 at 5:58:37 PM UTC+3, Steven D'Aprano wrote: > Hi Claudiu, > > > On Tue, 10 May 2016 11:51 pm, Claudiu Popa wrote: > > > Thank you for letting us know. While pylint is indeed > > opinionated in some cases, we're not trying to be > > "arrogant", as you put it, towards Guido or the other core > > developers. What's sad in this particular case is that the > > feedback had to come in rather a harsh manner, on this group, > > instead of being reported as a bug or an enhancement on pylint's > > bug tracker. > > > > Anyway, I wanted to tell you that I agree with your opinion > > regarding that message and as such, it is removed and won't be > > emitted anymore in the next release (1.6) > > Thanks for being so understanding! > > Speaking for myself, I think that the test for filter versus list > comprehensions is a reasonable test to include, so long as it is disabled > by default. Does PyLint support opt-in checks? > > > > -- > Steven Hi Steven, Yes, pylint is pretty configurable regarding its checks. First of all, we have extensions, which are checks which were found unsuitable to be part of the core, thus they need to be manually activated, as in: $ pylint --load-plugins=pylint.extensions.name_of_the_extension We also have a group of checks that are disabled by default, as is the case of the Python 3 porting checker, recommended as well by the Python 3 porting guide (https://docs.python.org/3/howto/pyporting.html?highlight=pylint) These needs to be enabled manually, as in: $ pylint --enable=python3 $ pylint --enable=other_disabled_group Last, but not least, each check can be (de)activated manually: $ pylint --disable=no-member # don't care about conventions and refactoring warnings $ pylint --disable=C,R $ pylint --disable=all --enable=no-member,other_check_I_want The bad-builtin check is now an extension, so using the first case would enable it. Another thing that is going to change with the next release is the introduction of tiers. Basically, pylint overwhelms the user right now with its enabled checks and we're trying to split these into tiers, as seen in the following: $ pylint myproject # core checkers enabled 10/10 - Congrats, you're clean on a core. You might try with "--pedantic" now. $ pylint myproject --pedantic # pedantic checkers enabled. 10/10 - Congrats, you're clean on pedantic. You might try with --refactoring now $ pylint myproject --refactoring # refactoring checkers enabled 10/10 - Congrats, you're clean on refactoring. Last up, try with --style now. $ pylint myproject --style 10/10 - Now you're pylint clean. Or running them all: $ pylint myproject --all (The discussion and whatnot can be found here https://github.com/PyCQA/pylint/issues/746) -- https://mail.python.org/mailman/listinfo/python-list
What should a decorator do if an attribute already exists?
I have a decorator that adds an attribute to the decorated function: def decorate(func): instrument = make_instrument() @functools.wraps(func) def inner(*args): instrument.start() result = func(*args) instrument.finish() return result inner.instrument = instrument return inner The actual nature of the instrumentation isn't important: depending on the decorator, it might count the number of function calls made, how long it takes, count cache hits, or something else. My question is, what should I do if the decorated function already has an instrument attribute? 1. raise an exception? 2. raise a warning, and over-write the attribute? 3. raise a warning, and skip adding the attribute? 4. raise a warning, and rename the existing instrument to something else before writing my own instrument? 5. silently over-write the attribute? I think 5 is clearly wrong, 4 is too difficult, and 3 seems pointless. So I think either 1 or 2 is the right thing to do. Thoughts? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What should a decorator do if an attribute already exists?
On Tue, May 10, 2016, at 08:45 AM, Steven D'Aprano wrote: > I have a decorator that adds an attribute to the decorated function: > [...] > My question is, what should I do if the decorated function already has an > instrument attribute? > > 1. raise an exception? This. Your decorator should, IMHO, treat the attribute as private data, and if something else is using the same thing, something has clearly gone wrong and raising the error early and clearly is right. -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On 5/9/2016 3:53 AM, Steven D'Aprano wrote:
On Monday 09 May 2016 09:10, DFS wrote:
sSQL = "line 1\n"
sSQL += "line 2\n"
sSQL += "line 3"
Pointlessly provocative subject line edited.
huh? You called yourself a "master crafts/wo/man".
--
DFS: "python is awesome, but too many options for doing the same thing
also makes it difficult. For me, anyway."
DuhPricko: "That's the difference between a master and an apprentice.
The apprentice likes to follow fixed steps the same way each time. The
master craftsman knows her tools backwards, and can choose the right
tool for the job, and when the choice of tool really doesn't matter and
you can use whatever happens to be the closest to hand."
--
Since all three lines are constants know by the programmer at the time the
source code is written, it should be written as:
sSQL = """line 1
line 2
line 3"""
Or if you prefer:
sSQL = "line 1\nline 2\nline 3"
Or even:
sSQL = ("line 1\n"
"line 2\n"
"line 3")
taking advantage of Python's compile-time implicit concatenation of string
constants.
or
sSQL = "line 1\n" \
"line 2\n" \
"line 3"
But no, "master", your answers are incorrect. What's wrong with that
concat statement is that += concatenation is frowned upon by python's
creator, and is not recommended (in PEP8):
Code should be written in a way that does not disadvantage other
implementations of Python (PyPy, Jython, IronPython, Cython, Psyco, and
such).
For example, do not rely on CPython's efficient implementation of
in-place string concatenation for statements in the form a += b or a = a
+ b . This optimization is fragile even in CPython (it only works for
some types) and isn't present at all in implementations that don't use
refcounting. In performance sensitive parts of the library, the
''.join() form should be used instead. This will ensure that
concatenation occurs in linear time across various implementations.
https://www.python.org/dev/peps/pep-0008/#programming-recommendations
'master craftswoman' my ass...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Tue, May 10, 2016, at 09:16 AM, DFS wrote:
> But no, "master", your answers are incorrect. What's wrong with that
> concat statement is that += concatenation is frowned upon by python's
> creator, and is not recommended (in PEP8):
>
>
> Code should be written in a way that does not disadvantage other
> implementations of Python (PyPy, Jython, IronPython, Cython, Psyco, and
> such).
>
> For example, do not rely on CPython's efficient implementation of
> in-place string concatenation for statements in the form a += b or a = a
> + b . This optimization is fragile even in CPython (it only works for
> some types) and isn't present at all in implementations that don't use
> refcounting. In performance sensitive parts of the library, the
> ''.join() form should be used instead. This will ensure that
> concatenation occurs in linear time across various implementations.
>
You once again misread PEP8.
Not one of Steven's answers used string concatenation, except for the
implicit literal concatenation, which all other implementations support.
Note:
> sSQL = """line 1
> line 2
> line 3"""
No concatenation. One string literal. Works in all implementations.
> sSQL = "line 1\nline 2\nline 3"
No concatenation. One string literal. Works in all implementations.
>
> sSQL = ("line 1\n"
> "line 2\n"
> "line 3")
Concatenation occurs at compile time, implicitly. Works in all
implementations.
The PEP says when building a string dynamically (that is, adding
together two strings that exist and are separate), use "".join() in
performance sensitive places. It says don't combine two strings with the
addition operator -- because while that's sometimes efficient in
CPython, the language doesn't guarantee it.
You'll notice that the one time Steven combined two strings, it was
implicitly at compile time.
In every Python implementation, it is guaranteed that:
>>> a = "a" "a"
>>> b = "aa"
Are the same. Two+ string literals are implicitly combined into one at
compile time.
> 'master craftswoman' my ass...
Yes, you're being that. Please stop.
--
Stephen Hansen
m e @ i x o k a i . i o
--
https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Tuesday, May 10, 2016 at 9:46:45 PM UTC+5:30, DFS wrote: > On 5/9/2016 3:53 AM, Steven D'Aprano wrote: > > On Monday 09 May 2016 09:10, DFS wrote: > > > >> sSQL = "line 1\n" > >> sSQL += "line 2\n" > >> sSQL += "line 3" > > > > Pointlessly provocative subject line edited. > > > huh? You called yourself a "master crafts/wo/man". > > > DuhPricko: > > > But no, "master", your answers are incorrect. What's wrong with that > 'master craftswoman' my ass... You do a good job This your teacher? https://www.youtube.com/watch?v=FMEe7JqBgvg -- https://mail.python.org/mailman/listinfo/python-list
Re: What should a decorator do if an attribute already exists?
Steven D'Aprano wrote: > I have a decorator that adds an attribute to the decorated function: > > > def decorate(func): > instrument = make_instrument() > > @functools.wraps(func) > def inner(*args): > instrument.start() > result = func(*args) > instrument.finish() > return result > >inner.instrument = instrument >return inner > > > The actual nature of the instrumentation isn't important: depending on the > decorator, it might count the number of function calls made, how long it > takes, count cache hits, or something else. > > My question is, what should I do if the decorated function already has an > instrument attribute? > > 1. raise an exception? > > 2. raise a warning, and over-write the attribute? > 3. raise a warning, and skip adding the attribute? > 4. raise a warning, and rename the existing instrument to >something else before writing my own instrument? > > 5. silently over-write the attribute? > > > I think 5 is clearly wrong, 4 is too difficult, and 3 seems pointless. So > I think either 1 or 2 is the right thing to do. > > Thoughts? Silently overwrite it. For @decorate @decorate def f(): pass the original instrument is still accessible as f.__wrapped__.instrument, so 5 is the easy way to get 4. -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Wed, 11 May 2016 02:16 am, DFS wrote: > huh? You called yourself a "master crafts/wo/man". [...] > DuhPricko *plonk* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What should a decorator do if an attribute already exists?
On 2016-05-10 17:06, Stephen Hansen wrote: On Tue, May 10, 2016, at 08:45 AM, Steven D'Aprano wrote: I have a decorator that adds an attribute to the decorated function: [...] My question is, what should I do if the decorated function already has an instrument attribute? 1. raise an exception? This. Your decorator should, IMHO, treat the attribute as private data, and if something else is using the same thing, something has clearly gone wrong and raising the error early and clearly is right. If it's not clear what you should do, you could look at the Zen. It says: "In the face of ambiguity, refuse the temptation to guess." To me, that suggests raising an exception. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should a decorator do if an attribute already exists?
On 05/10/2016 08:45 AM, Steven D'Aprano wrote: I have a decorator that adds an attribute to the decorated function: My question is, what should I do if the decorated function already has an instrument attribute? If the decorator is adding an attribute for the decorated thing to use, and that thing may already have the correct attribute, do nothing; otherwise, raise an exception. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: An educational site written in Python (from YCombinator's RFS)
On Tuesday, May 10, 2016 at 2:13:42 AM UTC-4, Cai Gengyang wrote: > > EDUCATION > > If we can fix education, we can eventually do everything else on this list. > The first attempts to use technology to fix education have focused on using > the Internet to distribute traditional content to a wider audience. This is > good, but the Internet is a fundamentally different medium and capable of > much more. > > Solutions that combine the mass scale of technology with one-on-one in-person > interaction are particularly interesting to us. > > This may not require a "breakthrough" technology in the classical sense, but > at a minimum it will require very new ways of doing things. > > --- > > I want to create such a site using Python. What are the various steps I need > to take to create such a site ? This is a big project, but one that is worth > doing ... Any suggestions / help appreciated ? Thanks alot If you want to join an existing project, Open edX is open-source Python/Django, and powers edx.org and 250 other sites around the world. I'm guessing it isn't quite what this proposal is getting at, but the description here is very vague, so I'm not sure what they are getting at. http://open.edx.org if you want to take a look. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
The irony
"There should be one-- and preferably only one --obvious way to do it."
https://www.python.org/dev/peps/pep-0020/
---
sSQL = "line 1\n"
sSQL += "line 2\n"
sSQL += "line 3"
---
sSQL = ("line 1\n"
"line 2\n"
"line 3")
---
sSQL = "\n".join([
"line 1",
"line 2",
"line 3",
])
---
sSQL = """line 1
line 2
line 3"""
---
sSQL = """\
line 1
line 2
line 3"""
---
sSQL = "line 1\n" \
"line 2\n" \
"line 3"
---
Which is the "one obvious way" to do it?
I liked:
sSQL = "line 1\n"
sSQL += "line 2\n"
sSQL += "line 3"
but it's frowned upon in PEP8.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Tue, May 10, 2016 at 10:16 AM, DFS wrote: > On 5/9/2016 3:53 AM, Steven D'Aprano wrote: >> >> On Monday 09 May 2016 09:10, DFS wrote: >> >>> sSQL = "line 1\n" >>> sSQL += "line 2\n" >>> sSQL += "line 3" >> >> >> Pointlessly provocative subject line edited. > > > > huh? You called yourself a "master crafts/wo/man". Stop trolling. > -- > DFS: "python is awesome, but too many options for doing the same thing also > makes it difficult. For me, anyway." > > DuhPricko: "That's the difference between a master and an apprentice. The > apprentice likes to follow fixed steps the same way each time. The master > craftsman knows her tools backwards, and can choose the right tool for the > job, and when the choice of tool really doesn't matter and you can use > whatever happens to be the closest to hand." > -- So what, you're upset by the implication that you haven't already mastered Python when you apparently just started a couple months ago? Temper your expectations. > 'master craftswoman' my ass... Take your gender insults somewhere else. They're not welcome here. -- https://mail.python.org/mailman/listinfo/python-list
Re: The irony
On Tuesday, May 10, 2016 at 2:03:47 PM UTC-4, DFS wrote:
> Which is the "one obvious way" to do it?
>
> I liked:
>
> sSQL = "line 1\n"
> sSQL += "line 2\n"
> sSQL += "line 3"
>
>
> but it's frowned upon in PEP8.
I would use a way you didn't show:
sSQL = """
line1
line2
line3
"""
SQL doesn't mind the extra whitespace, so don't worry about the leading
spaces. If you really wanted to control it tightly, I would use (and have
used):
sSQL = textwrap.dedent("""\
line1
line2
line3
""")
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The irony
(interspersing letters to name your examples)
On 2016-05-10 14:03, DFS wrote:
A (nope)
> ---
> sSQL = "line 1\n"
> sSQL += "line 2\n"
> sSQL += "line 3"
B (see below)
> ---
> sSQL = ("line 1\n"
> "line 2\n"
> "line 3")
C (see below)
> ---
> sSQL = "\n".join([
> "line 1",
> "line 2",
> "line 3",
> ])
D (almost)
> ---
> sSQL = """line 1
> line 2
> line 3"""
E (almost)
> ---
> sSQL = """\
> line 1
> line 2
> line 3"""
F (not bad)
> ---
> sSQL = "line 1\n" \
> "line 2\n" \
> "line 3"
> Which is the "one obvious way" to do it?
Readability is one of Python's key strengths. I find my choice(s)
influenced by ease-of-reading and ease-of-editing (along with its
friend, ease-of-reading-diffs).
As leading indentation doesn't usually matter in SQL, I tend to just
use triple-quoted strings for all my SQL, formatting so it looks like
good SQL:
sql = """
SELECT
a.foo,
b.bar
FROM tblA a
INNER JOIN tblB b
ON a.id = b.a_id
WHERE
a.osteopathy > b.saturation
ORDER BY
b.monkey_balloon
"""
This does mean that there's a superfluous newline at the beginning &
end of the string and unneeded indentation for each line. But SQL
doesn't care, and if it had any noticeable performance issue (ooh, a
couple dozen extra bytes getting sent over the wire), it could be
post-processed to a clean one-liner.
That said, there are cases where the leading indentation does matter
to you, then I tend to use your "C" example for code executed once,
or a modification of B for code in loops:
sql = (
"line1\n"
"line2\n"
"line3"
)
(the difference being the newline after the open-paren to align all
the strings' starting offset)
If the redundancy of the "\n" characters became sufficiently
annoying, I'd define a constant (evaluated once, not in a loop) using
the "\n".join(...) method.
Seek the code that reads best for you and meets your needs.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: An educational site written in Python (from YCombinator's RFS)
On 5/10/2016 2:13 AM, Cai Gengyang wrote: Ok, so after reading YCombinator's RFS, I have decided that I want to work on this : --- EDUCATION If we can fix education, we can eventually do everything else on this list. The first attempts to use technology to fix education have focused on using the Internet to distribute traditional content to a wider audience. This is good, but the Internet is a fundamentally different medium and capable of much more. Solutions that combine the mass scale of technology with one-on-one in-person interaction are particularly interesting to us. one room, one teacher, one student, and one web browser? This may not require a "breakthrough" technology in the classical sense, but at a minimum it will require very new ways of doing things. --- I want to create such a site using Python. What are the various steps I need to take to create such a site ? This is a big project, but one that is worth doing ... Any suggestions / help appreciated ? Thanks alot When you say 'such a site' what do you envision? -- https://mail.python.org/mailman/listinfo/python-list
Re: json.loads(...) ValueError: Expecting value: line 1 column 1 (char 0)
That was it. Thanks guys for your help. Best regards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On 5/10/2016 9:51 AM, Claudiu Popa wrote: Thank you for letting us know. While pylint is indeed opinionated in some cases, we're not trying to be "arrogant", as you put it, towards Guido or the other core developers. What's sad in this particular case is that the feedback had to come in rather a harsh manner, on this group, instead of being reported as a bug or an enhancement on pylint's bug tracker. My impression is that the objection to 'bad builtin' was communicated somehow to someone involved with PyLint at least a year ago and ignored or outright rejected. But I don't remember details. I might be mistaken or have been given false information. Anyway, I wanted to tell you that I agree with your opinion regarding that message and as such, it is removed and won't be emitted anymore in the next release (1.6) Then my harsh comment re pylint is not currently valid. Thank you. Hiring managers misusing the score to evaluate applicants is a different issue. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On 5/10/2016 11:35 AM, pcmantic...@gmail.com wrote: The bad-builtin check is now an extension, so using the first case would enable it. The 'old' (not 'bad') builtin check should include using map instead of a comprehension. The check should also pay attention to whether the function argument is an existing function or a one newly created with a lambda expression. "'lambda' in " I think filter(None, iterable) (== filter(bool, iterable)) should be separately flagged as a style point. It is a hack that became unneeded when bool was added. Another thing that is going to change with the next release is the introduction of tiers. Basically, pylint overwhelms the user right now with its enabled checks and we're trying to split these into tiers, as seen in the following: This looks good. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On Wed, May 11, 2016 at 1:35 AM, wrote: > Basically, pylint overwhelms the user > right now with its enabled checks and we're trying to split these > into tiers, as seen in the following: > > $ pylint myproject > # core checkers enabled > 10/10 - Congrats, you're clean on a core. You might try with "--pedantic" > now. > > $ pylint myproject --pedantic > # pedantic checkers enabled. > 10/10 - Congrats, you're clean on pedantic. You might try with > --refactoring now > > $ pylint myproject --refactoring > # refactoring checkers enabled > 10/10 - Congrats, you're clean on refactoring. Last up, try with --style > now. > > $ pylint myproject --style > 10/10 - Now you're pylint clean. > > Or running them all: > > $ pylint myproject --all Definitely support this notion. Not sure the "on a core" part makes sense, but that's a minor triviality. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On 5/10/2016 3:34 PM, Terry Reedy wrote: On 5/10/2016 9:51 AM, Claudiu Popa wrote: Thank you for letting us know. While pylint is indeed opinionated in some cases, we're not trying to be "arrogant", as you put it, towards Guido or the other core developers. What's sad in this particular case is that the feedback had to come in rather a harsh manner, on this group, instead of being reported as a bug or an enhancement on pylint's bug tracker. My impression is that the objection to 'bad builtin' was communicated somehow to someone involved with PyLint at least a year ago and ignored or outright rejected. But I don't remember details. I might be mistaken or have been given false information. Anyway, I wanted to tell you that I agree with your opinion regarding that message and as such, it is removed and won't be emitted anymore in the next release (1.6) Then my harsh comment re pylint is not currently valid. Thank you. Hiring managers misusing the score to evaluate applicants is a different issue. Interesting. Got any horror stories to share? -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On 5/10/2016 2:15 PM, Ian Kelly wrote: On Tue, May 10, 2016 at 10:16 AM, DFS wrote: On 5/9/2016 3:53 AM, Steven D'Aprano wrote: On Monday 09 May 2016 09:10, DFS wrote: sSQL = "line 1\n" sSQL += "line 2\n" sSQL += "line 3" Pointlessly provocative subject line edited. huh? You called yourself a "master crafts/wo/man". Stop trolling. Challenging someone's boastful claim isn't trolling. -- DFS: "python is awesome, but too many options for doing the same thing also makes it difficult. For me, anyway." DuhPricko: "That's the difference between a master and an apprentice. The apprentice likes to follow fixed steps the same way each time. The master craftsman knows her tools backwards, and can choose the right tool for the job, and when the choice of tool really doesn't matter and you can use whatever happens to be the closest to hand." -- So what, you're upset by the implication that you haven't already mastered Python when you apparently just started a couple months ago? Temper your expectations. Of course that wasn't my expectation. That would be crazy... My expectation was to not be met by smug, sanctimonious and condescending replies from the likes of DuhPricko. 'master craftswoman' my ass... Take your gender insults somewhere else. They're not welcome here. Take your net-nannying somewhere else. It's not welcome /anywhere/. -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Wed, May 11, 2016 at 7:21 AM, DFS wrote: > Take your net-nannying somewhere else. It's not welcome /anywhere/. DFS, you are out of line. Please reconsider the *way* you are saying things, and especially, don't call people names. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On 05/10/2016 02:21 PM, DFS wrote: On 5/9/2016 3:53 AM, Steven D'Aprano wrote: Pointlessly provocative subject line edited. huh? You called yourself a "master crafts/wo/man". Challenging someone's boastful claim isn't trolling. My expectation was to not be met by smug, sanctimonious and condescending replies from the likes of DuhPricko. 'master craftswoman' my ass... Take your net-nannying somewhere else. It's not welcome /anywhere/. Having found and read D'Aprano's post I can assure you that: - he wasn't claiming to be a master craftsman - he wasn't being arrogant I can also assure you that *you* are being hostile, rude, and discriminatory, and such behaviour is not welcome here. Any further posts of this nature and you will be placed on moderation. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: The irony
On Tuesday, May 10, 2016 at 11:03:47 AM UTC-7, DFS wrote:
> "There should be one-- and preferably only one --obvious way to do it."
>
> https://www.python.org/dev/peps/pep-0020/
>
>
Each method of string concatenation has different uses.
> ---
> sSQL = "line 1\n"
> sSQL += "line 2\n"
> sSQL += "line 3"
This method is simple, easy to read, and is fine for cases where you're not
going to be concatenating more than a couple strings *AT RUN-TIME*.
> ---
> sSQL = ("line 1\n"
> "line 2\n"
> "line 3")
This performs implicit string concatenation *AT COMPILE TIME*. It doesn't work
if the strings you are putting together are variables.
> ---
> sSQL = "\n".join([
> "line 1",
> "line 2",
> "line 3",
> ])
This joins several strings (at run time) with a string separating them. Though
an empty string, comma, or a new line are the most common strings to use, you
can use any string.
> ---
> sSQL = """line 1
> line 2
> line 3"""
> ---
> sSQL = """\
> line 1
> line 2
> line 3"""
These two are effectively the same, sure. I'll give you that.
> ---
> sSQL = "line 1\n" \
> "line 2\n" \
> "line 3"
This is just implicit string concatenation and no real different than your
second option except you used the explicit line continuation character instead
of using the implicit line continuation created by using parentheses.
> ---
>
>
> Which is the "one obvious way" to do it?
> I liked:
>
> sSQL = "line 1\n"
> sSQL += "line 2\n"
> sSQL += "line 3"
>
>
> but it's frowned upon in PEP8.
It's frowned upon because it is incredibly slow when used a lot. Every time
you do a += on a string, it has to re-allocate memory, whereas other methods
either figure it out at compile time or figure out how much memory will be
needed and allocate it once.
--
https://mail.python.org/mailman/listinfo/python-list
Re: pylint woes
On 5/7/2016 10:50 PM, Chris Angelico wrote: On Sun, May 8, 2016 at 12:15 PM, DFS wrote: The only reason for j in range(len(list1)): do something with list1[j], list2[j], list3[j], etc. or for item1, item2, item3 in zip(list1, list2, list3): do something with the items works is because each list has the same number of items. Sure, but who cares what each item's position is? All that matters is that they have corresponding positions, which is what zip() does. They have corresponding positions because zip() possibly truncates data! Imagine you don't even have the whole lists yet. Imagine someone's still writing stuff to them as you work. Maybe they're infinite in length. You can't iterate up to the length of list1, because it doesn't HAVE a length. But you can still zip it up with other parallel collections, and iterate over them all. Disregarding a list of infinite length. If lists are still being created: * at every moment in time, len(list1) returns a length that doesn't change even if data is added to the list after the call to len(). Example: If the list has 100 items in it at the point len(list) is called: for i in range(len(list1)) will never iterate more than 100x, no matter how large list1 grows to. Caveat: since list1 may be bigger or smaller than the other lists at that moment in time, an error may occur when using list2[i], list3[i]. Is that all correct as you understand it? * at every moment in time, zip(list1, list2, etc) will return a fixed, same-length lists of tuples, which doesn't change even if data is added to any of the lists after the call to zip(). Example: if the lists have 100, 97 and 102 items in them at the point zip(lists) is called: for item1, item2, item3 in zip(list1, list2, list3) will never iterate beyond 97x, even if the lists grow while the enumeration is occurring. Caveat: since zip() possibly truncates lists, the results - the usage of the data - could be completely invalid. Is that all correct as you understand it? So, if that's all correct, it doesn't matter whether you use 'for i in range(len(lists))' or 'for item in zip(lists)': neither will guarantee data integrity. I haven't timed them, but as I see it, neither has a definite advantage over the other. So what I decided to do was build the lists, check that the lengths are all the same (exit the program if not), zip() them, and use enumeration because it looks less a little less clunky. I see no advantage beyond appearance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On 05/10/2016 02:21 PM, DFS wrote: [some inflammatory nonsense] and is now being moderated. If you see flame-bait in one of the unmoderated venues please ignore it. Thanks. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: What should a decorator do if an attribute already exists?
On Tue, May 10, 2016 at 11:48 AM Peter Otten <__pete...@web.de> wrote: > Steven D'Aprano wrote: > > I have a decorator that adds an attribute to the decorated function: > >inner.instrument = instrument > >return inner > > the original instrument is still accessible as f.__wrapped__.instrument I'd say Peter's example is Option 6: Wrap the instrumented function with a second instrumented wrapper. Since you have various kinds of instruments, silently adding another layer makes sense to me. Is it OK if the order matters? Will some of the instruments get confused because they're working on a wrapper instead of the original function? -- https://mail.python.org/mailman/listinfo/python-list
Re: python - handling HTTP requests asynchronously
On Sat, May 7, 2016 at 4:46 PM wrote: > Il giorno sabato 7 maggio 2016 21:04:47 UTC+2, Michael Selik ha scritto: > > On Fri, May 6, 2016 at 3:01 AM wrote: > > > > > The PDF is generated through an external API. Since currently is > generated > > > on demand, this is handled synchronously via an HTTP request/response. > > > > > > Are you sending the request or are you receiving the request? > > If you are sending, you can just use threads as you are only doing IO. > > If you are receiving the requests and generating PDFs, you may want to > use > > subprocesses if the PDF-generation is compute-intensive. > > > > > > > 3) multiprocessing module, with e.g. 10 as workers limit. > > > > > > > multiprocessing.Pool is an easy way to use subprocesses > > multiprocessing.pool.ThreadPool is an easy way to use threads. It's not > > well documented, but has the exact same interface as Pool. > > > > the goal is to use the API concurrently (e.g. send 10 or 100 http > requests > > > simultaneously, depending on how many concurrent requests the API can > > > handle). > > > > > > > Sounds like you want to use threads. How does the API let you know you're > > hitting it too frequently? Perhaps you want to code an exponential > backoff > > and retry wrapper for your API requests. > > Thanks for the reply. > Currently the django view that does the job does three http request: > - the first does a POST and send the payload used during the PDF > rendering, the response contains a url to check the pdf generation progress; > - the second loop over that url, checking the progress of pdf generation. > Once the response contains the keyword 'status': 'complete', then it give > also a url for the file retrieval; > - the third one is a GET to retrieve the file, the reponse contains the > binary content of the file, then this content is read and wrapped as > attachment of a django http response, and then returned to the user. > > the goal is to reuse the existing code as much as possible, possibly doing > concurrently, and saving the file instead on a folder. > I'm not a Django expert. Does the Django View require all that stuff to happen before Django can send an HTTP Response back to the user? If so, I suggest you respond to the user immediately: "now generating a bunch of PDFs..." and take care of the rest in the background. Perhaps just write to a file, database, or message queue the info for the PDFs to generate. Have a separate program periodically read the file, database, or message queue to do that work and then maybe email the user when it's completed. -- https://mail.python.org/mailman/listinfo/python-list
Re: String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)
On Sunday, May 8, 2016 at 5:44:25 PM UTC-7, Thomas 'PointedEars' Lahn wrote: > Also, it would be a good idea if you posted under your real name. Internet > is the thing with cables; Usenet is the thing with people. I for one tend > to avoid communicating with few-letter entities; exceptions to that would > probably include only E.T., M.J., ALF, and K.I.T.T. > > -- > PointedEars > > Twitter: @PointedEars2 > Please do not cc me. / Bitte keine Kopien per E-Mail. I don't blame people for not wanting to use their real name on the Internet, especially if you're a woman. There are a lot of crazy people out there that will find out where you live and send death threats just because you disagree with them or you happen to be a woman that enjoys video games or exists in the tech world. -- https://mail.python.org/mailman/listinfo/python-list
Re: pylint woes
On 2016-05-10 23:36, DFS wrote: [snip] If lists are still being created: * at every moment in time, len(list1) returns a length that doesn't change even if data is added to the list after the call to len(). Example: If the list has 100 items in it at the point len(list) is called: for i in range(len(list1)) will never iterate more than 100x, no matter how large list1 grows to. Caveat: since list1 may be bigger or smaller than the other lists at that moment in time, an error may occur when using list2[i], list3[i]. Is that all correct as you understand it? Yes. * at every moment in time, zip(list1, list2, etc) will return a fixed, same-length lists of tuples, which doesn't change even if data is added to any of the lists after the call to zip(). Example: if the lists have 100, 97 and 102 items in them at the point zip(lists) is called: for item1, item2, item3 in zip(list1, list2, list3) will never iterate beyond 97x, even if the lists grow while the enumeration is occurring. Caveat: since zip() possibly truncates lists, the results - the usage of the data - could be completely invalid. Is that all correct as you understand it? In Python 2, zip iterates through the arguments immediately and returns a list of tuples, so the answer is yes. In Python 3, zip returns a lazy iterator (like itertools.izip in Python 2) that gets the values from the arguments _on demand_, so the answer is no. [snip] -- https://mail.python.org/mailman/listinfo/python-list
Moderation [was Re: ...What's wrong with this concatenation statement?]
On Wed, 11 May 2016 10:16 am, Thomas 'PointedEars' Lahn wrote: > (Note to moderators: But you have let *this* through, huh?) Moderation only affects the mailing list python-list@python.org, the Usenet mirror remains unmoderated. If you are reading this via Usenet, you may see DFS's insults, but it doesn't appear here: https://mail.python.org/pipermail/python-list/2016-May/thread.html -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
DFS wrote:
> On 5/8/2016 8:44 PM, Thomas 'PointedEars' Lahn wrote:
>> DFS wrote:
>>> sSQL = "line 1\n"
>>> sSQL += "line 2\n"
>>> sSQL += "line 3"
>>
>> […]
>> #---
>> sSQL = ("line 1\n"
>> "line 2\n"
>> "line 3")
>> #---
>>
>> […]
>
> or
>
> sSQL = "line 1\n" \
> "line 2\n" \
> "line 3"
>
Parentheses are less error-prone.
>> With the “%” string operator (deprecated),
>
> according to who?
TFM.
>> Next time, RTFM first:
>
>
> Ironically, PointyHead, […]
>
>> Internet is the thing with cables; Usenet is the thing with people. I
>> for one tend to avoid communicating with few-letter entities; exceptions
>> to that would probably include only E.T., M.J., ALF, and K.I.T.T.
>
> How about FU?
*PLONK*
(Note to moderators: But you have let *this* through, huh?)
.
.
.
.
.
.
.
.
.
.
.
.
.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
On Wed, May 11, 2016 at 10:16 AM, Thomas 'PointedEars' Lahn wrote: >>> With the “%” string operator (deprecated), >> >> according to who? > > TFM. [citation needed] ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Intel Distribution for Python
The Intel Distribution for Python 2017 Beta https://software.intel.com/en-us/python-distribution is available for Windows, Linux, and Mac OS for Python 2.7 and 3.5. "The Beta product adds new Python packages like scikit-learn, mpi4py, numba, conda, tbb (Python interfaces to Intel® Threading Building Blocks) and pyDAAL (Python interfaces to Intel® Data Analytics Acceleration Library). The Beta also delivers performance improvements for NumPy/SciPy through linking with performance libraries like Intel® MKL, Intel® Message Passing Interface (Intel® MPI), Intel® TBB and Intel® DAAL." I just installed Intel Python today. Has anyone tried it? Does it run your programs faster than the usual CPython? -- https://mail.python.org/mailman/listinfo/python-list
Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?
DFS writes: > But, I am dead serious about becoming a good Python developer, and I > truly appreciate all clp replies. People are more likely to reply to you if your posting style makes you enjoyable instead of annoying to engage with. That's community spirit. Friendly participation is always welcomed even when the person is new or otherwise not highly knowledgeable. Failing that, if you're a knowledgeable enough developer that people learn things from your posts even at moments when your style is annoying, they might interact with you for the self-interested sake of benefiting from access to your knowledge. There are some regulars here whose stuff is always worth reading even though they can be prickly at times. If you don't bring worthwhile amounts of knowledge AND your posting style is annoying, there's a considerable incentive to not bother reading your stuff at all. That will tend to decrease the amount of replies you receive. Hope this helps! -- https://mail.python.org/mailman/listinfo/python-list
Re: Intel Distribution for Python
On Wed, May 11, 2016 at 12:00 PM, beliavsky--- via Python-list wrote: > The Intel Distribution for Python 2017 Beta > https://software.intel.com/en-us/python-distribution is available for > Windows, Linux, and Mac OS for Python 2.7 and 3.5. > > "The Beta product adds new Python packages like scikit-learn, mpi4py, numba, > conda, tbb (Python interfaces to Intel® Threading Building Blocks) and pyDAAL > (Python interfaces to Intel® Data Analytics Acceleration Library). The Beta > also delivers performance improvements for NumPy/SciPy through linking with > performance libraries like Intel® MKL, Intel® Message Passing Interface > (Intel® MPI), Intel® TBB and Intel® DAAL." > > I just installed Intel Python today. Has anyone tried it? Does it run your > programs faster than the usual CPython? > I haven't used it, but based on a reading of their blurbs, I suspect you won't see any significant improvement in base Python code - the advantage is the numeric computation work. For general Python performance, check out PyPy, although it tends to lag behind CPython in versions somewhat. However, PyPy doesn't do anything for your numpy performance, and doesn't even guarantee that everything works: http://pypy.org/download.html#installing-numpy So if the Intel Math Kernel Library lives up to the descriptions, it might be the thing to fill in this gap - "use PyPy to speed up your Python code, or Intel Python to speed up your numpy code". (Most programs won't have performance issues on both of those at once.) It's worth noting that Intel engineers have been proposing a number of performance improvements for backporting into the CPython core, and some of them even made it into 2.7. I've no idea whether the page you linked to is part of the same project or not; it might be completely separate, or it might be the source of all those improvements. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Intel Distribution for Python
Thanks for the information, I just applied for program but I got one mail about license and expiration. This software license expires on October 29, 2016. I am not able to understand that can anyone put some light on that how license can be expired? -- https://mail.python.org/mailman/listinfo/python-list
Re: Intel Distribution for Python
On 5/10/2016 11:12 PM, Chris Angelico wrote: On Wed, May 11, 2016 at 12:00 PM, beliavsky--- via Python-list wrote: The Intel Distribution for Python 2017 Beta https://software.intel.com/en-us/python-distribution is available for Windows, Linux, and Mac OS for Python 2.7 and 3.5. "The Beta product adds new Python packages like scikit-learn, mpi4py, numba, conda, tbb (Python interfaces to Intel® Threading Building Blocks) and pyDAAL (Python interfaces to Intel® Data Analytics Acceleration Library). The Beta also delivers performance improvements for NumPy/SciPy through linking with performance libraries like Intel® MKL, Intel® Message Passing Interface (Intel® MPI), Intel® TBB and Intel® DAAL." I just installed Intel Python today. Has anyone tried it? Does it run your programs faster than the usual CPython? I haven't used it, but based on a reading of their blurbs, I suspect you won't see any significant improvement in base Python code - the advantage is the numeric computation work. All their benchmarks are heavy numeric computation. For general Python performance, check out PyPy, although it tends to lag behind CPython in versions somewhat. However, PyPy doesn't do anything for your numpy performance, and doesn't even guarantee that everything works: http://pypy.org/download.html#installing-numpy So if the Intel Math Kernel Library lives up to the descriptions, it might be the thing to fill in this gap - "use PyPy to speed up your Python code, or Intel Python to speed up your numpy code". (Most programs won't have performance issues on both of those at once.) It's worth noting that Intel engineers have been proposing a number of performance improvements for backporting into the CPython core, and some of them even made it into 2.7. I've no idea whether the page you linked to is part of the same project or not; it might be completely separate, or it might be the source of all those improvements. I presume it is all related. What I find interesting is that Intel thinks it will be more profitable to be involved in numerical computation driven by python than not to. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Intel Distribution for Python
On Wed, May 11, 2016 at 1:17 PM, Arshpreet Singh wrote:
> Thanks for the information, I just applied for program but I got one mail
> about license and expiration.
>
>
> This software license expires on October 29, 2016.
>
>
> I am not able to understand that can anyone put some light on that how
> license can be expired?
If I own something (say, a skillet that can fry your breakfast and
then clonk an intruder on the head), I can permit you to use it under
any terms I like. That includes putting a time limit on it ("you can
use it now, but I'll need it when I go to look at the floating
lights"). It's the same with software. The license terms are "Until
20161029, you may use this as long as blah blah blah, but after
20161029, you may not use this under any circumstances". A copyright
owner is free to put any restrictions on the use of the program; if
that prevents it from being useful to you, you're free to ignore the
program altogether.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Animations with mayavi and moviepy
The animation example below (taken from
http://zulko.github.io/blog/2014/11/29/data-animations-with-python-and-moviepy/)
stops after producing and displaying the 41 frames. In stead, after producing
the 41 frames I want to make it loop continuously. I have googled and googled
and googled and still not found out how to do it. I guess that it is very
simple but how?
The program prints out some rather uninteresting information - how can I
suppress that?
Poul Riis
import numpy as np
import mayavi.mlab as mlab
import moviepy.editor as mpy
duration= 2 # duration of the animation in seconds (it will loop)
# MAKE A FIGURE WITH MAYAVI
fig_myv = mlab.figure(size=(220,220), bgcolor=(1,1,1))
X, Y = np.linspace(-2,2,200), np.linspace(-2,2,200)
XX, YY = np.meshgrid(X,Y)
ZZ = lambda d: np.sinc(XX**2+YY**2)+np.sin(XX+d)
# ANIMATE THE FIGURE WITH MOVIEPY, WRITE AN ANIMATED GIF
def make_frame(t):
mlab.clf() # clear the figure (to reset the colors)
mlab.mesh(YY,XX,ZZ(2*np.pi*t/duration), figure=fig_myv)
return mlab.screenshot(antialiased=True)
animation = mpy.VideoClip(make_frame, duration=duration)
animation.write_gif("sinc.gif", fps=20)
--
https://mail.python.org/mailman/listinfo/python-list
