Re: Any ideas for a new language inspired to Python?

[2QdxY4RzWzUUiLuE]

On 2020-08-10 at 09:02:57 +1000,
Chris Angelico  wrote:

> If you *really* want to get away from ints-as-objects, what I would
> recommend is emulating it. Some languages pretend that everything's an
> object, but for small integers (say, those less than 2**60), it
> doesn't store the object itself, it just stores the integer (with the
> low bit set, for example). It requires special-casing integers
> *everywhere* in the language executor (interpreter/compiler), and in
> return, you get to save about 20 bytes per integer compared to the way
> CPython does it. Is that worth it?

As always, it depends.

The special casing to which Chris referred is no worse than the special
casing that has to happen for every arithmetic operation anyway.  How
does Python calculate a * b?  Well, it depends on the type of a and the
type of b, and then dispatching to a special case multiplication
routine.  All that boxing and unboxing (pulling the actual values out of
the objects, creating new objects, memory management, etc.) can add up,
too.

If my application deals with arithmetic on millions or billions¹ of
small integers (say, those less than 2**60), then it can make a big
difference.  ;-)

¹ whether a billion is 1e9 or 1e12
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE: New Feature?

[Terry Reedy]

On 8/9/2020 7:39 PM, Steve wrote:

Where would the conversation have to happen to get the forces-that-be to
install a pull-down/history menu for the Find option in IDLE?  To have to
retype the search option over and over when I am toggling between two or
more searches gets tiresome.  I would rather spend my brain cells and
bandwidth thinking about coding.

The IDLE-dev mail list
https://mail.python.org/mailman/listinfo/idle-dev
may or may not be active at any time.

Simplest specification:
one list for all 3 search boxes;
start fresh each session

If search boxes were non-modal, it might work to have two open for same 
editor (not sure).



Footnote:
There's 99 bugs in the code, in the code.
99 bugs in the code.
Take one down and patch it all around.
Now there's 117 bugs in the code.


Argh!  I sometimes find a bug fixing a bug, but more often think of 
multiple possible improvement when implementing one.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE: New Feature?

[Chris Angelico]

On Mon, Aug 10, 2020 at 9:40 AM Steve  wrote:
>
> Where would the conversation have to happen to get the forces-that-be to
> install a pull-down/history menu for the Find option in IDLE?  To have to
> retype the search option over and over when I am toggling between two or
> more searches gets tiresome.  I would rather spend my brain cells and
> bandwidth thinking about coding.
>

You could raise that on python-ideas, but if you want to put some
effort into making it really really easy for Terry, you could try
implementing it - or at least the beginnings of it - as a pull
request. Idle is written in Python, so you can tinker with it without
writing any C code.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

IDLE: New Feature?

[Steve]

Where would the conversation have to happen to get the forces-that-be to
install a pull-down/history menu for the Find option in IDLE?  To have to
retype the search option over and over when I am toggling between two or
more searches gets tiresome.  I would rather spend my brain cells and
bandwidth thinking about coding.

Steve


Footnote:
There's 99 bugs in the code, in the code.
99 bugs in the code.
Take one down and patch it all around.
Now there's 117 bugs in the code.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Including a Variable In the HTML Tags When Sending An Email

[Richard Damon]

On 8/9/20 6:22 PM, sammy.jackson...@gmail.com wrote:
> On Sunday, August 9, 2020 at 1:32:30 AM UTC+1, Richard Damon wrote:
>> On 8/8/20 8:03 PM, sammy.jackson...@gmail.com wrote:
>>> If i use place holders i.e. {0} and {1} where {0} is the name and {1} is 
>>> the dataframe i get an error for the following line of code:-
>>> .format((Name,Body).to_html()) which states 'tuple' object has no attribute 
>>> 'to_html'.
>> I would do it as
>>
>> .format(Name, Body.to_html()) if your names really are just straight
>> letters.
>>
>> If they might have some funny characters that need html handling, you
>> could do:
>>
>> import html
>>
>>
>> .format(html.escape(Name), Body.to_html())
>>
>>
>> Note that different types need to be treated differently to get them
>> into clean html.
>>
>>
>> -- 
>> Richard Damon
>
> Richard I love you.
>
> The following change you recommended worked. 
>
>
Now spend a bit of time understanding why that works, how it is
different from what you did, and what you can learn from it so you can
do other things than just follow a rote recipe.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[Chris Angelico]

On Mon, Aug 10, 2020 at 2:46 AM Marco Sulla
 wrote:
> This is another big problem: everything is an object?
> It seems that in practice, using integers and floats as objects leads
> to great slowdowns. And personally I never saw people that created
> superclasses of int or float. Anyway, if they feel the urgence, they
> can use `numbers` ABCs. It seems to me that the Java separation
> between primitive types vs objects is quite practical.

That isn't a problem. It is, in fact, extremely practical. EVERY
Python object has a repr, EVERY Python object has a type, etc, etc,
etc. You can ask questions like "is this object an instance of
(float,int)" and get back a useful answer.

If you *really* want to get away from ints-as-objects, what I would
recommend is emulating it. Some languages pretend that everything's an
object, but for small integers (say, those less than 2**60), it
doesn't store the object itself, it just stores the integer (with the
low bit set, for example). It requires special-casing integers
*everywhere* in the language executor (interpreter/compiler), and in
return, you get to save about 20 bytes per integer compared to the way
CPython does it. Is that worth it?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Including a Variable In the HTML Tags When Sending An Email

[sammy . jackson987]

On Sunday, August 9, 2020 at 1:32:30 AM UTC+1, Richard Damon wrote:
> On 8/8/20 8:03 PM, sammy.jackson...@gmail.com wrote:
> > If i use place holders i.e. {0} and {1} where {0} is the name and {1} is 
> > the dataframe i get an error for the following line of code:-
> > .format((Name,Body).to_html()) which states 'tuple' object has no attribute 
> > 'to_html'.
> 
> I would do it as
> 
> .format(Name, Body.to_html()) if your names really are just straight
> letters.
> 
> If they might have some funny characters that need html handling, you
> could do:
> 
> import html
> 
> 
> .format(html.escape(Name), Body.to_html())
> 
> 
> Note that different types need to be treated differently to get them
> into clean html.
> 
> 
> -- 
> Richard Damon


Richard I love you.

The following change you recommended worked. 


-- 
https://mail.python.org/mailman/listinfo/python-list

Python 3 Feature Request: `pathlib` Use Trailing Slash Flag

[Adam Hendry]

`pathlib` trims trailing slashes by default, but certain packages require 
trailing slashes. In particular, `cx_Freeze.bdist_msi` option "directories" is 
used to build the package directory structure of a program and requires 
trailing slashes.

Does anyone think it would be a good idea to add a flag or argument to 
`pathlib.Path` to keep trailing slashes? For instance, I envision something 
like:

```
from pathlib import Path

my_path = Path(r"foo/bar/", keep_trailing_slash=True)
```

The argument could be made `False` by default to maintain backwards 
compatibility. The only way I know to keep the backslash and maintain 
cross-compatibility is as follows:

```
import os
from pathlib import Path

my_path = f"{Path(r"foo/bar").resolve()}{os.sep}"
```

although this returns a string and the `Path` object is lost.

Any thoughts?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[2QdxY4RzWzUUiLuE]

On 2020-08-09 at 13:07:03 -0400,
Dennis Lee Bieber  wrote:

> On Sun, 9 Aug 2020 09:31:04 +0100, Barry Scott 
> declaimed the following:
> 
> >
> >By going to C you are really saying you want to use the native instructions 
> >of your CPU.
> >Contrast that with bytecode that needs an interpreter.
> >
> 
>   Unless one has located a C-compiler that generates byte-code for some
> virtual machine.

gcc compiles source code into different levels of virtual machines, and
then those virtual machines into actual object code.  Start at
https://gcc.gnu.org/onlinedocs/gccint/index.html, and drill down into
section 6.3.8 (Anatomy of a Language Front End) and chapter 9 (Passes
and Files of the Compiler).  Nothing stops you from translating your
source code directly into, say, RTL.

The Wikipedia page for LLVM tells me it's designed for this sort of
thing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[Grant Edwards]

On 2020-08-09, Marco Sulla  wrote:
> On Sun, 9 Aug 2020 at 10:31, Barry Scott  wrote:

>> By going to C you are really saying you want to use the native
>> instructions of your CPU.  Contrast that with bytecode that needs
>> an interpreter.
>
> This is also an answer for Grant Edwards: the idea was to generate
> bytecode and compile it to machine code.

Right.  I was just pointing out that you said you wanted to do "static
compilation", and then provided an small example that demonstrated
something unrelated[1] (static typing).  If you want to design a
language that has static typing, that's fine.  If you want to
implement that language using static compilation, that's fine.  You
can have both if you want.  But, they are two independent concepts,
and you're going to confuse people if you use them interchangeably.

[1] Though in theory they are orthogonal, in practice certain
combinations of static compilation vs. bytecode+VM and static
vs. dynamic typing are harder to implement than others.

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[Terry Reedy]

On 8/9/2020 12:44 PM, Marco Sulla wrote:


Do you think py devs will be greatly bored if I link this discussion
in the python-dev mailing list?


Don't.  This is neither about language development (and proposals 
initially go to python-ideas) nor about immediate cpython development



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Module import question

[Bob Gailer]

On Aug 9, 2020 11:41 AM, "Mats Wichmann"  wrote:
>
> On 8/9/20 12:51 AM, Gabor Urban wrote:
> > Hi guys,
> >
> > I have a quite simple question but I could not find the correct answer.
> >
> > I have twoo modules A and B. A imports B. If I import A in a script,
Will
> > be B imported automatically? I guess not, but fő not know exactly.
> >
> > Thanks for your answer ín advance,
>
> Think of import as meaning "make available in namespace".

Well it's actually a little more involved than that. When python import a
module it executes the module code. This is why you often see at the bottom
of a module:

if __name__ == '__main__':
  # code to execute when running the module as opposed to importing it.

When importing a module __name__ is the module's name rather than
'__main__'.

What happens when module A Imports module B depends on whether or not the
import B statement is actually executed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Module import question

[Gabor Urban]

Hi guys,

Thanks for the answers. IT is clear Noé.

Gábor
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: importlib: import X as Y; from A import B

[Dieter Maurer]

Jason Friedman wrote at 2020-8-8 21:23 -0600:
> ...
>The cherry-on-top would be to import with the "aliasing" and "from" they
>will most likely see on the web, so that my code matches what they see
>there. In other words, instead of:
>
>import pandas
>df = pandas.from_csv (...)
>import selenium
>browser = selenium.webdriver.Firefox()
>
>on the web they will typically see:
>
>import pandas as pd

import pandas; pd = pandas

>df = pd.from_csv (...)
>from selenium import webdriver

import selenium.webdriver; webdriver = selenium.webdriver
>
>I don't see anything in the importlib module documentation that supports
>this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[Marco Sulla]

On Sun, 9 Aug 2020 at 10:31, Barry Scott  wrote:
> By going to C you are really saying you want to use the native instructions 
> of your CPU.
> Contrast that with bytecode that needs an interpreter.

This is also an answer for Grant Edwards: the idea was to generate
bytecode and compile it to machine code. See gcj, for example, that
translates the Java bytecode into machine code.
Even if it's not needed by the "mainstream" implementation, it could
be good if someone wants to implement its own interpreter.

Currently I don't care if this will slow down the compilation: things
can be accelerated or removed. My doubt is if the initial work is too
much and if I can, eventually, add this extra step later without many
troubles.

On Sun, 9 Aug 2020 at 10:31, Barry Scott  wrote:
> Have a look at http://www.nuitka.net/ that compiles python into C.
> It can also spot optimisations that help, for example noticing that
> code is doing int math and write that as C avoiding the python objects.

This is another big problem: everything is an object?
It seems that in practice, using integers and floats as objects leads
to great slowdowns. And personally I never saw people that created
superclasses of int or float. Anyway, if they feel the urgence, they
can use `numbers` ABCs. It seems to me that the Java separation
between primitive types vs objects is quite practical.

On Sun, 9 Aug 2020 at 10:31, Barry Scott  wrote:
> You need a compiler person to explain better than I can.
> But the steps that you need are:
> 1. Parse the source into an intermediate form (AST for example)
> 2. Check that the code is valid
> 3. Compile into runnable code

I know this is not trivial... I read also about lexers and parsers.
For example, it seems that Guido now uses a new parser, a PEG parser.
Don't know if it uses a lexer or not and why. And it seems they exist
generators of lexers and parsers. The more simple to use seems to be
ANTLR: https://github.com/antlr/antlr4 but it does not generate a PEG
parser.

Do you think py devs will be greatly bored if I link this discussion
in the python-dev mailing list?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 3.8.5 Failing To Install With pythonz

[MRAB]

On 2020-08-09 16:15, Tim Daneliuk wrote:

I have a weird problem I could use a bit of help with ...

I have successfully installed 3.8.5 using pew/pythonz on a BSD FreeBSD system.
But when I attempt to install it on a Linux system I get the traceback below.
In this case, pew/pythonz were installed locally in my own account using system
native python 3.6:

Installing CPython-3.8.5 into /home/tundra/.pythonz/pythons/CPython-3.8.5
Traceback (most recent call last):
   File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 204, in install
 self.make()
   File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 350, in make
 s.check_call(make)
   File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
294, in check_call
 returncode = self.call(cmd)
   File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
286, in call
 fp.write(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2018' in position 
81: ordinal not in range(128)
ERROR: Failed to install CPython-3.8.5. Check 
/home/tundra/.pythonz/log/build.log to see why.
Traceback (most recent call last):
   File "/home/tundra/.local/bin/pew", line 11, in 
 sys.exit(pew())
   File "/home/tundra/.local/lib/python3.6/site-packages/pew/pew.py", line 809, 
in pew
 return command(sys.argv[2:])
   File "/home/tundra/.local/lib/python3.6/site-packages/pew/pew.py", line 704, 
in install_cmd
 return actual_installer.install()
   File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 204, in install
 self.make()
   File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 350, in make
 s.check_call(make)
   File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
294, in check_call
 returncode = self.call(cmd)
   File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
286, in call
 fp.write(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2018' in position 
81: ordinal not in range(128)


Ideas anyone?


FTR, '\u2018' is the codepoint 'LEFT SINGLE QUOTATION MARK'.

Try reporting it on the project's homepage. It looks like there have 
been similar problems before, but not this one.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Module import question

[Mats Wichmann]

On 8/9/20 12:51 AM, Gabor Urban wrote:
> Hi guys,
> 
> I have a quite simple question but I could not find the correct answer.
> 
> I have twoo modules A and B. A imports B. If I import A in a script, Will
> be B imported automatically? I guess not, but fő not know exactly.
> 
> Thanks for your answer ín advance,

Think of import as meaning "make available in namespace".

If A simply imports B, then B is available in A's namespace as a name
for module B's namespace, and you can access things inside B by
qualifying the names: if Foo is in B, then B.Foo works, Foo does not.
Different forms of the import statement change the way symbols are made
available, e.g you can do

from B import *# all the symbols from B are in A's global namespace,
Foo works now
import B as Baz# B is available through the name Baz, so use Baz.Foo
etc.

If you have a separate program, call it C, and it imports A, then A is
available in C as a name for module A's namespace.  That said nothing
about B, so the symbol B is not available in C.  But if C calls
something in A that uses B, then that will work fine, because B exists
in A's namespace. And you can access symbols from B by properly
qualifying: A.B.Foo.

Which is it you meant by "imported automatically"?

See Byung-Hee's example to see this in action without all these messy
words :)
-- 
https://mail.python.org/mailman/listinfo/python-list

3.8.5 Failing To Install With pythonz

[Tim Daneliuk]

I have a weird problem I could use a bit of help with ...

I have successfully installed 3.8.5 using pew/pythonz on a BSD FreeBSD system.
But when I attempt to install it on a Linux system I get the traceback below.
In this case, pew/pythonz were installed locally in my own account using system
native python 3.6:

Installing CPython-3.8.5 into /home/tundra/.pythonz/pythons/CPython-3.8.5
Traceback (most recent call last):
  File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 204, in install
self.make()
  File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 350, in make
s.check_call(make)
  File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
294, in check_call
returncode = self.call(cmd)
  File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
286, in call
fp.write(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2018' in position 
81: ordinal not in range(128)
ERROR: Failed to install CPython-3.8.5. Check 
/home/tundra/.pythonz/log/build.log to see why.
Traceback (most recent call last):
  File "/home/tundra/.local/bin/pew", line 11, in 
sys.exit(pew())
  File "/home/tundra/.local/lib/python3.6/site-packages/pew/pew.py", line 809, 
in pew
return command(sys.argv[2:])
  File "/home/tundra/.local/lib/python3.6/site-packages/pew/pew.py", line 704, 
in install_cmd
return actual_installer.install()
  File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 204, in install
self.make()
  File 
"/home/tundra/.local/lib/python3.6/site-packages/pythonz/installer/pythoninstaller.py",
 line 350, in make
s.check_call(make)
  File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
294, in check_call
returncode = self.call(cmd)
  File "/home/tundra/.local/lib/python3.6/site-packages/pythonz/util.py", line 
286, in call
fp.write(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2018' in position 
81: ordinal not in range(128)


Ideas anyone?
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] PyInstaller 4.0

[Hartmut Goebel]

Hello,

on behalf of the PyInstaller development team I'm happy to announce
PyInstaller 4.0.

   http://www.pyinstaller.org

Thanks for all those who contributed questions, bug-reports or
pull-requests.


PyInstaller is in urgent need of funding to make future security fixes
happen, see  for
details.


=== Important Changes ===

Release 4.0 adds support for 3rd-party packages to provide PyInstaller hooks
along with the package. This allows Maintainers of other Python packages to
deliver up-to-date PyInstaller hooks as part of their package.
See our sample project  for more 
information.

PyInstaller uses this option itself to provide updated hooks much faster:
Many hooks are moved into the new package pyinstaller-hooks-contrib 
,
which is updated monthly.
This package is installed automatically when installing PyInstaller,
but can also be updated independently.

Finally, this version drops support for Python 2.7,
which is end-of-life since January 2020..
The minimum required version is now Python 3.5.
The last version supporting Python 2.7 was PyInstaller 3.6.

The full changelog for this release can be found at:
https://pyinstaller.readthedocs.io/en/v4.0/CHANGES.html


=== What it is ===

PyInstaller bundles a Python application and all its dependencies into a
single package. The user can run the packaged app without installing a
Python interpreter or any modules.

PyInstaller reads a Python script written by you. It analyzes your code to
discover every other module and library your script needs in order to
execute.
Then it collects copies of all those files – including the active Python
interpreter! – and puts them with your script in a single folder, or
optionally in a single executable file.

PyInstaller is tested against Windows, Mac OS X, and Linux. However, it
is not a cross-compiler: to make a Windows app you run PyInstaller in
Windows; to make a Linux app you run it in Linux, etc. PyInstaller has
been used successfully with AIX, Solaris, and FreeBSD, but is not tested
against them.


=== Help keeping PyInstaller alive ===

Maintaining PyInstaller is a huge amount of work.
PyInstaller development can only continue
if users and companies provide sustainable funding.
Please consider recurring donations.
See http://www.pyinstaller.org/funding.html for how
to support PyInstaller.


=== Installation ===

PyInstaller can be installed from PyPi using

   pip install pyinstaller

=== Important Changes ===



The full changelog for this release can be found at:

   https://pyinstaller.readthedocs.io/en/v4.0/CHANGES.html


=== Feedback ===

We're eager to listen to your feedback on using PyInstaller:

 Bug tracker: https://github.com/pyinstaller/pyinstaller/issues
 Mailing list: http://groups.google.com/group/PyInstaller

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/warum-sie-nicht-perl-programmiern-sollten
Kolumne: http://www.cissp-gefluester.de/2012-02-bring-your-own-life-glosse

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any ideas for a new language inspired to Python?

[Barry Scott]

> On 8 Aug 2020, at 18:18, Marco Sulla  wrote:
> 
> On Sat, 8 Aug 2020 at 14:10, Barry  wrote:
 On 7 Aug 2020, at 23:28, Marco Sulla  wrote:
>>> My idea seems to be very simple (so probably it's not simple at all):
>>> a language similar to Python, but statically compiled.
>> 
>> Have a look at Apple’s Swift. It reminds me of python as I read it.
> 
> Thank you, some features are interesting, even if I prefer the Python syntax.
> 
> What about the compiler? Is it better to "compile" to C or to
> bytecode?

By going to C you are really saying you want to use the native instructions of 
your CPU.
Contrast that with bytecode that needs an interpreter.

> How can I generate a bytecode that can be compileed by gcc?

Have a look at http://www.nuitka.net/  that compiles 
python into C.
One part of its speed up is that the bytecode evel code is not needed.
It can also spot optimisations that help, for example noticing that
code is doing int math and write that as C avoiding the python objects.

> Can I skip the AST generation for now, or it will be a great problem
> later?

You need a compiler person to explain better than I can.
But the steps that you need are:
1. Parse the source into an intermediate form (AST for example)
2. Check that the code is valid
3. Compile into runnable code

Barry
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Module import question

[황병희]

Gabor Urban  writes:

> Hi guys,
>
> I have a quite simple question but I could not find the correct answer.
>
> I have twoo modules A and B. A imports B. If I import A in a script, Will
> be B imported automatically? I guess not, but fő not know exactly.
>
> Thanks for your answer ín advance,

#+BEGIN_SRC: sh + python
(bionic)soyeomul@localhost:~/222$ cat b.py
name = "b"
(bionic)soyeomul@localhost:~/222$ cat a.py
import b

name = "a"
(bionic)soyeomul@localhost:~/222$ cat c.py
import a

print(a.name) # a.py's name
print(a.b.name) # b.py's name
(bionic)soyeomul@localhost:~/222$ python3 c.py
a
b
(bionic)soyeomul@localhost:~/222$ 
#+END_SRC

Sincerely, Byung-Hee

-- 
^고맙습니다 _白衣從軍_ 감사합니다_^))//
-- 
https://mail.python.org/mailman/listinfo/python-list