On Tue, Jul 24, 2012 at 1:32 PM, Paul Rubin wrote:
> Dieter Maurer writes:
>> I have only one vague idea: should something try to terminate the
>> process, modules would start to lose their variables during shutdown.
>
> That happens all the time with multi-threaded programs, because the
> shutdo
eption info: Traceback (most recent call last):
>> File "scheduler.py", line 376, in applyrule
>> result = execrule(rule_code)
>> File "scheduler.py", line 521, in execrule
>> rulepath =
>> os.path.dirname(__file__)+"/"+'/&#x
Dieter Maurer writes:
> I have only one vague idea: should something try to terminate the
> process, modules would start to lose their variables during shutdown.
That happens all the time with multi-threaded programs, because the
shutdown is happening concurrently with other threads doing stuff.
er.py", line 376, in applyrule
> result = execrule(rule_code)
> File "scheduler.py", line 521, in execrule
> rulepath =
> os.path.dirname(__file__)+"/"+'/'.join(rule['modules'])+"/"+rule['rulename']
> NameErro
e following
> exception:
> >
> >File "/some/path/scheduler.py", line 376, in applyrule
> > result = execrule(rule_code)
> >File "/some/path/scheduler.py", line 521, in execrule
> > rulepath =
> os.path.dirname(__file__)+"/&
roblems. At some point I start getting the
> exception:
> >
> > Exception info: Traceback (most recent call last):
> > File "scheduler.py", line 376, in applyrule
> > result = execrule(rule_code)
> > File "scheduler.py", line 521, in
If you use fork(), it drops all file descriptors, and creates new
ones - may be then loss the __file__...?
I don't think this is the case. He wrote that the process runs for weeks
without problems, and code using __file__ is being executed all the time.
--
http://mail.python.org/ma
= execrule(rule_code)
File "/some/path/scheduler.py", line 521, in execrule
rulepath =
os.path.dirname(__file__)+"/"+'/'.join(rule['modules'])+"/"+rule['rulename']
NameError: name '__file__' is not defined
It is not a direct s
t recent call last):
> File "scheduler.py", line 376, in applyrule
> result = execrule(rule_code)
> File "scheduler.py", line 521, in execrule
> rulepath =
> os.path.dirname(__file__)+"/"+'/'.join(rule['modules'])+"/&quo
r.py", line 521, in execrule
rulepath =
os.path.dirname(__file__)+"/"+'/'.join(rule['modules'])+"/"+rule['rulename']
NameError: name '__file__' is not defined
This section is executed *all the time* but somehow stops working after a
de)
File "scheduler.py", line 521, in execrule
rulepath =
os.path.dirname(__file__)+"/"+'/'.join(rule['modules'])+"/"+rule['rulename']
NameError: name '__file__' is not defined
This section of the code is executed in thi
On 12/12/11 1:25 AM, MRAB wrote:
On 12/12/2011 00:21, Steven D'Aprano wrote:
I've just started using a Debian system, instead of the usual RedHat
based systems I'm used to, and module.__file__ appears to have
disappeared for some (but not all) modules.
On Fedora:
[steve@ora
On 12/12/2011 00:21, Steven D'Aprano wrote:
I've just started using a Debian system, instead of the usual RedHat
based systems I'm used to, and module.__file__ appears to have
disappeared for some (but not all) modules.
On Fedora:
[steve@orac ~]$ python -E
Python 2.6.2 (r262:716
I've just started using a Debian system, instead of the usual RedHat
based systems I'm used to, and module.__file__ appears to have
disappeared for some (but not all) modules.
On Fedora:
[steve@orac ~]$ python -E
Python 2.6.2 (r262:71600, Aug 21 2009, 12:22:21)
[GCC 4.4.1 2009081
On Fri, 1 Oct 2010 21:00:02 +0200
Sébastien Barthélemy wrote:
> Hi,
>
> Arnaud, Christian, thank you for your help.
>
> I'll use abspath, it's shorter.
>
> Any idea why it's sometimes absolute, sometimes not?
AFAICT, that's because sys.path contains some absolute paths and some
relative ones.
Hi,
Arnaud, Christian, thank you for your help.
I'll use abspath, it's shorter.
Any idea why it's sometimes absolute, sometimes not?
--
http://mail.python.org/mailman/listinfo/python-list
lace both
> during development and after and install.
>
> In my program, I need to find the absolute path to this data file.
>
> I could think of 3 ways to do this:
> 1. using the __path__ property in the module
> 2. using __file__ property in the module
> 3. using __file__ and
ve, so it is in place both
> during development and after and install.
>
> In my program, I need to find the absolute path to this data file.
>
> I could think of 3 ways to do this:
> 1. using the __path__ property in the module
> 2. using __file__ property in the module
> 3.
need to find the absolute path to this data file.
I could think of 3 ways to do this:
1. using the __path__ property in the module
2. using __file__ property in the module
3. using __file__ and os.getcwd() in the module
The first option does not work, because __path__ is initialised after the
module
On Aug 15, 2:19 pm, Christian Heimes wrote:
> wgw wrote:
> > I don't understand why the __file__ value in my installation of PyQt
> > would not give a proper, full path.
>
> > I'm guessing that I did not install pyqt properly (I'm on Ubuntu
> > Hardy,
wgw wrote:
I don't understand why the __file__ value in my installation of PyQt
would not give a proper, full path.
I'm guessing that I did not install pyqt properly (I'm on Ubuntu
Hardy, trying to install QT4.5), but before redoing the install, I
want to see if there is a quic
I don't understand why the __file__ value in my installation of PyQt
would not give a proper, full path.
I'm guessing that I did not install pyqt properly (I'm on Ubuntu
Hardy, trying to install QT4.5), but before redoing the install, I
want to see if there is a quicker fix.
Als
I think I have figured this out, thanks for your input.
The time comes from lazy modules related to e-mail importing on
attribute access, which is acceptable. Hence of course
why ImportError was sometime raised.
I originally was thinking that accessing __file__ was triggering some
mechanism that
En Fri, 05 Jun 2009 00:12:25 -0300, John Machin
escribió:
> (2) This will stop processing on the first object in sys.modules that
> doesn't have a __file__ attribute. Since these objects aren't
> *guaranteed* to be modules,
Definitely not guaranteed to be modules. Pyth
Steven D'Aprano REMOVE.THIS.cybersource.com.au> writes:
>
> On Fri, 05 Jun 2009 02:21:07 +, Steven D'Aprano wrote:
>
> > You corrected this to:
> >
> > for module in sys.modules.itervalues():
> >try:
> >path
Zac Burns wrote:
The section of code below, which simply gets the __file__ attribute of
the imported modules, takes more than 1/3 of the total startup time.
Given that many modules are complicated and even have dynamic
population this figure seems very high to me. it would seem very high
if one
On Fri, 05 Jun 2009 02:21:07 +, Steven D'Aprano wrote:
> You corrected this to:
>
> for module in sys.modules.itervalues():
>try:
> path = module.__file__
>except (AttributeError, ImportError):
>return
>
> (
En Thu, 04 Jun 2009 22:24:48 -0300, Zac Burns escribió:
The section of code below, which simply gets the __file__ attribute of
the imported modules, takes more than 1/3 of the total startup time.
Given that many modules are complicated and even have dynamic
population this figure seems very
On Thu, 04 Jun 2009 18:24:48 -0700, Zac Burns wrote:
> The section of code below, which simply gets the __file__ attribute of
> the imported modules, takes more than 1/3 of the total startup time.
How do you know? What are you using to time it?
[...]
> From once python starts and
Sorry, there is a typo. The code should read as below to repro the problem:
for module in sys.modules.itervalues():
try:
path = module.__file__
except (AttributeError, ImportError):
return
The section of code below, which simply gets the __file__ attribute of
the imported modules, takes more than 1/3 of the total startup time.
Given that many modules are complicated and even have dynamic
population this figure seems very high to me. it would seem very high
if one just considered the
On May 16, 3:40 pm, gert wrote:
> On May 16, 3:16 pm, "Diez B. Roggisch" wrote:
>
> > gert schrieb:
>
> > > open(os.path.join(os.path.dirname(__file__),'../www/bin/picture.png'),
> > > 'rb')
> > > how do you do this on
On May 16, 3:16 pm, "Diez B. Roggisch" wrote:
> gert schrieb:
>
> > open(os.path.join(os.path.dirname(__file__),'../www/bin/picture.png'),
> > 'rb')
> > how do you do this on windows (py3) so it still works on linux ?
>
> os.path.join(&q
Diez B. Roggisch wrote:
gert schrieb:
open(os.path.join(os.path.dirname(__file__),'../www/bin/picture.png'),
'rb')
how do you do this on windows (py3) so it still works on linux ?
os.path.join("..", "www", "bin", "picture.png"
gert schrieb:
open(os.path.join(os.path.dirname(__file__),'../www/bin/picture.png'),
'rb')
how do you do this on windows (py3) so it still works on linux ?
os.path.join("..", "www", "bin", "picture.png")
Or use os.sep.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
open(os.path.join(os.path.dirname(__file__),'../www/bin/picture.png'),
'rb')
how do you do this on windows (py3) so it still works on linux ?
--
http://mail.python.org/mailman/listinfo/python-list
Yes, that is my exact question. How do you get the file path of your
script/program. Normally in python you can use __file__ and it will
return the file path of the script you are in, however, when you
compile the script to exe py2exe (or whatever util you are using)
compresses them into a zip
On Jan 6, 7:03 am, TechieInsights wrote:
> __file__ command does not work when compiled to exe. It makes since
> because the file is now in a compressed library. Is there a
> replacement or something else you can do? The real problem is that
> when you create an exe of your program
__file__ command does not work when compiled to exe. It makes since
because the file is now in a compressed library. Is there a
replacement or something else you can do? The real problem is that
when you create an exe of your program with python embedded, you can't
always guarantee that
original justification for the patch no
> > longer applies, and that the secondary purpose of the patch is better
> > solved by leaving __file__ as it is in Python 2.x, and introducing a new
> > attribute __source__.
>
> > What do people think? There seems to be a little int
e patch is better
> solved by leaving __file__ as it is in Python 2.x, and introducing a new
> attribute __source__.
>
> What do people think? There seems to be a little interest on the python-
> dev list from a couple of people, but not enough to actually lead to any
> action. Does a
On 29 Aug 2008 15:21:53 GMT, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
On the python-dev mailing list, a question has be raised about a change
to module.__file__ in Python 3.
http://www.gossamer-threads.com/lists/python/dev/674923#674923
In Python 2.x, m.__file__ is the name of th
On the python-dev mailing list, a question has be raised about a change
to module.__file__ in Python 3.
http://www.gossamer-threads.com/lists/python/dev/674923#674923
In Python 2.x, m.__file__ is the name of the file that the module was
imported from. That file might end with .py, .pyc, .pyo
On Feb 14, 1:50 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Wed, 13 Feb 2008 13:07:31 -0200, alain <[EMAIL PROTECTED]> escribió:
>
> > There exists an undocumented builtin called __file__, but
> > unfortunately no corresponding __line__
>
>
En Wed, 13 Feb 2008 13:07:31 -0200, alain <[EMAIL PROTECTED]> escribió:
> There exists an undocumented builtin called __file__, but
> unfortunately no corresponding __line__
There is no __file__ builtin AFAIK; but there is __file__ module attribute
documented here:
http://docs.py
alain wrote:
> On Feb 12, 7:44 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>
>> It still would be nice to have syntax as clean as __FILE__ and __LINE__.
>
> There exists an undocumented builtin called __file__, but
> unfortunately no corresponding __line__
Drat! So
On Feb 12, 7:44 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> It still would be nice to have syntax as clean as __FILE__ and __LINE__.
There exists an undocumented builtin called __file__, but
unfortunately no corresponding __line__
Alain
--
http://mail.python.org/mailman/listinfo/python-list
h_underscore, the "current" style recommended by
> PEP8 http://www.python.org/dev/peps/pep-0008/ but hurry up before it
> changes!
Right on. Won't I feel silly if the inspect.currentmethods() ever get
renamed,for consistency with the PEP?
It still would be nice to have syntax as
En Tue, 12 Feb 2008 16:20:12 -0200, Jeff Schwab <[EMAIL PROTECTED]>
escribió:
> What about the following? Should the underscores be omitted from the
> method names, for consistency with inspect?
I prefer the names_with_underscore, the "current" style recommended by
PEP8 http://www.python.org
Gabriel Genellina wrote:
> En Tue, 12 Feb 2008 14:41:20 -0200, Jeff Schwab <[EMAIL PROTECTED]>
> escribi�:
>
>> def line():
>> try:
>> raise Exception
>> except:
>> return sys.exc_info()[2].tb_frame.f_back.f_lineno
>> d
Bill Davy wrote:
[...]
> What a lovely langauge.
>
+1 QOTW
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list
En Tue, 12 Feb 2008 14:41:20 -0200, Jeff Schwab <[EMAIL PROTECTED]>
escribi�:
> def line():
> try:
> raise Exception
> except:
> return sys.exc_info()[2].tb_frame.f_back.f_lineno
> def file():
> return ins
sidered. In the example, I would want to report
>> that LoopLable is not referenced, and LoopLabel is not defined.
>>
>> TIA,
>> Bill
>>
>> PSwww.SynectixLtd.comis not relevant
>
> def __LINE__():
> try:
> raise Exception
"thebjorn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Feb 11, 4:55 pm, Gary Herron <[EMAIL PROTECTED]> wrote:
>> Bill Davy wrote:
>> > Writing a quick and dirty assembler and want to give the user the
>> > location
>> > of an error. The "assembly language" is Python. If th
oopLable is not referenced, and LoopLabel is not defined.
>
> TIA,
> Bill
>
> PSwww.SynectixLtd.comis not relevant
def __LINE__():
try:
raise Exception
except:
return sys.exc_info()[2].tb_frame.f_back.f_lineno
def __FILE__():
return inspe
On Feb 11, 4:55 pm, Gary Herron <[EMAIL PROTECTED]> wrote:
> Bill Davy wrote:
> > Writing a quick and dirty assembler and want to give the user the location
> > of an error. The "assembly language" is Python. If the user wants to
> > generat some object code they write something like:
>
> > Labe
Bill Davy wrote:
> Writing a quick and dirty assembler and want to give the user the location
> of an error. The "assembly language" is Python. If the user wants to
> generat some object code they write something like:
>
> Label(LoopLable)
> Load(R4)
> Dec()
> JNZ(LoopLabel)
>
> I
Writing a quick and dirty assembler and want to give the user the location
of an error. The "assembly language" is Python. If the user wants to
generat some object code they write something like:
Label(LoopLable)
Load(R4)
Dec()
JNZ(LoopLabel)
I can use Python to do all the expres
> Thanks, I'll then use sys.getfilesystemencoding() to decode _file__
> and re-encode into utf-8, which is the default encoding of all strings
> in our software, as we deal a bit with Chinese terms.
>
> Windows-1252 on my box. I just created a directory containing Chinese
> characters (on Vista),
On 7 Jan., 23:06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > can someone quickly tell me what the encoding of __file__ is? I can't
> > find it in the documentation.
>
> > BTW, I'm using Python 2.5.1 on WIndows XP and Vista.
>
> It's p
> can someone quickly tell me what the encoding of __file__ is? I can't
> find it in the documentation.
>
> BTW, I'm using Python 2.5.1 on WIndows XP and Vista.
It's platform-specific - the same encoding that is used for file names
(i.e. sys.getfilesystemencoding()). O
Dear all,
can someone quickly tell me what the encoding of __file__ is? I can't
find it in the documentation.
BTW, I'm using Python 2.5.1 on WIndows XP and Vista.
Kind regards,
Sebastian
--
http://mail.python.org/mailman/listinfo/python-list
dline.py
> If I invoke it as 'cmdline.py', then the output is:
> C:\Users\hai\src\python\cmdline.py
>
> The same happens for __file__. My question: do you have any
> suggestions for a more consistent way to figure out the full path of
> your script?
How about::
> use os.path.abspath
Bingo! This is just what the doctor ordered. Thank you.
Hai
--
http://mail.python.org/mailman/listinfo/python-list
cmdline.py
> If I invoke it as 'cmdline.py', then the output is:
> C:\Users\hai\src\python\cmdline.py
>
> The same happens for __file__. My question: do you have any
> suggestions for a more consistent way to figure out the full path of
> your script?
use os.path.abspath
--
http://mail.python.org/mailman/listinfo/python-list
Users\hai\src\python\cmdline.py
The same happens for __file__. My question: do you have any
suggestions for a more consistent way to figure out the full path of
your script?
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 5, 1:07 am, sandipm <[EMAIL PROTECTED]> wrote:
> interestingly...
> I wanted to reuse this code so i wrote function in a file
>
> def getParentDir():
> import os
> return os.path.dirname(os.path.abspath(__file__))
>
> and called this function, in anot
interestingly...
I wanted to reuse this code so i wrote function in a file
def getParentDir():
import os
return os.path.dirname(os.path.abspath(__file__))
and called this function, in another file, its giving me parent
directory of file where this function is defined.?
how to reuse this
On 3 Nov, 15:46, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Sat, 03 Nov 2007 10:07:10 -0300, Giampaolo Rodola' <[EMAIL PROTECTED]>
> escribió:
>
> > On 3 Nov, 04:21, klenwell <[EMAIL PROTECTED]> wrote:
> >> In PHP you ha
klenwell wrote:
> Bjoern Schliessmann wrote:
>> I use os.path.dirname(os.path.abspath(__file__))
>
> That makes sense, as it is almost a literal translation of what
> I'm used to using in PHP. Thanks for pointing this out.
You're welcome, happy coding :)
Regards,
On Nov 3, 4:18 am, Bjoern Schliessmann wrote:
> Jeff McNeil wrote:
> > I've used the 'os.path.realpath(os.path.pardir)' construct in a
> > couple of scripts myself.
>
> In Windows? Using Linux, this gives me "..".
>
> I use os.path.dirname
d()
'/Users/jeff'
>>> os.path.realpath(os.path.pardir)
'/Users'
>>>
The __file__ construct is fine from within a module and is probably
more inline with what the OP was looking for anyways.
On Nov 3, 2007, at 7:18 AM, Bjoern Schliessmann wrote:
> Jeff
En Sat, 03 Nov 2007 10:07:10 -0300, Giampaolo Rodola' <[EMAIL PROTECTED]>
escribió:
> On 3 Nov, 04:21, klenwell <[EMAIL PROTECTED]> wrote:
>> In PHP you have the __FILE__ constant which gives you the value of the
>> absolute path of the file you're in (
On 3 Nov, 04:21, klenwell <[EMAIL PROTECTED]> wrote:
> I apologize in advance for coming at this from this angle but...
>
> In PHP you have the __FILE__ constant which gives you the value of the
> absolute path of the file you're in (as opposed to the main script
>
Jeff McNeil wrote:
> I've used the 'os.path.realpath(os.path.pardir)' construct in a
> couple of scripts myself.
In Windows? Using Linux, this gives me "..".
I use os.path.dirname(os.path.abspath(__file__))
> That ought to work within the interactive interp
The __file__ attribute is present when you run a script from a file.
If you run from the interactive interpreter, it will raise a
NameError. Likewise, I believe that in earlier versions of Python
(2.1? Pre 2.2?) it was only set within imported modules. I've used the
'os.pat
I apologize in advance for coming at this from this angle but...
In PHP you have the __FILE__ constant which gives you the value of the
absolute path of the file you're in (as opposed to the main script
file.) With the function dirname, this makes it easy to get the
parent dir of a parti
On Apr 11, 6:55 am, "John Machin" <[EMAIL PROTECTED]> wrote:
> On Apr 11, 8:03 pm, "7stud" <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi,
>
> > Thanks for the response.
>
> > On Apr 11, 12:49 am, "Gabriel Genellina" <[
On Apr 11, 8:03 pm, "7stud" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks for the response.
>
> On Apr 11, 12:49 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > __file__ corresponds to the filename used to locate and loa
Hi,
Thanks for the response.
On Apr 11, 12:49 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
>
> __file__ corresponds to the filename used to locate and load the module,
> whatever it is. When the module is found on the current directory
> (corresponding to &
En Tue, 10 Apr 2007 21:20:51 -0300, 7stud <[EMAIL PROTECTED]>
escribió:
> I'm having trouble understanding what the definition of __file__ is.
> With this program:
>
> --
> #data.py:
>
> def show():
> print __file__
>
> if __name__ == "
Hi,
I'm having trouble understanding what the definition of __file__ is.
With this program:
--
#data.py:
def show():
print __file__
if __name__ == "__main__":
show()
---
if I run data.py with the prompt pointing to the directory that
contains data.py, then __fi
Le dimanche 13 août 2006 14:18, John Machin a écrit :
> I don't usually go for one-liners, especially ugly ones like
> "inspect.stack()[1][1:3]" but it avoids the risk of hanging on to a
> reference to the frame object -- see the warning in the inspect docs.
Yes, my mistake, thanks for pointing th
Maric Michaud <[EMAIL PROTECTED]> writes:
> Sure, try :
>
> In [46]: import inspect
>
> In [47]: c=inspect.currentframe()
>
> In [48]: c.f_lineno
> Out[48]: 1
>
> In [49]: c.f_code.co_filename
> Out[49]: ''
Thanks a lot - that was just what I wanted.
Regards - Joakim
--
Joakim Hove
hove AT
ion is called. If this were C I would
> have used the __FILE__ and __LINE__ macros as:
>
> log_msg(msg , __FILE__ , __LINE__)
>
> Is there a way to emulate this behaviour in Python?
>
It's better in Python not to emulate that but to let the caller do the
work:
C:\junk&
t; the source file where the function is called. If this were C I would
> have used the __FILE__ and __LINE__ macros as:
>
> log_msg(msg , __FILE__ , __LINE__)
>
> Is there a way to emulate this behaviour in Python?
Sure, try :
In [46]: import inspect
In [47]: c=inspect.cu
Hello,
i have simple[1] function like this:
def log_msg(msg , file , line):
print "%s:%s %s" % (file,line,msg)
the file and line arguments should be the filename and linenumber of
the source file where the function is called. If this were C I would
have used the __
On Thu, 09 Mar 2006 17:25:20 -0500, Jack Diederich wrote:
> It is a built-in module so it doesn't have a .so (dll) or .py file
> to mention.
Wouldn't it make sense for module.__file__ to be set to None rather than
completely missing in this case?
--
Steven.
--
http://mail.py
"mh" wrote:
> So on most modules I import, I can access the .__file__ attribute to
> find the implementation. ie:
> >>> import time
> >>> time.__file__
> '/data1/virtualpython/lib/python2.3/lib-dynload/timemodule.so'
> >>> import s
On Thu, Mar 09, 2006 at 02:04:45PM -0800, mh wrote:
> So on most modules I import, I can access the .__file__ attribute to
> find the implementation. ie:
> >>> import time
> >>> time.__file__
> '/data1/virtualpython/lib/python2.3/lib-dynload/timemodul
So on most modules I import, I can access the .__file__ attribute to
find the implementation. ie:
>>> import time
>>> time.__file__
'/data1/virtualpython/lib/python2.3/lib-dynload/timemodule.so'
>>> import socket
>>> socket.__file__
'/data1/vi
Thank you very much for the prompt reply and the patch - I applied it
and everything is well now.
Looking forward to the update!
--
http://mail.python.org/mailman/listinfo/python-list
[fortepianissimo wrote]
> This is a question to all of you who use Komodo IDE for development:
> when I tried to debug my script which uses __file__ to get the absolute
> path to the file, Komodo complained that the variable is not defined.
>
> Anyway to work around this? (witho
This is a question to all of you who use Komodo IDE for development:
when I tried to debug my script which uses __file__ to get the absolute
path to the file, Komodo complained that the variable is not defined.
Anyway to work around this? (without changing the code)
Or if I need to change the
94 matches
Mail list logo
