Re: Py330b1, un café crème sucré
On 27 juin, 22:48, Karim wrote:
>
> Euhhh, j'ai pas tout suivi. C'est quoi la feinte?
>
Perso je suis pas sûr qu'il y en ait une.
Je dirais que l'OP a peut-être eu un grand besoin de café crème sucré
et a voulu partager son plaisir avec d'autres, why not ;)
regards,
gst.
>
> Le 27/06/2012 21:49, wxjmfa...@gmail.com a écrit :
>
>
>
>
>
>
>
> > # -*- coding: cp1252 -*-
> > # café.py
>
> > import sys
> > print(sys.version)
>
> > sys.path.append('d:\\crème')
> > import crème
> > import sucré
>
> > s = ' '.join(['un', 'café', crème.tag, sucré.tag])
> > print(s)
>
> > input(':')
>
> > #--
> > # .\sucré.py:
> > # -*- coding: cp1252 -*-
> > #tag = 'sucré'
>
> > #--
> > # d:\crème\crème.py
> > # -*- coding: cp1252 -*-
> > #tag = 'crème'
>
> > # output
> > # 3.3.0b1 (v3.3.0b1:e15c554cd43e+, Jun 26 2012, 20:30:00) [MSC v.1600 32
> > bit (Intel)]
> > # un café crème sucré
> > # :
>
> > # :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: New to python, do I need an IDE or is vim still good enough?
Le jeudi 27 décembre 2012 21:01:16 UTC+1, mogul a écrit : > 'Aloha! > holà ! > > I'm new to python, got 10-20 years perl and C experience, all gained on unix > alike machines hacking happily in vi, and later on in vim. > About same than me, though I had not to use/work with perl for new projects, only in maintaining some existing stuffs in some previous jobs. > > Now it's python, and currently mainly on my kubuntu desktop. > > Do I really need a real IDE, as the windows guys around me say I do, or will > vim, git, make and other standalone tools make it the next 20 years too for > me? > Obviously I have same comments than others ;) though I think it mainly depends on the project.. I do think/experience that big projects get some real advantage of advanced IDE, like eclipse/pycharm and others "big" python IDE. Now which one to use is mainly a matter of taste, as always. > > Oh, by the way, after 7 days I'm completely in love with this python thing. > as others said: welcome to the club :) > I should have made the switch much earlier! Don't be afraid of the late switch : you'll very quickly make amazing stuffs with Python and anyway it's (always) better late than never and it could be better now than some few years ago (I begin to make the switch about 3-4 years ago and now I have the luck to work for a company where I'm 100% working with Python :)). Python3(.2+) effectively corrects some, I'd say, youth problems related to python2 and it's now quite highly deployed and about all majors libraries are already supporting it, if not they are about all on their way to do it sooner than later ;) > /mogul %-) good work/fun with Python, greg. -- http://mail.python.org/mailman/listinfo/python-list
Re: why () is () and [] is [] work in other way?
Le samedi 21 avril 2012 10:46:39 UTC+2, Alexander Blinne a écrit : > Am 21.04.2012 05:25, schrieb Rotwang: > > This happens only because the first [] gets destroyed after evaluation > of id([]). The second [] then by accident gets the same id as the first > one had. > > >>> a = [] > >>> b = [] > >>> id(a) == id(b) > False > > Greetings Hi, I played (python3.2) a bit on that and : case 1) Ok to me (right hand side is a tuple, whose elements are evaluated one per one and have same effect as your explanation (first [] is destroyed right before the second one is created) : >>> x, y = id([]), id([]) >>> x == y True >>> case 2) also ok to me: >>> x = id([]) ; y = id([]) >>> x == y True >>> case 3) NOT ok to me : >>> x = id([]) >>> y = id([]) >>> x == y False >>> case 4) ok to me : >>> def f(): x = id([]) y = id([]) return x == y >>> f() True >>> I'd have thought that cases 2&3 are totally, while 3&4 nearly, syntactically equal and that case 3 is the incorrect result.. how would you explain case 3 vs cases 2 and 4 ?? regards, gs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Running asyncio.run() more than once
Le mardi 14 mars 2023 à 02:32:23 UTC-4, Clint Olsen a écrit : > We have an application that involves submitting hundreds to thousands of jobs > to a shared computing resource, and we're using asyncio to do so because it > is far less overhead than threading or multiprocessing for the bookkeeping > required to keep track of all these jobs. It makes extensive use of > asyncio.create_subprocess_exec(). This was developed mostly in Python 3.9.7. > I'm not asyncio expert or even not advanced user, but using a simple list to hold the jobs to execute and fill it as necessary after results gathering is not good ? ``` @async def execute_jobs(jobs: List["Job"]): while len(jobs) > 0: # launch_job(s) # gather_job(s)_result(s) # append_jobs_if_desired ``` does not make the trick ? -- https://mail.python.org/mailman/listinfo/python-list
Re: logger.info / logger.error with logger.addHandler - how to split streams?
Le lundi 26 décembre 2016 10:34:48 UTC-5, Alec Taylor a écrit : > So I'm putting .info in one StringIO and .error in another StringIO. > > How do I stop them from both being put into both? > > Code: http://ideone.com/Nj6Asz Hi, it's doable with filter on the handlers: def exact_filter(level): def filter(record): return level == record.levelno filter.filter = filter return filter stdout_stream.addFilter(exact_filter(logging.INFO)) stderr_stream.addFilter(exact_filter(logging.ERROR)) -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
I know this does not bring anything valuable but: Definitively agree with your mental model !! 'then' and only "then" is the best keyword in the situation which is on the table right now. it totally fix the confusing "else" actual mess (for at least 2 reasons). Python 4.0 ? My son will thank us ! NB: - I'm not a native English speaker - but I'm using the "(for,while)/else" way sometimes, but damn the "then" keyword is at least better here ! -- https://mail.python.org/mailman/listinfo/python-list
Re: Just starting to learn Python, and encounter a problem
Heuh case 2 : "String1" or "String2" Evaluates to "String1" ? -- https://mail.python.org/mailman/listinfo/python-list
Re: 0 equals False, was Re: (unknown)
Le mercredi 23 mars 2016 04:52:02 UTC-4, Peter Otten a écrit :
> Nick Eubank wrote:
>
> > Hello All,
> >
> >
> > Found an odd behavior I'd never known about today, not sure if it's a bug
> > or known. Python 3.4.4 (anaconda).
> > True, False, 0, 1 can all be used as dictionary keys.
> >
> > But Apparently True and 1 hash to the same item and False and 0 hash to
> > the same item, so they can easily overwrite (which I spent a while banging
> > my head over today).
> >
> > In other words:
> >
> > In[1]:
> > d = {True: 'a', False: 'b'}
> > d[0] = 'z'
> > d[False]
> >
> > Out[1]:
> > 'z'
> >
> > I understand that True and False are sub-types of ints, but it's not clear
> > to me why (i.e. certainly didn't feel intuitive) that they would be
> > treated the same as keys.
> >
> > Relatedly, if this is a desired behavior, any advice one how best to work
> > with dictionaries when one wants "True" and 1 to be different? I'm working
> > on a function that accepts arguments that may be "True" or 1 (meaning very
> > different things) and am seeking a pythonic solution...
I would include the type in the dictionary key:
d = {}
x = True
d[(type(x), x)] = 42
x = 1
d[(type(x), x)] = "foo"
--
https://mail.python.org/mailman/listinfo/python-list
Re: encoding name mappings in codecs.py with email/charset.py
Le vendredi 12 décembre 2014 04:21:14 UTC-5, Stefanos Karasavvidis a écrit :
> I've hit a wall with mailman which seems to be caused by pyhon's character
> encoding names.
>
> I've narrowed the problem down to the email/charset.py file. Basically the
> following happens:
>
Hi,
it's all in the email.charset.ALIASES dict.
you could also simply patch the __str__ method of Charset :
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "copyright", "credits" or "license()" for more information.
>>>
>>> import email.charset
>>>
>>> c = email.charset.Charset('iso-8859-7')
>>> str(c)
'iso8859-7'
>>>
>>> old = email.charset.Charset.__str__
>>>
>>> def patched(self):
r = old(self)
if r.startswith('iso'):
return 'iso-' + r[3:]
return r
>>>
>>> email.charset.Charset.__str__ = patched
>>>
>>> str(c)
'iso-8859-7'
>>>
regards,
gst.
--
https://mail.python.org/mailman/listinfo/python-list
Re: encoding name mappings in codecs.py with email/charset.py
Le dimanche 14 décembre 2014 14:10:22 UTC-5, Stefanos Karasavvidis a écrit :
> thanks for replying gst.
>
> I've thought already of patching the Charset class, but hoped for a cleaner
> solution.
>
>
> This ALIASES dict has already all the iso names *with* a dash. So it must get
> striped somewhere else.
not on my side, modifying this dict with the missing key-value apparently does
what you want also :
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "copyright", "credits" or "license()" for more information.
>>>
>>> import email.charset
>>> email.charset.ALIASES
{'latin-8': 'iso-8859-14', 'latin-9': 'iso-8859-15', 'latin-2': 'iso-8859-2',
'latin-3': 'iso-8859-3', 'latin-1': 'iso-8859-1', 'latin-6': 'iso-8859-10',
'latin-7': 'iso-8859-13', 'latin-4': 'iso-8859-4', 'latin-5': 'iso-8859-9',
'euc_jp': 'euc-jp', 'latin-10': 'iso-8859-16', 'ascii': 'us-ascii', 'latin_10':
'iso-8859-16', 'latin_1': 'iso-8859-1', 'latin_2': 'iso-8859-2', 'latin_3':
'iso-8859-3', 'latin_4': 'iso-8859-4', 'latin_5': 'iso-8859-9', 'latin_6':
'iso-8859-10', 'latin_7': 'iso-8859-13', 'latin_8': 'iso-8859-14', 'latin_9':
'iso-8859-15', 'cp949': 'ks_c_5601-1987', 'euc_kr': 'euc-kr'}
>>>
>>> for i in range(1, 16):
c = 'iso-8859-' + str(i)
email.charset.ALIASES[c] = c
>>>
>>> iso7 = email.charset.Charset('iso-8859-7')
>>> iso7
iso-8859-7
>>> str(iso7)
'iso-8859-7'
>>>
regards,
gst.
>
> sk
>
>
>
> On Sun, Dec 14, 2014 at 7:21 PM, gst wrote:
> Le vendredi 12 décembre 2014 04:21:14 UTC-5, Stefanos Karasavvidis a écrit :
>
> > I've hit a wall with mailman which seems to be caused by pyhon's character
> > encoding names.
>
> >
>
> > I've narrowed the problem down to the email/charset.py file. Basically the
> > following happens:
>
> >
>
>
>
> Hi,
>
>
>
> it's all in the email.charset.ALIASES dict.
>
>
>
> you could also simply patch the __str__ method of Charset :
>
>
>
> Python 2.7.6 (default, Mar 22 2014, 22:59:56)
>
> [GCC 4.8.2] on linux2
>
> Type "copyright", "credits" or "license()" for more information.
>
> >>>
>
> >>> import email.charset
>
> >>>
>
> >>> c = email.charset.Charset('iso-8859-7')
>
> >>> str(c)
>
> 'iso8859-7'
>
> >>>
>
> >>> old = email.charset.Charset.__str__
>
> >>>
>
> >>> def patched(self):
>
> r = old(self)
>
> if r.startswith('iso'):
>
> return 'iso-' + r[3:]
>
> return r
>
>
>
> >>>
>
> >>> email.charset.Charset.__str__ = patched
>
> >>>
>
> >>> str(c)
>
> 'iso-8859-7'
>
> >>>
>
>
>
>
>
> regards,
>
>
>
> gst.
>
> --
>
> https://mail.python.org/mailman/listinfo/python-list
>
>
>
>
> --
>
>
> ==
> Stefanos Karasavvidis, Electronic & Computer Engineer, M.Sc.
> e-mail: s...@isc.tuc.gr, Tel.: (+30) 2821037508, Fax: (+30) 2821037520
> Technical University of Crete, Campus, Building A1
--
https://mail.python.org/mailman/listinfo/python-list
Re: Passing new fields to an object
Le vendredi 12 juin 2015 11:53:24 UTC-4, Paulo da Silva a écrit : > I would like to do something like this: > > class C: > def __init__(self,**parms): > ... > > c=C(f1=1,f2=None) > > I want to have, for the object > self.f1=1 > self.f2=None > > for an arbitrary number of parameters. > > What is the best way to achieve this? > > Thanks in the __init__, simply do: self.__dict__.update(**parms) regards, gst. -- https://mail.python.org/mailman/listinfo/python-list
Sometimes bottle takes a lot of time
What if you try with all the SQLite code commented ? -- https://mail.python.org/mailman/listinfo/python-list
Re: First python project : Tuner
On 17 jan, 15:16, Jérôme wrote: > Hi all. > hi, just my 2 cents: you have quite lot of such test: > if self._index is 0: I think it's better to compare with equality against 0 (or other needed value) ; that is: if self._index == 0: otherwise your code looks very nice to me, though I just had a very quick look ;) regards, GS. -- http://mail.python.org/mailman/listinfo/python-list
use of __new__ to permit "dynamic" completion within (any?) IDE ?
Hi, I met a situation where I was passing an object created in/with an upper level module class to a lower level module class' instance in one of its __init__ argument and saving a ref of the upper object in that lower level class' new instance. But in my IDE I want the completion to also work from within the lower level module when it's refering to the object passed from the upper level: Well, I'm sure I'm not very clear in my terms (and probably a bit long in the sentence) so here it is in code: files: module1.py subpackage/module2.py file module1.py: from subpackage.module2 import class2 class class1(object): def __new__(cls, _self=None, *args, **kwargs): if _self: ## we've been passed an instance already initialyzed ## so directly return it instead of creating a new object. return _self return object.__new__(cls) def __init__(self, _self=None, *args, **kwargs): if _self: ## we've been passed an instance already initialyzed ## so directly returns ## assert(self is _self) ? return self.object2 = class2(object1=self, "blip", "blop") # others init file module2.py: class class2(object): def __init__(self, object1, *args, **kwargs): from ..module1 import class1 self.object1 = class1(_self=object1)## instead of: self.object1 = object1 ## others functions and/or init.. ## where now I've completion working on self.object1 : ## if I add(or remove) fields/methods in module1 (and save) then ## I have them available(or disappeared) in the completion when executed from this submodule. ## This ofcourse permits to save me of remembering all of the class1 attributes/methods when I'm working with self.object1 from within one of class2 methods. What do you think of this ? I guess there can be others ways of doing this.. ? Thanks, Regards, Greg. note: I'm using Eclipse 3.5.2 with pydev so (I don't really know how others IDE can handle this case) . -- http://mail.python.org/mailman/listinfo/python-list
Re: use of __new__ to permit "dynamic" completion within (any?) IDE ?
On 8 déc, 11:45, Steven D'Aprano wrote:
> On Tue, 07 Dec 2010 07:52:06 -0800, gst wrote:
> > Hi,
>
> > But in my IDE I want the completion to also work from within the lower
> > level module when it's refering to the object passed from the upper
> > level:
>
> "The completion"? What do you mean?
Hi,
I mean the autocompletion feature of my IDE :
when I type "object." then on the "." it shows me possible members/
methods of the 'object'. depending on what my IDE can guess about the
object possible type(s) ; in the worst case it can't guess nothing
about it and that's my point below..
> > Well, I'm sure I'm not very clear in my terms (and probably a bit long
> > in the sentence) so here it is in code:
>
> I'm afraid I have to agree with your, your description is not clear to me.
I hope I'm now ;)
> Unfortunately, neither is your code, because I don't understand *why* you
> do the things you do.
damn. ok let's go..
> > file module1.py:
>
> > from subpackage.module2 import class2
>
> Is it relevant that class2 comes from another module?
yes. hmmm or maybe not completely.. I think it only highly depends on
what the IDE can guess on an object type used inside some methods
depending on the files hierarchy..
> Would your concept work if class1 and class2 were defined in the same file?
I guess yes also.
> > class class1(object):
>
> > def __new__(cls, _self=None, *args, **kwargs):
> > if _self: ## we've been passed an instance already
> > initialyzed
> > ## so directly return it instead of creating a
> > new object.
> > return _self
> > return object.__new__(cls)
>
> Depending on your application, this may be an unsafe assumption. If the
> caller says class1("spam"), your class will return "spam". This may or
> may not be what you want.
I'm always passing the good object type when I do this.
> > def __init__(self, _self=None, *args, **kwargs):
> > if _self: ## we've been passed an instance already
> > initialyzed
> > ## so directly returns
> > ## assert(self is _self) ?
> > return
> > self.object2 = class2(object1=self, "blip", "blop") # others
> > init
>
> Okay, this seems like a fairly straightforward case of adding an
> attribute to your instance that includes a reference to itself. No big
> deal... there's nothing wrong with this, although you are creating a
> reference cycle, which is somewhat of a (mild) code-smell.
that is a worry effectively. (hmm when you say it's a case of adding
an attribute that includes a ref to itself it's not really that (or i
badly understand) : it's adding an attribute to a lower level class
instance that contains a ref to an upper level class instance (which
also contains a ref to the lower level class' instance and that's the
cycle (and that's a bit my worry))
> > file module2.py:
>
> > class class2(object):
>
> > def __init__(self, object1, *args, **kwargs):
>
> > from ..module1 import class1
>
> Now you have a circular import, and that's a pretty major code smell.
> That's dangerous. Try to avoid it. Perhaps the easiest way to avoid it is
> to place class1 and class2 in the same module, and stop writing Java :)
damn if this looks like Java it's really not my will ; I've not made
Java anymore for probably 10 years !
I'll try by putting class1 and class2 in same module (or at same
directory level first) and see if that can do it..
>
> > self.object1 = class1(_self=object1) ## instead of:
> > self.object1 = object1
>
> > ## others functions and/or init..
> > ## where now I've completion working on self.object1 : ## if I
> > add(or remove) fields/methods in module1 (and save) then ## I have
> > them available(or disappeared) in the completion when
> > executed from this submodule.
> > ## This ofcourse permits to save me of remembering all of the
> > class1 attributes/methods when I'm working with self.object1 from within
> > one of class2 methods.
>
> I'm afraid I don't understand what you mean here in these comments. What
> do you mean, "save me of (from?) remembering all the class1 attributes/
> methods..." -- how does it save you from knowing the methods? Whether you
> write this:
>
> instance = class1()
> instance.method()
>
> or this:
>
> instance = class1()
> another_instance = class2(instan
Re: use of __new__ to permit "dynamic" completion within (any?) IDE ?
On 8 déc, 14:09, Steve Holden wrote:
>
> If you'd told us which IDE you were using we might have offered better
> advice, but you seem to want to keep that a secret ("my IDE" tells us
> nothing).
>
sorry it was totally bottom of my first message :
> note: I'm using Eclipse 3.5.2 with pydev so (I don't really know how
others IDE can handle this case) .
now I realyze that my question has not a lot to do with python
language itself and I should resubmit that probably on pydev forums/..
but as I told I wanted to have some advises on the "good" (or not) use
of this "way of doing" with python itself. You already explained me
it's not the best so far.. and I agree although during (my) dev it
helps ;) (but I do this only with very few classes that have lot of
attributes/methods ofcourse).
regards,
greg.
--
http://mail.python.org/mailman/listinfo/python-list
Re: use of __new__ to permit "dynamic" completion within (any?) IDE ?
On 8 déc, 15:51, Jean-Michel Pichavant wrote:
Hi,
> gst wrote:
> > nb: so this "hack" is only relevant during dev ; once the project
> > would be finished the "hack" could be removed (i.e : in class2 init I
> > would directly do : self.object1 = object1)
>
> Expect some bugs then on the 'release' version.
even with the "assert(self is _self)" in the "if _self:" condition in
the new and/or init methods of the class1 ?
> I'm not sure I understood everything you mentioned in your OP, however
> writing python code on class creation to make Eclipse completion 'work'
> is ... a very bad idea IMO.
> Just don't do it.
yes I'm trying to find better ways for having completion works out of
the box in this case.. (that would be a high help to my opinion).
> quoting eclipse page:
>
> "Pydev [...] uses advanced type inference techniques to provide features
> such code completion and code analysis"
>
> I don't know exactly what's hidden behind this marketing stuff. Did you
> try to document your method with a markup language supported by Eclipse
> (if there is any)?
pydev completion apparently is restricted (as far as i see) to some
very specific cases (basically it works when you import a module at
top of another one and that you instantiate objects from the imported
module within the init methods of the classes of the module which is
importing the other one (but so "circular" references created on some
objects from the first module (the one imported) in the second one
won't have the completion working for them (that's what I see)).
> class class2(object):
> def __init__(self, object1, *args, **kwargs):
> """blablabla
>
> @param object1: a L{class1} reference
> """
> self.object1 = object1
>
> The docstring would be the only way for an IDE to infer a argument type.
> Note that I used the epydoc markup language because it's the only one I
> know but it's unlikely supported by Eclipse. You better try
> reStructuredText.
>
> JM
well, I'm not very used to docstrings in fact but it's effectively a
way to achieve this ; well certainly better than doing this kind of
"ugly" hack so.
I'll have a try at that.
Thanks for your reply,
regards,
greg.
--
http://mail.python.org/mailman/listinfo/python-list
Re: use of __new__ to permit "dynamic" completion within (any?) IDE ?
On 8 déc, 16:20, gst wrote: > On 8 déc, 15:51, Jean-Michel Pichavant wrote: > > Hi, > > > gst wrote: > > > nb: so this "hack" is only relevant during dev ; once the project > > > would be finished the "hack" could be removed (i.e : in class2 init I > > > would directly do : self.object1 = object1) > > > Expect some bugs then on the 'release' version. > > even with the "assert(self is _self)" in the "if _self:" condition in > the new and/or init methods of the class1 ? note: I don't know if that matters but I'm using __slots__ in this class1 .. greg. -- http://mail.python.org/mailman/listinfo/python-list
Re: use of __new__ to permit "dynamic" completion within (any?) IDE ?
On 8 déc, 16:20, gst wrote: > even with the "assert(self is _self)" in the "if _self:" condition in > the new and/or init methods of the class1 ? damn : in the init method only of course.. -- http://mail.python.org/mailman/listinfo/python-list
Re: PTH files: Abs paths not working as expected. Symlinks needed?
Le mercredi 15 février 2017 10:34:42 UTC-5, Steve D'Aprano a écrit : > On Wed, 15 Feb 2017 11:42 pm, poseidon wrote: > > > Yes, removed it (symlink still there) and it still works. But then, what > > are pth files for? > > > Good question. I don't actually know anyone that uses pth files, so perhaps > they're unnecessary. > when used with the "import " mechanism they can be used as a startup hook for instance, which can be pretty useful. -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio does not always show the full traceback
Le mercredi 1 mars 2017 09:25:48 UTC-5, Frank Millman a écrit :
> "Frank Millman" wrote in message news:o93vs2$smi$1...@blaine.gmane.org...
SNIP
>
> If you run this as is, it works.
>
> I added '1/0' at various points, to force an exception.
>
> If I put it in main() or in aenum(), I do not get the full traceback.
>
> If I put it in aenumerate() or in gen(), I do get the traceback.
>
Hi,
I ran your snippet, using 3.6 under Linux, and get the correct (imo) full
traceback in all cases :
ZeroDivisionError Traceback (most recent call last)
in ()
25
26 loop = asyncio.get_event_loop()
---> 27 loop.run_until_complete(main())
/opt/softs/python/3.6/lib/python3.6/asyncio/base_events.py in
run_until_complete(self, future)
464 raise RuntimeError('Event loop stopped before Future
completed.')
465
--> 466 return future.result()
467
468 def stop(self):
in main()
22
23 async def main():
---> 24 await aenum()
25
26 loop = asyncio.get_event_loop()
in aenum()
14
15 async def aenum():
---> 16 1/0
17 g = gen(5)
18 async for a, x in aenumerate(g):
ZeroDivisionError: division by zero
In [5]:
BUT !
There is one time where I got a RuntimeError, and it's with 1/0 placed inside
aenumerate() (after the yield) :
In [8]:
...: import asyncio
...: from itertools import count
...:
...: async def aenumerate(aiterable):
...: counter = count()
...: async for x in aiterable:
...: yield next(counter), x
...: await asyncio.sleep(0.5)
...: 1/0
...:
...: async def gen(n):
...: for i in range(100, 100+n):
...: yield i
...:
...: async def aenum():
...: g = gen(5)
...: async for a, x in aenumerate(g):
...: print(a, x)
...: print('done')
...:
...: async def main():
...:
...: await aenum()
...:
...: loop = asyncio.get_event_loop()
...: loop.run_until_complete(main())
...:
0 100
---
RuntimeError Traceback (most recent call last)
in ()
25
26 loop = asyncio.get_event_loop()
---> 27 loop.run_until_complete(main())
/opt/softs/python/3.6/lib/python3.6/asyncio/base_events.py in
run_until_complete(self, future)
462 future.remove_done_callback(_run_until_complete_cb)
463 if not future.done():
--> 464 raise RuntimeError('Event loop stopped before Future
completed.')
465
466 return future.result()
RuntimeError: Event loop stopped before Future completed.
In [9]:
I tried reproducing it but couldn't. Other trials now always show the full
traceback up to the 1/0 expression.
Not sure this helps you though..
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamically replacing an objects __class__; is it safe?
Hi, You can subclass M2 from M1 and override only what you need. Regards, -- https://mail.python.org/mailman/listinfo/python-list
Question About When Objects Are Destroyed
'two' is a so called constant or literal value .. (of that function). Why not attach it, as a const value/object, to the function itself ? So that a new string object has not to be created each time the function is called. Because anyway strings are immutable. So what would be the point to recreate such object every time the function is called ? -- https://mail.python.org/mailman/listinfo/python-list
