What is Application Context and Request Context in Flask and WerkZeug.
Hi, I am developing a web application using flask, Werkzeug and jinja2. I am very much confused with these terms and wanted to know the meaning of the terms and how they are interrelated to the CGI environment variables. What is global variable g and how it is related to the application context and request context. Also since I don't have much knowledge of developing web apps( I am doing it for first time) any another language also so there is another request if someone could give a reference or make me understand that how the requests are handled, i mean what happens when a request arrives to the web application. Also if i am not using any openID providers for logging in the user into my website, how can i make the password secure. Should i use any framework for that? Thanks, Norah Jones -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 07 Apr 2014 07:54:27 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : > >> On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote: >>> It is academic because the author, Raymond Smullyan, was a professor >>> of philosophy and, more importantly, my professor selected that as a >>> textbook for us graduate students. >> >> Ah. Well they do that, don't they? I've always consider the ability of >> professors to select their own book as text to be a classic case of >> conflict of interest. They're supposed to pick the best book, not >> necessarily the one that earns them money. > > Note that "my professor" above was not Raymond Smullyan. Ah! Sorry about that, I misread your post as implying he was your professor. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
In article , Chris Angelico wrote: > On Mon, Apr 7, 2014 at 1:48 PM, Roy Smith wrote: > > There is (or at least, was) another reason. Creating a new process used > > to be far more expensive than creating a new thread. In modern Unix > > kernels, however, the cost difference has become much less, so this is > > no longer a major issue. > > Unix maybe, but what about Windows? Is it efficient to create > processes under Windows? Whether something works well on Windows is really not something I worry about a lot. -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 10:26 PM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> On Mon, Apr 7, 2014 at 1:48 PM, Roy Smith wrote: >> > There is (or at least, was) another reason. Creating a new process used >> > to be far more expensive than creating a new thread. In modern Unix >> > kernels, however, the cost difference has become much less, so this is >> > no longer a major issue. >> >> Unix maybe, but what about Windows? Is it efficient to create >> processes under Windows? > > Whether something works well on Windows is really not something I worry > about a lot. It's a concern for some of us. Maybe one day supporting Windows will be like supporting Python 2.4 is now - something that only a few people do, and knowingly pay the complexity price for it - but for now, it's a fully-supported platform for a lot of Python software, so in a generic discussion, I'd say it's important to note it. Threading has NOT been entirely replaced with multiprocessing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
In article , Chris Angelico wrote: > On Mon, Apr 7, 2014 at 10:26 PM, Roy Smith wrote: > > Whether something works well on Windows is really not something I worry > > about a lot. > > It's a concern for some of us. You have my sympathy. > it's a fully-supported platform for a lot of Python software, so in a > generic discussion, I'd say it's important to note it. In all things technology related, there is an evolutionary path. It goes something like this: * bleeding edge * avant-garde * what the kewl kids are using * modern * mainstream * traditional * corporate standard * legacy * extended support * prehistoric I figure Windows (at least on the desktop) is legacy at this point. Or, in the case of XP (The Release That Wouldn't Die), extended support. I acknowledge it exists, and is still commercially important, and even has certain advantages, in the same way that I acknowledge the continued existence of incandescent light bulbs, POTS, C++, and film photography. I put threading in the same category. There are two major reasons for using threading: as an architectural pattern for doing non-blocking I/O, and to allow a program to take advantage of multiple processors in a single machine. Fortunately, we have figured out better ways to do both of those. The idea that we should continue to use threading just because Windows makes process creation hideously expensive compared to thread creation doesn't impress me as an argument in favor of threading. It impresses me as an argument in favor of ditching Windows. When I started using Python (1.4), it was somewhere around avant-garde. Now, I figure it's mainstream, which probably means it's time for me to move on to something else soon :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 07/04/2014 14:22, Roy Smith wrote: When I started using Python (1.4), it was somewhere around avant-garde. Now, I figure it's mainstream, which probably means it's time for me to move on to something else soon :-) Python 2.8? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Roy Smith : > The idea that we should continue to use threading just because Windows > makes process creation hideously expensive compared to thread creation > doesn't impress me as an argument in favor of threading. It impresses > me as an argument in favor of ditching Windows. There are many reasons to start processes or threads. One of them is performance (you have more than one CPU core). When performance is the objective, my rough guidelines would be: * Start your processes during initialization. * Start about twice as many processes as there are CPUs. IOW, the processes are there to exercise the CPUs and should not represent individual connections or other dynamic entities. I don't program for Windows, but that's the approach I would take under linux as well. Marko -- https://mail.python.org/mailman/listinfo/python-list
testfixtures 3.0.2 Released!
Hi All, I'm pleased to announce the release of testfixtures 3.0.2. This is a bug fix release featuring the following changes: - Document ShouldRaise.raised and make it part of the official API. - Fix rare failures when cleaning up TempDirectory instances on Windows. If you haven't bumped into it already, testfixtures is a collection of helpers for writing succinct unit tests including help for: - Comparing objects and sequences Better feedback when the results aren't as you expected along with support for comparison of objects that don't normally support comparison. - Mocking out objects and methods Easy to use ways of stubbing out objects, classes or individual methods for both doc tests and unit tests. Special helpers are provided for testing with dates and times. - Testing logging Helpers for capturing logging output in both doc tests and unit tests. - Testing stream output Helpers for capturing stream output, such as that from print statements, and making assertion about it. - Testing with files and directories Support for creating and checking files and directories in sandboxes for both doc tests and unit tests. - Testing exceptions Easy to use ways of checking that a certain exception is raised, even down the to the parameters the exception is raised with. The package is on PyPI and a full list of all the links to docs, issue trackers and the like can be found here: http://www.simplistix.co.uk/software/python/testfixtures Any questions, please do ask on the Testing in Python list or on the Simplistix open source mailing list... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 11:22 PM, Roy Smith wrote: > In all things technology related, there is an evolutionary path. It > goes something like this: > > * bleeding edge > * avant-garde > * what the kewl kids are using > * modern > * mainstream > * traditional > * corporate standard > * legacy > * extended support > * prehistoric > > I figure Windows (at least on the desktop) is legacy at this point. Or, > in the case of XP (The Release That Wouldn't Die), extended support. I > acknowledge it exists, and is still commercially important, and even has > certain advantages, in the same way that I acknowledge the continued > existence of incandescent light bulbs, POTS, C++, and film photography. And technologies can be, at the same time, at different points depending on where you look. To many people, OS/2 is prehistoric; to us, it's legacy. Incandescent light bulbs are legacy in a lot of places, but corporate standard in theatres (the modern replacement is LEDs, but their colors are distinctly different so you can't just pull out an incan and stick in an LED). Same goes for plenty of other technologies. To a lot of people, Windows is mainstream, and Linux is "what the non-cool kids are using", which doesn't exactly fit on your scale anywhere :) So if your audience is that sort of person, then to you Windows has to be considered mainstream or at least traditional, with Linux being the modern option that you're trying to push people onto. That's how I am with my MUD client. People use Windows, Mac OS, and Linux (plus various mobile devices, which I don't support); I'd like to push more people to Linux, but as a second-best, I can get them onto the same client that I'm developing on Linux, which minimizes the cross-platform development work. That's unlikely to change any time soon, so Windows support has to be a part of what I do. Doesn't mean I can't look with envy at projects that have dropped Windows support altogether and saved themselves a mess of trouble... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa wrote: > Roy Smith : > >> The idea that we should continue to use threading just because Windows >> makes process creation hideously expensive compared to thread creation >> doesn't impress me as an argument in favor of threading. It impresses >> me as an argument in favor of ditching Windows. > > There are many reasons to start processes or threads. One of them is > performance (you have more than one CPU core). When performance is the > objective, my rough guidelines would be: > > * Start your processes during initialization. > > * Start about twice as many processes as there are CPUs. > > IOW, the processes are there to exercise the CPUs and should not > represent individual connections or other dynamic entities. That's potentially brutal on a shared system! I hope it's controlled by an option, or that you do this only in something you're writing for yourself alone. There are other reasons for forking per connection, though, such as state cleanup. You can guarantee that each job is done in a consistent state if it's spawned from the exact same point in the master process every time. That can help enormously if you're allowing any sort of foreign code, even from a trusted programmer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing IDE 5.0.5 released
Hi, Wingware has released version 5.0.5 of Wing IDE, our cross-platform integrated development environment for the Python programming language. Wing IDE includes a professional quality code editor with vi, emacs, visual studio, and other key bindings, auto-completion, call tips, goto-definition, find uses, refactoring, context-aware auto-editing, a powerful graphical debugger, version control, unit testing, search, and many other features. For details see http://wingware.com/ Changes in this minor release include: * Preference to control auto-spacing inside argument lists * Palette color and preference for changing occurrences color * Detect and flag unit tests that crash before running to completion * Fix Compare to Repository with recent SVN versions * Syntax highlighting for .scss CSS extension language files * Fix scraping extension modules in recent numpy versions * Fixed restarting after patch installation * Fix auto-editor and auto-completion context detection problems in the shells * Correctly show PEP 287 docstrings when indentation causes parse errors * Expand fold points on any edited line to avoid inaccessible folded lines * Improve and clarify validation of Python Executable in Project Properties * Several color adjustment fixes * About 25 other bug fixes For details see http://wingware.com/pub/wingide/5.0.5/CHANGELOG.txt A summary of new features in Wing 5: * Redesigned GUI based on Qt and PySide * Native GUI on OS X (and better overall OS-native look and feel) * Tools and editors can be dragged around * Toolbar and editor and Project context menus are configurable * Optional mode that opens different sets of files in each editor split * Sharable color palettes and syntax highlighting configurations * Auto-editing is on by default (except some operations that have a learning curve) * Named file sets * Sharable launch configurations * Named entry points * More control over unit testing environment * Lockable editor splits * Initial preferences dialog for new users * Support for Python 3.4 * Support for Django 1.6 * Support for matplotlib on Anaconda and with MacOSX backend * Improved Source Assistant with PEP 287 docstring rendering and return types * Improved integrated and PDF documentation For more information on what's new in Wing 5, see http://wingware.com/wingide/whatsnew Free trial: http://wingware.com/wingide/trial Downloads: http://wingware.com/downloads Feature list: http://wingware.com/wingide/features Sales: http://wingware.com/store/purchase Upgrades: https://wingware.com/store/upgrade Questions? Don't hesitate to email us at [email protected]. Thanks, -- Stephan Deibel Wingware | Python IDE The Intelligent Development Environment for Python Programmers wingware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Chris Angelico : > On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa wrote: >> Roy Smith : >> IOW, the processes are there to exercise the CPUs and should not >> represent individual connections or other dynamic entities. > > That's potentially brutal on a shared system! I hope it's controlled > by an option, or that you do this only in something you're writing for > yourself alone. I'm thinking of a dedicated system here and exploiting the available CPU resources as efficiently as possible. > There are other reasons for forking per connection, though, such as > state cleanup. If we are talking about a handful of connections, a single asyncio process will be all you need (and will be gentle to other users of the shared system). When your server has to deal with thousands of simultaneous connections, spawning a process for each connection is probably not the optimal approach. It is precisely the scalability issues that caused Windows and Java go back to event-driven processing (that was prevalent in GUI design from the get-go). A company I used to work for was bitten badly by the multithreaded classic Java I/O, and a NIO overhaul was required when the connection count went to 500 and beyond. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Tue, Apr 8, 2014 at 12:51 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa wrote: >>> Roy Smith : >>> IOW, the processes are there to exercise the CPUs and should not >>> represent individual connections or other dynamic entities. >> >> That's potentially brutal on a shared system! I hope it's controlled >> by an option, or that you do this only in something you're writing for >> yourself alone. > > I'm thinking of a dedicated system here and exploiting the available CPU > resources as efficiently as possible. Huh. I don't remember the last time I worked on any system that could be dedicated to one single job. My servers are all carrying multiple services (HTTP, SMTP, IMAP, DNS, database, maybe a MUD or two...), my desktop computer doubles as a router and a VM host and a server for a few internal things (the NIV 1984 translation of the Bible is hosted there, for convenience, as is my RSS reader), etc, etc, etc. Ages since I've had enough physical hardware that I can afford to say "You're *just* the XYZ server and nothing else". At very least, I'll usually want to have some spare CPU cycles so I can plop a backup service on there (eg a PostgreSQL replicating clone, or a fail-over HTTP server, or a secondary DNS), but mainly, I've been working for the past however-many years under budget constraints. Oh the luxury of a dedicated application server. But that's why I said "writing for yourself alone", or govern it with an option. For any sort of general server software, it should be able to cope with a shared system. (And that should probably be the default - anyone who's running a dedicated system will normally already be aware that most programs need to be tweaked before you get maximum throughput out of them.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
Am 06.04.2014 09:25, schrieb Gary Herron: On 04/05/2014 11:53 PM, John Ladasky wrote: I find this programming pattern to be useful... but can it cause problems? No. What kind of problems are you considering? It won't break Python. It's perfectly legal code. The tuple c is still immutable, consisting of two specific objects, and (as always) without regard to the specifics or contents of those two objects. It seems a tuple's immutability is debatable, or is this another instance of the small-integer-reuse-implementation-detail-artifact? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = ([1,2],[3,4]) >>> b = a >>> a is b True >>> a == b True >>> c = (1,2,3) >>> d = (1,2,3) >>> c is d False >>> c == d True cheers Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Tue, Apr 8, 2014 at 1:26 AM, Paul Kölle wrote: > It seems a tuple's immutability is debatable, or is this another instance of > the small-integer-reuse-implementation-detail-artifact? > > Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) > [GCC 4.4.5] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. a = ([1,2],[3,4]) b = a a is b > True a == b > True c = (1,2,3) d = (1,2,3) c is d > False c == d > True That's nothing to do with mutability or reuse. With a and b, you assigned one to be the same as the other, so they are by definition identical (and equal; tuples assume that identity implies equality, even though that may not be true of their elements). With c and d, you assigned separate tuples, so they're allowed to be separate objects. I'm not sure if they're allowed to be constant-folded, but CPython apparently isn't doing so. They are still equal, though; they contain equal elements, ergo they are equal. (Note that (1, 2, 3) and (1.0, 2.0, 3.0) are equal, but they obviously can't be identical any more than "1 is 1.0" can ever be True.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
Am 07.04.2014 17:44, schrieb Chris Angelico: On Tue, Apr 8, 2014 at 1:26 AM, Paul Kölle wrote: It seems a tuple's immutability is debatable, or is this another instance of the small-integer-reuse-implementation-detail-artifact? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. a = ([1,2],[3,4]) b = a a is b True a == b True c = (1,2,3) d = (1,2,3) c is d False c == d True That's nothing to do with mutability or reuse. With a and b, you assigned one to be the same as the other, so they are by definition identical (and equal; tuples assume that identity implies equality, even though that may not be true of their elements). With c and d, you assigned separate tuples, so they're allowed to be separate objects. I'm not sure if they're allowed to be constant-folded, but CPython apparently isn't doing so. They are still equal, though; they contain equal elements, ergo they are equal. (Note that (1, 2, 3) and (1.0, 2.0, 3.0) are equal, but they obviously can't be identical any more than "1 is 1.0" can ever be True.) ChrisA Thanks Chris, stupid error indeed ;) cheers Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Tue, Apr 8, 2014 at 5:46 AM, Paul Kölle wrote: > Thanks Chris, stupid error indeed ;) Error, at least :) This is why we have a mailing list: errors, inaccuracies, and typos, regardless of who makes them or when, are pretty much guaranteed to be caught. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On 4/7/2014 11:26 AM, Paul Kölle wrote: >>> c = (1,2,3) >>> d = (1,2,3) >>> c is d False An implementation would be allowed to make that True, as it does for small ints and short strings that could be identifiers. >>> a = 'one' >>> b = 'one' >>> a == b; a is b True True However, duplicate tuples are much rarer than duplicate identifier strings. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/6/14 12:31 PM, Rustom Mody wrote: I think python wins because it (usually) lets people do their thing (includes but not limited to CS-research) and gets out of the way. To say therefore that it is irrelevant to the research is a strange inversion of its advantages. I think so too. I find python useful for modeling (prototyping) constructs that it [python interpreter] was not 'designed' to do. [Or simply just switch to C++ for 3 months and report back with the increment in your white-hair-count] Back in the day I used Rexx to prototype a new language idea, or a new computational technique. Today I use python for prototyping. From a CS standpoint I can use python for research in morphology because of the flexibility and extensibility of the namespace, and the easy ability to create new nouns and verbs through 'def' (as either function or generator) and the iterative process over data types like 'list' and 'dict'. I am playing with neural nets again, using python, and liking the fact that I can put my ideas into practice easily and python gets out of the way. I find it a great research language. I am surprised that others only see it as a problem solving tool. I have another question for y'all, is a function (particularly a generator) a noun or a verb? Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? Based on name and parms should a function (or generator) function as a noun, or function as a verb, or *both*? --or, are Classes nouns only, and all functions *are* verbs only? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 2014-04-08 02:33, Mark H Harris wrote: On 4/6/14 12:31 PM, Rustom Mody wrote: I think python wins because it (usually) lets people do their thing (includes but not limited to CS-research) and gets out of the way. To say therefore that it is irrelevant to the research is a strange inversion of its advantages. I think so too. I find python useful for modeling (prototyping) constructs that it [python interpreter] was not 'designed' to do. [Or simply just switch to C++ for 3 months and report back with the increment in your white-hair-count] Back in the day I used Rexx to prototype a new language idea, or a new computational technique. Today I use python for prototyping. From a CS standpoint I can use python for research in morphology because of the flexibility and extensibility of the namespace, and the easy ability to create new nouns and verbs through 'def' (as either function or generator) and the iterative process over data types like 'list' and 'dict'. I am playing with neural nets again, using python, and liking the fact that I can put my ideas into practice easily and python gets out of the way. I find it a great research language. I am surprised that others only see it as a problem solving tool. I have another question for y'all, is a function (particularly a generator) a noun or a verb? Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? Based on name and parms should a function (or generator) function as a noun, or function as a verb, or *both*? --or, are Classes nouns only, and all functions *are* verbs only? A function is an object (noun) that does stuff (verb). Does that make it clearer? :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Dennis Lee Bieber wrote: > That's been my experience too... Threading works for me... My attempts > at so called asyncio (whatever language) have always led to my having to > worry about losing data if some handler takes too long to return. > > To me, asyncio is closer to a polling interrupt handler, and I still > need a thread to handle the main processing. On a 32 bit system, the virtual address space with limit the scalabiliy for multi-threading in parallel i/o. That is, the stack space for each thread can quickly become a problem. Memory is not a problem on 64-bit servers. Multithreading can be used to solve the C10K problem, contrary to common belief. Before you dissmiss threads, take a look at this: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://stackoverflow.com/questions/17593699/tcp-ip-solving-the-c10k-with-the-thread-per-client-approach My personal feeling is that asynchronous i/o is mostly useful on 32-bit systems, and the problem it actually solves is the limited virtual address space. On a 64 bit system we can just throw more RAM at it and threads be fine. Sturla -- https://mail.python.org/mailman/listinfo/python-list
gdb python print truncated string
Hi all,
I have a question regarding gdb python.
I use gdb7.7 and python2.7.6.
Here is snippet that py-print one variable:
(gdb) py-print self
local 'self' = ,
timer513645288=<_Timeout at remote 0xb42f760>, timer1248840930=<_Timeout at
remote 0x7f85f7f4c300>, timer1678666863=<_Timeout at remote 0x7f85fec0ddf0>,
timer888598936=<_Timeout at remote 0x7f860579a300>, timer1566174556=<_Timeout
at remote 0xe69a7d0>, timer1307561941=<_Timeout at remote 0x7f85e41145a0>,
timer1010094072=<_Timeout at remote 0xb42af40>, to_device={u'sendno':
u'1252682169', u'msg_content': {u'message': {u'command': True}}, u'msg_type':
u'2'}, timer2050775853=<_Timeout at remote 0x7f8606ddcb50>,
timer1115907467=<_Timeout at remote 0x9c02140>, timer333587031=<_Timeout at
remote 0xbb25450>, timer71350378=<_Timeout at remote 0x7f85e5e38220>,
timer1044716881=<_Timeout at remote 0x7f86053094c0>, timer2069059536=<_Timeout
at remote 0x7f85f3d3b530>, timer2139990080=<_Timeout at remote 0x8bd5370>,
timer1121163931=<_Timeout at remote 0x99e5370>,
queue=, maxsize=0, all_ta...(truncated)
self is instance of Connection class.
So, actually, I wanna check self.status...but you can see the print is
truncated.
I tried py-print self.status but failed.
After a lot google work, somebody mention gdb 'set print elements 0/-1', but
still failed..
So, how to check self.status value?
Thanks.
Wesley
--
https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Mon, 07 Apr 2014 20:16:05 -0400, Terry Reedy wrote:
> On 4/7/2014 11:26 AM, Paul Kölle wrote:
>
>> >>> c = (1,2,3)
>> >>> d = (1,2,3)
>> >>> c is d
>> False
>
> An implementation would be allowed to make that True, as it does for
> small ints and short strings that could be identifiers.
And indeed, that happens in at least one circumstance in Python 3.3:
py> a, b = [(1, 2, 3) for _ in range(2)]
py> a is b
True
But:
py> x = 3
py> a, b = [(1, 2, x) for _ in range(2)]
py> a is b
False
As Terry knows, but for the benefit of others who may not, the re-use of
objects leading to object identity ("a is b") is an implementation detail
which *cannot be relied on*. It can change without notice, and is not a
promise of the language.
> >>> a = 'one'
> >>> b = 'one'
> >>> a == b; a is b
> True
> True
In this case, it is a promise of the language that a will equal b: a and
b must be bound to strings with the same value. But an implementation
detail whether Python creates two strings, both with value "one", or just
a single string, and uses it for both a and b.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Tue, Apr 8, 2014 at 11:33 AM, Mark H Harris wrote: > Does a function (or generator) 'do' something (based on name and parms) or > does it 'return' something based on name and parms? If it has no side effects, then it does something, where the 'something' is returning a value. "Return" is a verb. (It can also be a noun, but in the context of functions, it's a verb.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
change spacing to two instead of four with pep8 or flake8?
Hi, In Pylint you can change the spacing multiplier from 4 spaces to two in its pylintrc, but for the life of me I cannot find a way to do this with the flake8 / pep8 utilities. I want to avoid ignoring E111 altogether if at all possible, because it may catch other spacing problems that are not as obvious. hacky/non-hacky solutions welcome of course. If this is too specific and I should go to the pep8/flake8 MLs that is welcome advice too. Thanks, Dennis -- https://mail.python.org/mailman/listinfo/python-list
Re: Keeping track of things with dictionaries
On Sunday, April 6, 2014 12:44:13 AM UTC-7, Giuliano Bertoletti wrote: > obj = brands_seen.get(brandname) > > if obj is None: > obj = Brand() > brands_seen[brandname] = obj > > Would dict.setdefault() solve this problem? Is there any advantage to defaultdict over setdefault() Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: Keeping track of things with dictionaries
On Tue, Apr 8, 2014 at 2:02 PM, Josh English wrote: > On Sunday, April 6, 2014 12:44:13 AM UTC-7, Giuliano Bertoletti wrote: > > >> obj = brands_seen.get(brandname) >> >> if obj is None: >> obj = Brand() >> brands_seen[brandname] = obj >> >> > > Would dict.setdefault() solve this problem? Is there any advantage to > defaultdict over setdefault() That depends on whether calling Brand() unnecessarily is a problem. Using setdefault() is handy when you're working with a simple list or something, but if calling Brand() is costly, or (worse) if it has side effects that you don't want, then you need to use a defaultdict. I think this is a textbook example of why defaultdict exists, though, so I'd be inclined to just use it, rather than going for setdefault :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Dennis Lee Bieber : > That's been my experience too... Threading works for me... My > attempts at so called asyncio (whatever language) have always led to > my having to worry about losing data if some handler takes too long to > return. > > To me, asyncio is closer to a polling interrupt handler, and I > still need a thread to handle the main processing. Yes, asynchronous processing results in complex, event-driven state machines that can be hard to get right. However, my experience is that that's the lesser evil. About a handler taking too long: you need to guard each state with a timer. Also, you need then to handle the belated handler after the timer has expired. The main problems with threads include: * Thread-safety is rarely done right. Also, when it's done wrong, it can be virtually impossible to fix it without a significant rewrite. This is not a theoretical concern: I have had to deal with the resulting nightmares in my work. * There is no accepted, taught, industry-wide discipline on proper thread-safety practices so every developer has to improvise. I have come up with a "bullet-proof" way of developing with threads, but even that methodology has nasty corner cases. * Thread-safety cannot be abstracted out. IOW, divide and conquer doesn't work. You can't hide the locking inside a class and forget about it. The entire application must be aware low-level thread synchronization needs. * Threads assume each state has one exit event. At a bare minimum, each thread should be prepared to have the blocking event aborted from the outside. Unfortunately, most threading frameworks don't allow for graceful aborts (that goes for Java and Python, too). * If you have made your design around threads and finally decide asynchronous processing would have been a better choice, a complete rewrite is required if it is even possible. Library writers often only provide blocking I/O functions forcing you to insulate the libraries in thread pools. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Keeping track of things with dictionaries
On Monday, April 7, 2014 9:08:23 PM UTC-7, Chris Angelico wrote: > That depends on whether calling Brand() unnecessarily is a problem. > Using setdefault() is handy when you're working with a simple list or > something, but if calling Brand() is costly, or (worse) if it has side > effects that you don't want, then you need to use a defaultdict. > > I think this is a textbook example of why defaultdict exists, though, > so I'd be inclined to just use it, rather than going for setdefault :) Thanks for the clarification. -- https://mail.python.org/mailman/listinfo/python-list
