Cameron Simpson wrote:
[snip]
>
> >The POP3 processing is solely to collect E-Mail that ends up in the
> >'catchall' mailbox on my hosting provider. It empties the POP3
> >catchall mailbox, checks for anything that *might* be for me or other
> >family members then just deletes the rest.
>
> Ver
On 27Aug2020 14:36, Chris Green wrote:
>Cameron Simpson wrote:
>> I do ok, though most of my message processing happens to messages
>> already landed in my "spool" Maildir by getmail. My setup uses getmail
>> to get messages with POP into a single Maildir, and then I process the
>> message files
Cameron Simpson wrote:
> On 27Aug2020 09:16, Chris Green wrote:
> >Cameron Simpson wrote:
> >> But note: joining bytes like strings is uncommon, and may indicate
> >> that
> >> you should be working in strings to start with. Eg you may want to
> >> convert popmsg from bytes to str and do a str.
On 27Aug2020 09:16, Chris Green wrote:
>Cameron Simpson wrote:
>> But note: joining bytes like strings is uncommon, and may indicate
>> that
>> you should be working in strings to start with. Eg you may want to
>> convert popmsg from bytes to str and do a str.join anyway. It depends on
>> exactl
Cameron Simpson wrote:
> On 26Aug2020 15:09, Chris Green wrote:
> >2qdxy4rzwzuui...@potatochowder.com wrote:
> >> Join bytes objects with a byte object:
> >>
> >> b"\n".join(popmsg[1])
> >
> >Aaahhh! Thank you (and the other reply).
>
> But note: joining bytes like strings is uncommon, and
On 26Aug2020 15:09, Chris Green wrote:
>2qdxy4rzwzuui...@potatochowder.com wrote:
>> Join bytes objects with a byte object:
>>
>> b"\n".join(popmsg[1])
>
>Aaahhh! Thank you (and the other reply).
But note: joining bytes like strings is uncommon, and may indicate that
you should be working i
2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2020-08-26 at 14:22:10 +0100,
> Chris Green wrote:
>
> > I have the following line in Python 2:-
> >
> > msgstr = string.join(popmsg[1], "\n") # popmsg[1] is a list containing
> the lines of the message
> >
> > ... so I changed it to:-
> >
> >
On 2020-08-26 14:22, Chris Green wrote:
I have the following line in Python 2:-
msgstr = string.join(popmsg[1], "\n") # popmsg[1] is a list
containing the lines of the message
... so I changed it to:-
s = "\n"
msgstr = s.join(popmsg[1]) # popmsg[1] is a list containin
On 2020-08-26 09:22, Chris Green wrote:
> I have the following line in Python 2:-
>
> msgstr = string.join(popmsg[1], "\n") # popmsg[1] is a list
> containing the lines of the message
>
> ... so I changed it to:-
>
> s = "\n"
> msgstr = s.join(popmsg[1]) # popmsg[1] is a l
On 2020-08-26 at 14:22:10 +0100,
Chris Green wrote:
> I have the following line in Python 2:-
>
> msgstr = string.join(popmsg[1], "\n") # popmsg[1] is a list
> containing the lines of the message
>
> ... so I changed it to:-
>
> s = "\n"
> msgstr = s.join(popmsg[1]) # po
Amit Regmi neolinuxsolutions.com> writes:
> For some commad Linux like (pdbedit) its not possible to supply password
> in the command line itself while we add a samba user account into the
You might be able to utilize pexpect for this. Go google :)
Diez
--
http://mail.python.org/mailman/lis
> From my point of view, they're basically identical, and
> although I find Carl's approach slightly less explicit
> and harder to read (mainly the uncommon __import__ call,
> but it's not a big deal), I can't see why either of them
> would be considered evil.
Of course, when I said evil, I didn't
Carl Banks wrote:
It's a bit more honest to set module attributes using setattr than dict
access, I would say.
Granted.
But I think it's also more honest to change a module's dict by
using globals() than by using a setattr call. <0.500 wink>
-Peter
--
http://mail.python.org/mailman/listinfo/pytho
Carl Banks wrote:
Nick Coghlan wrote:
to that module is far more evil than playing with globals() ;)
I'd say using globals() is far eviler.
I don't understand either of you. ;-)
From my point of view, they're basically identical, and
although I find Carl's approach slightly less explicit
and hard
Nick Coghlan wrote:
> Well, aside from the detail that modifying a module's contents via a
reference
> to that module is far more evil than playing with globals() ;)
>
> Even if that module is the one you're running in. . .
It seems to me that that which makes modifying a module's contents via
a r
Carl Banks wrote:
Modifying globals() not even necessary for this. When I want to
dynamically update the global namespace, I do it this way:
mod = __import__(__name__)
setattr(mod,symbol,value)
Works perfectly unless you're worried about someone modifying the built
in __import__.
Well, aside from
Peter Hansen wrote:
> In general I would say that mucking with globals() like this is
> probably best restricted to constants like in this case, if at all.
Modifying globals() not even necessary for this. When I want to
dynamically update the global namespace, I do it this way:
mod = __import__(
Peter Hansen wrote:
The main way I use this is in some sort of a "const" module, which
provides access to a large set of constant information. In other
words, in contrast to what you had in mind when you wrote the
above, I'm dealing with neither "variables" nor information that
_would_ best be put
Jeff
I do the same thing in Delphi -> prepend "Self" before all the members in
class methods even though its not required. I do it partially for the
same reason as you - so I can grok which variables are local and which are
global (well, global within the class, anyway).
The other reason is
Jeff Shannon wrote:
Of course, just because modifications of the dict returned by globals()
*do* reliably result in modifications to the global namespace, doesn't
mean it's a good idea. ;)
"The" global namespace misses the possibility that doing this in
"a" global namespace might be a good idea.
Nick Coghlan wrote:
Peter Hansen wrote:
Nick, could you please comment on why you say this about globals()?
I've never heard of any possibility of "unreliability" in updating
globals() and, as far as I know, a large body of code exists which
does in fact rely on this -- much of mine included. ;-)
On Tue, 07 Dec 2004 21:12:24 GMT, "It's me" <[EMAIL PROTECTED]> wrote:
>
>"Caleb Hattingh" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> Hi It's me
>>
>> >
>> > a = 3
>> > y = "a"
>> > print eval(y)
>> >
>>
>> To get 'a' to be 4 here, you would say
>>
>> a = 4
>>
>
>O
Both Peters :)
Sure, I must concede that the problem here was my expectation of how
things should work.
Thanks for the explanations. I still don't really know whether this
behaviour of locals() is the result of a design decision, or an
implementation artifact of CPython, but at least I have a cl
Peter Hansen wrote:
Nick Coghlan wrote:
Generally, altering the contents of the dicts returned by locals() and
globals() is unreliable at best.
Nick, could you please comment on why you say this about globals()?
I've never heard of any possibility of "unreliability" in updating
globals() and, as
Caleb Hattingh wrote:
> I am convinced now that locals() doesn't work as (I) expected. Steven
> says there was some or other reason why locals() as used in this context
> is not writable - Do you know why this is? I really do not like
> guidelines like "may not work", "is unreliable" and so on.
Peter Hansen wrote:
> Caleb Hattingh wrote:
>> I am convinced now that locals() doesn't work as (I) expected. Steven
>> says there was some or other reason why locals() as used in this
>> context is not writable - Do you know why this is? I really do not
>> like guidelines like "may not work",
Caleb Hattingh wrote:
I am convinced now that locals() doesn't work as (I) expected. Steven
says there was some or other reason why locals() as used in this
context is not writable - Do you know why this is? I really do not
like guidelines like "may not work", "is unreliable" and so on.
P
Thx Peter
I verified this situation myself with a post from Steven Bethard earlier
(trying to use "locals" within a function definition).
I am convinced now that locals() doesn't work as (I) expected. Steven
says there was some or other reason why locals() as used in this context
is not wri
Caleb Hattingh wrote:
> In what way is it unreliable? I can't seem to create a situation where
> the update through globals and locals doesn't work. Are you referring
Updates to a locals() dictionary may not be reflected by the variables in
the local scope, e. g.:
>>> def f():
... locals(
Peter, I second that.
Nick
In what way is it unreliable? I can't seem to create a situation where
the update through globals and locals doesn't work. Are you referring
perhaps to the possibility of variables being garbage collected and then
not being around later when one tries to access t
Nick Coghlan wrote:
Generally, altering the contents of the dicts returned by locals() and
globals() is unreliable at best.
Nick, could you please comment on why you say this about globals()?
I've never heard of any possibility of "unreliability" in updating
globals() and, as far as I know, a larg
Caleb Hattingh wrote:
'>>> a # The value of a is changed.
8
'>>>
The value of a is changed. . . *maybe*.
The Python language definition states explicitly that updates to the dictionary
returned by locals() may not actually alter the local variables.
Generally, altering the contents o
It's me wrote:
Yes, Russell, what you suggested works.
I have to chew more on the syntax to see how this is working.
because in the book that I have, it says:
exec code [ in globaldict [, localdict] ]
The [] indicate the last two parts are optional. If you don't supply them, exec
just uses the
It's me wrote:
For simplicity sake, let's say I need to do something like this (for
whatever reason):
If I had a situation like this, I'd probably store my 'variables' as
keys in a dict, e.g.:
>>> bindings = {}
>>> for i in range(3):
... name = raw_input('Name: ')
... value = int(raw_i
Thanks for all the replies and yes I realize the associated issue of doing
something like this.
For simplicity sake, let's say I need to do something like this (for
whatever reason):
In situations like this, I wouldn't know the name of the variable in Python
I need to use ahead of time and so
Yes, Russell, what you suggested works.
I have to chew more on the syntax to see how this is working.
because in the book that I have, it says:
exec code [ in globaldict [, localdict] ]
...
--
It's me
"Russell Blau" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "It's me"
It's me wrote:
How do I do something like this:
I know that
a = 3
y = "a"
print eval(y)
would give me a print out of 3 - but how do I do something to the effect of:
eval(y) = 4# hopefully the value of a gets changed to 4
Generally, if you find yourself doing this, you may want t
On Wed, 2004-12-08 at 05:12, It's me wrote:
> There are many situations where this is useful. For instance, you might be
> getting an input which is a string representing the name of a variable and
> you wish to evaluate the expression (like a calculator application, for
> instance).
While I do
It's me wrote:
In REXX, for instance, one can do a:
interpret y' = 4'
Since y contains a, then the above statement amongs to:
a = 4
The direct equivalent in Python would be
a = 3
y = 'a'
exec '%s = 4' % y
The better question would be whether or not this as useful as
"It's me" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> In REXX, for instance, one can do a:
>
> interpret y' = 4'
>
> Since y contains a, then the above statement amongs to:
>
> a = 4
>
> There are many situations where this is useful. For instance, you might
be
> getti
Sure, ok, I think I am with you now.
You get a (e.g.) variable name as a string, and you KNOW how to evaluate
it with "eval", but you also want to be able to assign back to (through)
the string representation?
One way (if I understand you correctly) is with the globals or locals
dicts. Try
"Caleb Hattingh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi It's me
>
> >
> > a = 3
> > y = "a"
> > print eval(y)
> >
>
> To get 'a' to be 4 here, you would say
>
> a = 4
>
Obviously but that's not what I wish to do.
> I am not sure why you would want to do othe
Hi It's me
a = 3
y = "a"
print eval(y)
To get 'a' to be 4 here, you would say
a = 4
I am not sure why you would want to do otherwise? Perhaps you could
sketch out a little more about what you are trying to do? That would help
a lot. Are you aiming for something like point
43 matches
Mail list logo
