Re: exit ThreadPoolExecutor immediately
Atul Johri writes: > I am looking for a way to stop a ThreadPoolExecutor immediately under the > assumption that I don't care about what's currently running or pending. > > ``` > limit = 2 > executor = ThreadPoolExecutor(10) > posts = itertools.islice(mygen(executor=executor, **kwargs), 0, limit) > for post in posts: > print(post) > executor.shutdown(wait=False) > ``` > > Basically I have a generator, mygen, which is using the executor to submit > many tasks in parallel and yield the result one at a time. I would like to > be able to limit the generator and have the executor stop processing > immediately. > > I was considering clearing the _work_queue or iterating over it and running > future.cancel() on each future but both seem to be quite hacky and didn't > work in my initial try. > > https://github.com/python/cpython/blob/master/Lib/concurrent/futures/thread.py#L83 > > Any ideas? I would implement my own class (inheriting from "ThreadPoolExecutor") and give it appropriate API to realise what I need (using whatever internal implementation details are necessary). I should not be that difficult for tasks not yet started (i.e. not yet run be a thread). In earlier Python versions, it was not possible from Python level to abort a thread; there was a C level Python API function to abort a thread once it started to execute Python code again. Thus, there was not a complete solution for your problem. This might have changed with modern Python version, but I doubt it (the main reason for the restriction has been the difficulty to cleanly abort a thread in a platform independent way -- this difficulty should remain, whatever the Python version). -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On 11/14/2016 11:32 PM, jf...@ms4.hinet.net wrote: > But obviously it's not. The compiled code of function gpa is still > reference to a hidden deen.tblm 'global' object which I can't access > anymore. A bad news:-( Seems like you're still not understanding Python variables. After importing all the names from "deen" into your current module's namespace, they do "point" or refer to the actual objects from the deen module. So at that moment, they are the same objects as if you were to import deen and refer to them with the deen.foo notation. However once you assign to these names in your current module you are breaking this link to the deen module and assigning a new object to these names in your current module's namespace. You're getting hung up on the names, when you should be concentrating on what the names refer to. Variables in python aren't implement the same as C, or Java. They aren't aliases for a box in memory that you can alter using assignment. Instead assignment points the name to the object in the RHS, in place of the old object it used to refer to (if the references to this old object reach zero, it is deleted). As you've been told several times, if you "import deen" then you can place a new object into the deen namespace using something like: deen.foo=bar Importing everything from an imported module into the current module's namespace is not the best idea. -- https://mail.python.org/mailman/listinfo/python-list
Re: exit ThreadPoolExecutor immediately
Doug Hellmann has what looks like a similar example using a poison pill (2nd example at) https://pymotw.com/2/multiprocessing/communication.html#multiprocessing-queues Note that join() allows the processes to finish so it you don't care then don't "join()" them. You can also terminate a multiprocessing thread https://pymotw.com/2/multiprocessing/basics.html#terminating-processes -- https://mail.python.org/mailman/listinfo/python-list
Python Guarded Pattern matching (when x -> do action)
I am looking to see if there is prior work, or design ideas for implementing pattern-matched guard statements in a very natural format for python programmers. For those not familiar with pattern matching in [SCALA][1], [Erlang][2], or [F#][3] They all have constructs similiar to: When (pattern == condition) then invoke( behavior) This is also very similiar to trigger-stored-procedure techniques in Databases. What we want to do is create an agent-based system, where there is a large shared memory, with lots of binary structs (python has good modules for this). Which has many attached guard-statement rules, that will fire when the values match the pattern (we will have monitors that watch when structs are modified). Has anyone seen prior work of this nature? The goal is to get something that is quite natural to a python programmer, not force SCALA, GO, Erlang, F#, etc on python folks. We have our own ideas, but I would love to see what the community might have already done along these lines. [1]: http://docs.scala-lang.org/tutorials/tour/pattern-matching.html [2]: http://stackoverflow.com/questions/21083874/erlang-case-statement [3]: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/match-expressions -- https://mail.python.org/mailman/listinfo/python-list
PyQt pass data from class
Hello i need to this
class Form(QWidget, Ui_Form):
"""
Class documentation goes here.
"""
def __init__(self, parent=None):
"""
Constructor
@param parent reference to the parent widget
@type QWidget
"""
super(Form, self).__init__(parent)
self.setupUi(self)
self.tabWidget.setCurrentIndex(0)
combo = QComboBox()
self.disegno = Cornice()
class Cornice(QPainter):
def __init__(self, parent=None):
lista_dati = []
in the class Form i have a lineEdit
in the class Cornice i need to write something link
self.lineEdit.setText('blabla') that is in the class Form
in wich way i can have access to the lineedit of class Form without event from
class Cornice
Many Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: PyQt pass data from class
luca72 wrote:
> Hello i need to this
>
> class Form(QWidget, Ui_Form):
> """
> Class documentation goes here.
> """
> def __init__(self, parent=None):
> """
> Constructor
>
> @param parent reference to the parent widget
> @type QWidget
> """
> super(Form, self).__init__(parent)
> self.setupUi(self)
> self.tabWidget.setCurrentIndex(0)
> combo = QComboBox()
> self.disegno = Cornice()
>
> class Cornice(QPainter):
>
> def __init__(self, parent=None):
>
> lista_dati = []
>
> in the class Form i have a lineEdit
>
> in the class Cornice i need to write something link
>
> self.lineEdit.setText('blabla') that is in the class Form
>
> in wich way i can have access to the lineedit of class Form without event
> from class Cornice
>
> Many Thanks
Traditionally you'd have Cornice emit a Signal, which when you
__init__the Form you'd connect to the appropriate slot. I don't recall
PyQt syntax, but in PySide it would look like
self.disengo.theSignal.connect(self.lineEdit.setText)
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: PyQt pass data from class
On 11/15/2016 10:01 AM, luca72 via Python-list wrote: > in wich way i can have access to the lineedit of class Form without event > from class Cornice If I understand you, you are asking how to set the text without having it emit a signal. Is that correct? Or are you asking how to access the member of one class from a method in another class? If it's the former, you can ask PyQt to suppress a callback for a while. Look up the blockSignals() method of QWidget. If it's the latter, your best bet is to pass the object you want to access into the other class somehow, perhaps as an argument to __init__(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Making stl files with python for 3d printing
Den mandag den 14. november 2016 kl. 05.55.20 UTC+1 skrev Gregory Ewing: > Poul Riis wrote: > > However, when sending the .stl file produced to a 3D-printer the vase comes > > out as a filled solid - no room for water and flowers! > > My guess is that you have a problem with the orientation > of your faces. The inner surface needs to have its triangles > oriented so that their "outside" direction is towards the > centre of the vase. > > If you generate the inner surface using the same code as > the outer surface and just change the radius, you will > end up with both surfaces oriented outwards, which would > produce the effect you describe. > > -- > Greg You are right - thank you so much! Poul Riis -- https://mail.python.org/mailman/listinfo/python-list
A question about sprite rendering in game development
I'm still quite new to python, but I have a concern. I want to learn python for game development, but I need to know if python is capable of rendering, let's say 50 animated character sprites, at once without lagging. if anyone's ever played the epic war game series then you should have an idea of what I'm trying to create. in short, I need several different types of characters to be under the players command while there are several of each character and each of them also need to be able to react to their envoirment (being able to notice when an opponent is in front of them) is all of this possible in python without massive lagg?? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question about sprite rendering in game development
shadecelebi : > I'm still quite new to python, but I have a concern. I want to learn > python for game development, but I need to know if python is capable > of rendering, let's say 50 animated character sprites, at once without > lagging. > > if anyone's ever played the epic war game series then you should have > an idea of what I'm trying to create. in short, I need several > different types of characters to be under the players command while > there are several of each character and each of them also need to be > able to react to their envoirment (being able to notice when an > opponent is in front of them) > > is all of this possible in python without massive lagg?? Your question suggests Python is the least of your problems. Do you already have the artwork for even one of your game characters? Anyway, do create your game in Python. You should at least be able to test your game ideas with it. If it is too slow, simply reimplement your prototype in C. Compared with everything else, learning Python and reimplementing the game in C will be trivial. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On 15/11/16 14:43, Michael Torrie wrote: As you've been told several times, if you "import deen" then you can place a new object into the deen namespace using something like: deen.foo=bar Importing everything from an imported module into the current module's namespace is not the best idea But "from foo import *" is not importing "everything". It's the opposite - it's importing everything _that the module wants to explicitly expose_ (i.e., a subset of everything ;)). It *used* to be everything in the module's namespace, but then the possibly misnamed "__all__" magic variable made it a subset of whatever the module's author wanted to expose. However, "import foo" _does_ import "everything", and also gives the importer the power to re-bind names within that module's namespace too (which is the crux of the original question). This is not usually a good thing unless the importing module is incestuous with the imported module. So this brings up another point - not sure if it has been made before: should a module have a way of *not* allowing an importer to re-bind its local bindings? For example, something like a "__bindable__" variable such that all names not included may not be bound by any other module? And/or something like an "__export__" variable that says what gets exposed to a simple "import foo" (sometimes one might want to "import foo" and sometimes "from foo import *" for namespace reasons, but why should those two statements import different things)? E. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question about sprite rendering in game development
On Wed, 16 Nov 2016 08:57 am, shadecelebi wrote: > I'm still quite new to python, but I have a concern. I want to learn > python for game development, but I need to know if python is capable of > rendering, let's say 50 animated character sprites, at once without > lagging. Absolutely. For something like that, I suggest you look at PyGame. You do all the game programming and logic in Python, and the underlying game engine (including drawing the sprites) is based on fast C and assembly code. It supports multiple backends, including opengl, directx, windib, X11, linux frame buffer, and even ASCII art. http://www.pygame.org/ http://www.pygame.org/wiki/about -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On Wed, 16 Nov 2016 09:16 am, Erik wrote:
> On 15/11/16 14:43, Michael Torrie wrote:
>> As you've been told several times, if you "import deen" then you can
>> place a new object into the deen namespace using something like:
>>
>> deen.foo=bar
>>
>> Importing everything from an imported module into the current module's
>> namespace is not the best idea
>
> But "from foo import *" is not importing "everything". It's the opposite
> - it's importing everything _that the module wants to explicitly expose_
> (i.e., a subset of everything ;)).
I think you're skipping Michael's point and making a pedantic comment that
isn't really relevant and, to be even more pedantic, is wrong.
The gory details of what precisely gets imported by an import star is
probably not relevant to a beginner still struggling with understanding
fundamental scoping issues.
I'm also sure that Michael didn't *literally* mean "everything", since he's
been around a while and is probably aware that private names with a single
leading underscore won't be imported.
And your comment is (pedantically) wrong because it isn't always the case
that "import *" only imports things that the module explicitly exposes for
importing. By default, it imports everything which isn't implicitly
excluded. Modules don't pre-define an __all__ variable, hence modules have
to opt out of allowing imports of all non-private names rather than opt in.
I'm sure this is all important for intermediate-level Python programmers,
but I just hope we're not confusing the OP.
> It *used* to be everything in the module's namespace, but then the
> possibly misnamed "__all__" magic variable made it a subset of whatever
> the module's author wanted to expose.
It isn't misnamed: it's intended as a shorter version of "all public names".
The intent being, module authors list ALL their module's public names in
__all__ in order to control what import star does, without relying purely
on the implicit _private name convention.
> However, "import foo" _does_ import "everything",
No, that's a misuse of terminology. It only imports a single thing: `foo`.
You can test this yourself by comparing the local namespace before and after
a single import: only one more name is added to your namespace.
py> before = after = None
py> before = set(locals().keys())
py> assert 'cmath' not in before
py> import cmath
py> after = set(locals().keys())
py> after - before
{'cmath'}
The conclusion is obvious: importing a single name imports only a single
object into the current namespace. (Well, what else did you expect? *wink*)
What you are talking about is something different: importing a module gives
you access to all the module's attributes. Well of course it does. If you
import a single class from a module, having access to the class gives you
access to all the class attributes. Importing a single function gives you
access to the function's attributes. Importing any object at all gives you
access to that object's attributes. Modules are no different.
> and also gives the
> importer the power to re-bind names within that module's namespace too
> (which is the crux of the original question). This is not usually a good
> thing unless the importing module is incestuous with the imported module.
With great power comes great responsibility...
Monkey-patching modules is a powerful and risky technique. No *library*
should monkey-patch another library (unless they're designed to work
together), since you cannot tell if you're messing with something a third
library relies on. But its acceptable for an application to take over
control of a library and monkey-patch it, since there should only ever be a
single application running at once.
Perhaps only *borderline* acceptable, and maybe not something many people
are willing to do in production systems, but its certainly something we do
in (for example) testing. What is a test suite but a stand-alone
application? And test suites will often monkey-patch libraries, insert
mocks and stubs and otherwise manipulate the library.
At least we're not Ruby :-)
http://www.virtuouscode.com/2008/02/23/why-monkeypatching-is-destroying-ruby/
> So this brings up another point - not sure if it has been made before:
> should a module have a way of *not* allowing an importer to re-bind its
> local bindings?
Certainly not! Well, maybe. Yes.
Never mind this "the importer" bit, that's just a special case of a more
general problem: Python has no way of enforcing constants.
This has been argued about many times. Some people want a way of getting
real constants which cannot be modified, or at least cannot be re-bound to
a new value. Others think that the status quo ("if you don't want to
re-bind a constant, then don't re-bind it") is satisfactory.
I'd prefer to have a way to protect against *accidental* re-bindings:
const x = 1.2345
# later:
x += 1 # raise an exception
while still allowing some mechanism for *deliberate* monkey-patching, say:
vars()['x'] = 2.234
Re: help on "from deen import *" vs. "import deen"
Michael Torrie at 2016/11/15 10:43:58PM wrote: > Seems like you're still not understanding Python variables. I do, just not get used to it yet:-) > However once > you assign to these names in your current module you are breaking this > link to the deen module and assigning a new object to these names in > your current module's namespace. Why? the name "tblm" is already exist and is a mutable one, should be changed intuitional by "tblm=tbli". If I really need a new list, I can create one by using a new name. Python shouldn't have its finger in my pie:-( > You're getting hung up on the names, > when you should be concentrating on what the names refer to. That's one problem I was concerned. Human beings are very deeply binding on words (names?). We think in words, talk in words, communicate in words. Actually we are living in words. I really don't like that when I said "John is a boy" and was told "No, John is a dog now":-) --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On 11/15/2016 07:39 PM, jf...@ms4.hinet.net wrote: > Michael Torrie at 2016/11/15 10:43:58PM wrote: >> Seems like you're still not understanding Python variables. > > I do, just not get used to it yet:-) No you don't yet. See below. > Why? the name "tblm" is already exist and is a mutable one, should be > changed intuitional by "tblm=tbli". If I really need a new list, I > can create one by using a new name. Python shouldn't have its finger > in my pie:-( No, names are not mutable per se. Objects can be. If the object is mutable you can mutate it: someobject.some_mutate_method(foo) or some_list[1] = 5 The latter is actually syntactic sugar for something more akin to this: some_list.__setattr__(1,5). Note that this throws out the reference to the object that used to be held by slot 1, and now refers to the new object, 5. Names are, well, just names. They refer to objects, which may or may not be mutable. And multiple names can refer to the exact same object. Internally, variables are stored in dictionaries: >>> a = 5 >>> globals['a'] 5 And in fact in Python many primitive objects like numbers and strings are immutable. They cannot ever change once they are brought into existence. Expressions such as mathematical equations result in new objects being created (number objects can be reused and are often cached). The assignment operator does not by default mutate an object. Instead it makes the variable (the name) refer to the new object, the result of the RHS. Now this may seem like I've contradicted myself, seeing as I used the example above to show how = can mutate a list-like object. But if you understand the underlying mechanism for holding names, it's actually consistent. The globals object is a dictionary and is itself mutable. But when we assign a new object to a particular dictionary key, it tosses out the old reference and makes the key now refer to the new object. It does not do anything to the old object itself. Anyway, don't think we can make things much clearer than that. >> You're getting hung up on the names, when you should be >> concentrating on what the names refer to. > > That's one problem I was concerned. Human beings are very deeply > binding on words (names?). We think in words, talk in words, > communicate in words. Actually we are living in words. I really don't > like that when I said "John is a boy" and was told "No, John is a dog > now":-) Not quite sure where you're going with that. I would think the idea of labels on objects would be fairly natural. I could stick a label that says "chair" on a chair, and then later move that label to the couch. Same label, different object. Whether the label makes sense is up to you. -- https://mail.python.org/mailman/listinfo/python-list
__debug__ http://stackoverflow.com/questions/15305688/conditional-debug-statement-not-executed-though-debug-is-true
Trying to make sense of that article. My understanding of debug was simple: 1. __debug__ is always True, unless -O or -OO 2. 'if' is optimized out when True and the expr is inlined. So what does he mean by: 1. 'If you rebind __debug__, it can cause symptoms' 2. 'During module compilation, the same code that handles literals also handles the magic constants ..., None, True, False, and __debug__' 3. 'you'll see that if __debug__: statements are either removed entirely, or use LOAD_CONST to load the compile-time debug constant, while if bool(__debug__): statements use LOAD_GLOBAL to load the value of __debug__.' 4. 'Of course these are guaranteed to be the same… unless you rebind __debug__' Basically every line in that answer is new to me.. -- https://mail.python.org/mailman/listinfo/python-list
Re: __debug__ http://stackoverflow.com/questions/15305688/conditional-debug-statement-not-executed-though-debug-is-true
Veek M wrote: > Trying to make sense of that article. My understanding of debug was > simple: > 1. __debug__ is always True, unless -O or -OO > 2. 'if' is optimized out when True and the expr is inlined. > > So what does he mean by: > > 1. 'If you rebind __debug__, it can cause symptoms' > 2. 'During module compilation, the same code that handles literals > also handles the magic constants ..., None, True, False, and > __debug__' 3. 'you'll see that if __debug__: statements are either > removed entirely, or use LOAD_CONST to load the compile-time debug > constant, while if bool(__debug__): statements use LOAD_GLOBAL to load > the value of __debug__.' > > 4. 'Of course these are guaranteed to be the same… unless you rebind > __debug__' > > Basically every line in that answer is new to me.. Sorry for the awful title but I was not sure what to title it because I have no clue what they are talking about.. barring the fact that it's about __debug__ and assigning True/False to it.. Isn't that how you turn it off when you don't want -O ?? -- https://mail.python.org/mailman/listinfo/python-list
Re: PyQt pass data from class
Thanks for your reply Is the latter, can you explain how i can do it. Thanks -- https://mail.python.org/mailman/listinfo/python-list
