Re: Passing information between modules
In a module mostly for this purpose; ( big program means many modules aka files
):
--
globalIdeas.py
--
# Empty object maker ( M T ) ... get it say it !
class MT():
pass
# IO dot area readier
def prepIO():
# Prep for general IO use really
dotObjOps.ioSupport = MT()
dotObjOps.ioSupport.sequenceMacro = MT()
-
In Every use module:
-
import globalIdeas as gi
so now without burdensome advanced planning, a swap area is not only segregated
by function
but doesn't overly pollute too much globalism everywhere.
New Idea:
gl.ioSupport.sequencesMacro.newStartupIdea = {}
gl.ioSupport.sequencesMacro.thingToReuse = 14
etc ...
A method in globalIdeas is named like startEverything():
prepIO()
prepNext()
prepSounds()
etc...
This seems to me amenable to management of large programs in which absolutely
any shaped objects be created as needed and be RW sharable in orderly fashion,
etc.
Its important if you read write files to plan ahead and have MT() names in
surplus before you need them.
I cant see any drawback to this at all. Many program have very legit reasons to
have universal ideas. This avoids the emotional burden of the' "global KW" ;
entirely.
Regards,
Daniel B. Kolis
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging
On 20Nov2022 12:36, Chris Angelico wrote: On Sun, 20 Nov 2022 at 12:27, Cameron Simpson wrote: But really, is there any problem which cannot be solved with a decorator? I've even got a @decorator decorator for my decorators. Do you have a @toomanydecorators decorator to reduce the number of decorators you need to decorate your decorators? Apparently not :-) @classmethod @pfx_method @promote @typechecked def promote(cls, policy, epoch: Optional[Epoch] = None, **policy_kw): and there aren't even any @require decorators on that one (from the excellent icontract package). Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Superclass static method name from subclass
On 11/13/2022 7:27 AM, Axy via Python-list wrote:
On 11/11/2022 16:21, Ian Pilcher wrote:
Is it possible to access the name of a superclass static method, when
defining a subclass attribute, without specifically naming the super-
class?
A instance's __bases__ attribute is a sequence that contains all its
base classes. So:
class A:
@staticmethod
def double(n):
return 2 * n
class B(A):
def parent_method(self, n):
par = self.__class__.__bases__[0] # For single inheritance
return par.double(n)
b = B()
print(b.parent_method(3)) # 6
# or
print(b.__class__.__bases__[0].double(4)) # 8
Contrived example:
class SuperClass(object):
@staticmethod
def foo():
pass
class SubClass(SuperClass):
bar = SuperClass.foo
^^
Is there a way to do this without specifically naming 'SuperClass'?
There is, but it's weird. I constructed classes from yaml config so I
did not even know the name of super class but I wanted similar things
for my clabate templates and I implemented superattr() which works for me:
class BasePage:
body = 'Hello'
class MySpecificPage(BasePage):
body = superattr() + 'World'
Actually, it's suboptimally elegant code. Artistic code, to be clear, as
if you looked at modern art and thought: WTF? Also, it's specific for
templates only and supports only __add__.
But I think the approach can be extended to a general superclass() if
you log __getattr__ calls and apply them in __get__ method same way.
I realize this reply is not an immediate help and probably won't help,
but there's always a way out.
Axy.
Here's the code:
class superattr:
'''
This is a descriptor that allows extending attributes in a simple and
elegant way:
my_attr = superattr() + some_addition_to_my_attr
'''
def __init__(self):
self.additions = []
def __set_name__(self, owner, name):
print('__set_name__', name)
self.attr_name = name
def __get__(self, obj, objtype=None):
for cls in obj.__class__.__mro__[1:]:
try:
value = getattr(cls, self.attr_name)
except AttributeError:
continue
for a in self.additions:
value = value + a
return value
raise AttributeError(self.attr_name)
def __add__(self, other):
print('__add__:', other)
self.additions.append(other)
return self Full article:
https://declassed.art/en/blog/2022/07/02/a-note-on-multiple-inheritance-in-python
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging
On Sun, 20 Nov 2022 at 12:27, Cameron Simpson wrote: > > On 19Nov2022 18:26, Thomas Passin wrote: > >>The alternative is to just replace every calling function which uses > >>my_ugly_debug() to directly call a logging.whatever() call. > > > >Maybe a place for a decorator... > > Indeed, though I don't think the OP is up to decorators yet. > > But really, is there any problem which cannot be solved with a > decorator? I've even got a @decorator decorator for my decorators. > Do you have a @toomanydecorators decorator to reduce the number of decorators you need to decorate your decorators? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Logging
On 19Nov2022 18:26, Thomas Passin wrote: The alternative is to just replace every calling function which uses my_ugly_debug() to directly call a logging.whatever() call. Maybe a place for a decorator... Indeed, though I don't think the OP is up to decorators yet. But really, is there any problem which cannot be solved with a decorator? I've even got a @decorator decorator for my decorators. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Logging
On 11/19/2022 5:27 PM, Cameron Simpson wrote: On 19Nov2022 11:08, Stefan Ram wrote: writes: You are expected to implement logging feature to an existing code which uses the function below. [...] You are not allowed to make changes in my_ugly_debug, so find another way. If found a solution that is even more ugly than your function. I was just about to post it here, but then remembered about the "no homework" rule. Bummer! I suspect that the OP is just being asked to modify existing code which calls my_ugly_debug to use more conventional logging calls. Baran, in addition to the various info(), warning() etc logging calls there is a log() logging call which accepts a log level (the warning() etc calls basicly call this with their own logging level). I would be inclined to write a my_better_debug(s,level=0) function which took those existing levels (0,1,2) and mapped them to the official logging levels logging.INFO, logging.WARNING etc, and then called logging.log() with the official level. Then adjust the calling code to call your new function. The alternative is to just replace every calling function which uses my_ugly_debug() to directly call a logging.whatever() call. Maybe a place for a decorator... Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 18Nov2022 10:53, Stefan Ram wrote:
Can I use "sys.argv" to pass information between modules
as follows? [...]
Stefan, it looks like most of the replies take the form: yes you can do
that but it is probably a bad idea.
Could you outline the larger situation where you want to do this? Often
this kind of response ("yes but don't!") can be a clue that you're
chasing the wrong (sorry, "suboptimal/poor") solution to a problem which
can be solved in another way.
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging
On 19Nov2022 11:08, Stefan Ram wrote: writes: You are expected to implement logging feature to an existing code which uses the function below. [...] You are not allowed to make changes in my_ugly_debug, so find another way. If found a solution that is even more ugly than your function. I was just about to post it here, but then remembered about the "no homework" rule. Bummer! I suspect that the OP is just being asked to modify existing code which calls my_ugly_debug to use more conventional logging calls. Baran, in addition to the various info(), warning() etc logging calls there is a log() logging call which accepts a log level (the warning() etc calls basicly call this with their own logging level). I would be inclined to write a my_better_debug(s,level=0) function which took those existing levels (0,1,2) and mapped them to the official logging levels logging.INFO, logging.WARNING etc, and then called logging.log() with the official level. Then adjust the calling code to call your new function. The alternative is to just replace every calling function which uses my_ugly_debug() to directly call a logging.whatever() call. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 11/19/2022 3:46 PM, Michael F. Stemper wrote: On 18/11/2022 04.53, Stefan Ram wrote: Can I use "sys.argv" to pass information between modules as follows? in module A: import sys sys.argv.append( "Hi there!" ) in module B: import sys message = sys.argv[ -1 ] I just tried and it appears that one can append to sys.argv. However, it seems like an incredibly bad idea. For that matter, you can just directly add attributes to the sys module, no need to use sys.argv: >>> import sys >>> sys._extra = 'spam' # Not an exception >>> print(sys._extra) spam Probably not the best idea, though. Better to use some module that you control directly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 11/19/2022 4:28 PM, Thomas Passin wrote: On 11/19/2022 3:46 PM, Michael F. Stemper wrote: On 18/11/2022 04.53, Stefan Ram wrote: Can I use "sys.argv" to pass information between modules as follows? in module A: import sys sys.argv.append( "Hi there!" ) in module B: import sys message = sys.argv[ -1 ] I just tried and it appears that one can append to sys.argv. However, it seems like an incredibly bad idea. For that matter, you can just directly add attributes to the sys module, no need to use sys.argv: >>> import sys >>> sys._extra = 'spam' # Not an exception >>> print(sys._extra) spam Probably not the best idea, though. Better to use some module that you control directly. This could be one of those things of which Raymond Chen (The Old New Thing) asks "what if everyone did this?". Imagine if every (non-standard-library) module misused sys or sys.argv like this. The result could be chaotic. Best to put all your own stuff into modules that you yourself control. -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 18/11/2022 04.53, Stefan Ram wrote: Can I use "sys.argv" to pass information between modules as follows? in module A: import sys sys.argv.append( "Hi there!" ) in module B: import sys message = sys.argv[ -1 ] I just tried and it appears that one can append to sys.argv. However, it seems like an incredibly bad idea. -- Michael F. Stemper The name of the story is "A Sound of Thunder". It was written by Ray Bradbury. You're welcome. -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 18/11/2022 23.53, Stefan Ram wrote: Can I use "sys.argv" to pass information between modules as follows? in module A: import sys sys.argv.append( "Hi there!" ) in module B: import sys message = sys.argv[ -1 ] . "sys.argv" is said to be a list by the standard documentation, so it should be guaranteed to be appendable as lists are appendable. Moreover, in my own program, after its startup, third parties do not inspect "sys.argv". So by appending something to it (or modifying it) I do not tamper with information that might be misinterpreted by any third party outside of my own code. Another hack might be: in module A import builtins builtins.message = "Hi there!" in module B import builtins message = builtins.message But I'm not sure whether modules (such as "builtins" here) are guaranteed to be modifyable and visible by the language reference in this way though The re-use of built-in features is risky, if only because of the remote possibility that a future version of Python will add something that clashes. That's why Python makes such good (and careful) use of namespaces! In some respects we have the (OP) problem because Python does not have "interfaces" as a formal component of the language. So, we often get-away with taking an easier course - but in doing-so, may forget that they serve specific purposes. There is a general idea that globals are harmful, a code-smell, etc; and therefore something to be avoided. However, the global namespace is a (built-in!) feature of Python, so why not use it? The problem comes when we try to re-use module A or B in some other application. It may not be relatively-obvious that some global, eg config, must be previously-defined and made-available. If you're prepared to accept that risk - and presumably combat the criticism by carefully (and prominently) documenting it, just as with any other docstring, where's the problem? (caveat emptor!) Considering the use-case, it is unlikely to be as trivial as the example-given (OP). A classic example would be set of credentials to access an RDBMS and specific table(s). A 'standard' solution is to collect all such configuration-data at the start of the application, into an object (or other data-structure) - I usually call it "env" (an instantiation of "Environment"). Thereafter, when needing such data within a module, calling the particular function/class/method by name (moduleNM.function(...) ), and passing only that section of the env[ironment] required. Such achieved by passing some sub-structure of env, or by passing a retrieval/get method. (a module handling GUI, for example, has no business looking at RDBMS-creds - which it would be able to do if the whole env was passed!) but... the module's code will expect its data in a particular form (an interface!), which must be documented and understood by both the provider and consumer (people and software) - which sounds like the same 'solution' to the 'globals problem'... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Logging
How can I solve this question?
There is a module called ‘logging’ to
employ logging facility in Python.
import logging
logging. info('Just a normal message' )
Logging.warning('Not fatal but still noted')
logging.error('There is something wrong')
You are expected to implement logging
feature to an existing code which uses the
function below.
def my_ugly_debug(s, level=0):
pre_text = [ "INFO",
"WARNING",
"ERROR"
]
print(f"{pre_text[level]}: {s}")
You are not allowed to make changes in my_ugly_debug, so find another way.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help Merging Of Separate Python Codes
On 20/11/2022 02.20, maria python wrote: Hello, I have these two python codes that work well separately and I want to combine them, but I am not sure how to do it. Also after that, I want to print the result in txt cvs or another file format. Do you have a code for that? Thank you. Have you tried joining them together, one after the other? Have you looked at the Python docs? eg https://docs.python.org/3/library/csv.html Do you need the help of a professional to write code for you? If you are learning Python, perhaps the Tutor list will be a more appropriate for you... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
