Re: How to make a variable's late binding crosses the module boundary?

[Antoon Pardon]

Op 30/08/2022 om 23:52 schreef dn:

The conversation seems to be wandering some way from the OP. Whereas
both of these answers are clever (and I assume work), the question
becomes: why would you want to do this? (especially as it looks ugly and
'smells' a bit convoluted). An example use-case from your experience?


Delving into the list-archive, to get back to the OP: the first message
in the thread quotes another message that's (apparently) not present.

However, in there somewhere is:


from test import *

So, the elephant-in-the-room has always been a very stinky 'code-smell'
- which pretty much every text or web-tutorial will say is a bad idea.


No that is a red herring. If for some reason a variable in a module has
to be (re)set after import time, it doesn't matter whether someone uses

from module import *

or

from module import resetable_variable

in both cases the module that did the import will not notice the change
in the original module.

focussing on the code smell, is leading the attention away from the problem.

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

Re: How to make a variable's late binding crosses the module boundary?

[dn]

On 31/08/2022 19.38, Antoon Pardon wrote:
> 
> 
> Op 30/08/2022 om 23:52 schreef dn:
>> The conversation seems to be wandering some way from the OP. Whereas
>> both of these answers are clever (and I assume work), the question
>> becomes: why would you want to do this? (especially as it looks ugly and
>> 'smells' a bit convoluted). An example use-case from your experience?
>>
>>
>> Delving into the list-archive, to get back to the OP: the first message
>> in the thread quotes another message that's (apparently) not present.
>>
>> However, in there somewhere is:
>>
>>> from test import *
>> So, the elephant-in-the-room has always been a very stinky 'code-smell'
>> - which pretty much every text or web-tutorial will say is a bad idea.
> 
> No that is a red herring. If for some reason a variable in a module has
> to be (re)set after import time, it doesn't matter whether someone uses
> 
>     from module import *
> 
> or
> 
>     from module import resetable_variable
> 
> in both cases the module that did the import will not notice the change
> in the original module.
> 
> focussing on the code smell, is leading the attention away from the
> problem.


Are you the OP?

The behavior has been shown to be exactly that which is (should be)
expected.

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make a variable's late binding crosses the module boundary?

[Antoon Pardon]

Op 31/08/2022 om 09:53 schreef dn:

On 31/08/2022 19.38, Antoon Pardon wrote:


Op 30/08/2022 om 23:52 schreef dn:

The conversation seems to be wandering some way from the OP. Whereas
both of these answers are clever (and I assume work), the question
becomes: why would you want to do this? (especially as it looks ugly and
'smells' a bit convoluted). An example use-case from your experience?


Delving into the list-archive, to get back to the OP: the first message
in the thread quotes another message that's (apparently) not present.

However, in there somewhere is:


from test import *

So, the elephant-in-the-room has always been a very stinky 'code-smell'
- which pretty much every text or web-tutorial will say is a bad idea.

No that is a red herring. If for some reason a variable in a module has
to be (re)set after import time, it doesn't matter whether someone uses

     from module import *

or

     from module import resetable_variable

in both cases the module that did the import will not notice the change
in the original module.

focussing on the code smell, is leading the attention away from the
problem.

Are you the OP?

The behavior has been shown to be exactly that which is (should be)
expected.


That doesn't contradict that the behaviour is a problem. What is expected
(viewed as a language specification) and what is desired (viewed from what
would solve the problem easily) can be at odds.

--
Antoon Pardon.

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

Re: Download Python 3.10.6 for windows

[George Rwaga]

Thanks for the suggestions, Mrab and Eryk.

Because my R and RStudio are under program files, for consistency I
installed Python in C:\program files\Python\Python310. I updated to the
latest version of Spyder in C:\program files\Spyder\Spyder5.3.3. As with R
and RStudio, some Python and Spyder files were automatically installed in
C:\Users\George.Rwaga\AppData\Local. I am not sure why the default for
installing Python
is C:\Users\x.x\AppData\local\programs\Python\Python310.

Initial tests suggest Spyder 5.3.3 is working fine. The real test will
probably come when I try to run some of my old code based on such sources
as Python for Finance by Yves Hilpisch, a book by the same title by Yuxing
Yan, Python for Data Analysis by Wes McKinney, etc.

Again, thanks.

George
--


On Tue, Aug 30, 2022 at 4:06 PM Eryk Sun  wrote:

> On 8/30/22, George Rwaga  wrote:
> >
> > 1. I installed Python 3.10.6 in the default directory
> > C:\Users\x.x\AppData\local\programs\Python\Python310
> > After the installation, there was no shortcut on my desktop.
>
> Shortcuts are created in the start menu. The installer doesn't modify
> the user's desktop or the desktop of all users, which many users don't
> want and would find annoying. Just copy the shortcuts from the start
> menu to the desktop if that's what you want. Right-click the icon in
> the start menu and choose to open the location. You can copy shortcuts
> from the opened Explorer window.
>
> > 2. I then decided to install Python3.10.6 in a customized directory
> > C:\program files\Python\Python310
> > I am being asked to verify access to this directly. I went to properties,
> > made what I thought were the relevant changes. But I keep getting asked
> to
> > verify access.
>
> Installing to "Program Files" requires elevating to get administrator
> access. All users have the right to read and execute files in a
> directory created in "Program Files", but adding, removing, or
> deleting files and directories requires administrator access, as it
> should.
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coffee

[Meredith Montgomery]

"Michael F. Stemper"  writes:

> On 29/08/2022 07.16, Stefan Ram wrote:
>> |Python's obviously a great tool for all kinds of programming things,
>> |and I would say if you're only gonna use one programming
>> |language in your live, Python will probably the right one.
>> Brian Kernighan
>>I transcribed this from the recent video
>>"Coffee with Brian Kernighan".
>
> For those who'd like to see the whole chat:
> 

So kind of you!  Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on GNU EMACS's python-mode, loading entire buffer

[Meredith Montgomery]

Meredith Montgomery  writes:

[...]

> I would also be interested in a command that restarts the REPL afresh
> and reloads my buffer --- sort of like keyboard's [F5] of the IDLE.

A partial solution for this is the following procedure.

--8<---cut here---start->8---
(defun python-revert-and-send-buffer-to-repl ()
  "Revert current buffer and sends it to the Python REPL."
  (interactive)
  (revert-buffer "ignore-auto-no" "no-confirm")
  (python-shell-send-buffer))
--8<---cut here---end--->8---

We can map this to the F5-key and that improves things.  But a restart
of the REPL would be the ideal.  (Sometimes we really want to start
afresh.  Sometimes.  Most often we don't want that.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make a variable's late binding crosses the module boundary?

[Mark Bourne]

Jach Feng wrote:

Mark Bourne 在 2022年8月29日 星期一下午6:40:59 [UTC+8] 的信中寫道：

Jach Feng wrote:

Chris Angelico 在 2022年8月29日 星期一下午1:58:58 [UTC+8] 的信中寫道：

On Mon, 29 Aug 2022 at 15:54, Jach Feng  wrote:


Richard Damon 在 2022年8月29日 星期一上午10:47:08 [UTC+8] 的信中寫道：

On 8/27/22 7:42 AM, Mark Bourne wrote:

Jach Feng wrote:

I have two files: test.py and test2.py
--test.py--
x = 2
def foo():
print(x)
foo()

x = 3
foo()

--test2.py--
from test import *
x = 4
foo()

-
Run test.py under Winows8.1, I get the expected result:
e:\MyDocument>py test.py
2
3

But when run test2.py, the result is not my expected 2,3,4:-(
e:\MyDocument>py test2.py
2
3
3

What to do?


`from test import *` does not link the names in `test2` to those in
`test`. It just binds objects bound to names in `test` to the same
names in `test2`. A bit like doing:

import test
x = test.x
foo = test.foo
del test

Subsequently assigning a different object to `x` in one module does
not affect the object assigned to `x` in the other module. So `x = 4`
in `test2.py` does not affect the object assigned to `x` in `test.py`
- that's still `3`. If you want to do that, you need to import `test`
and assign to `test.x`, for example:

import test
test.x = 4
test.foo()


Yes, fundamental issue is that the statement

from x import y

makes a binding in this module to the object CURRECTLY bound to x.y to
the name y, but if x.y gets rebound, this module does not track the changes.

You can mutate the object x.y and see the changes, but not rebind it.

If you need to see rebindings, you can't use the "from x import y" form,
or at a minimum do it as:


import x

from x import y

then later to get rebindings to x.y do a

y = x.y

to rebind to the current x.y object.

--
Richard Damon

Yes, an extra "import x" will solve my problem too! Sometimes I am wondering why 
"from x import y" hides x? hum...can't figure out the reason:-)


"from x import y" doesn't hide x - it just grabs y. Python does what
you tell it to. :)

ChrisA

But I had heard people say that "from x import y" did import the whole x module into memory, just 
as "import x" did, not "grabs y" only. Is this correct?

`from x import y` does import the whole module x into memory, and adds
it to `sys.modules`. But it only binds the name `y` in the namespace of
module doing the import (and it binds it to the value of `x.y` at the
time the import is done - it doesn't magically keep them in sync if one
or the other is later reassigned).

The point about the whole module being imported is that you don't save
any memory by using `from x import y` to avoid importing some very large
object `z` from `x`. Those other large objects might be needed by
functions which have been imported (e.g. your `foo` function still needs
`x` even if you haven't imported `x` - so it still needs to be loaded
into memory) or might be imported and used by other modules importing
`x`, so they still have to be loaded when any part of `x` is imported -
they just don't have to be bound to names in the importing module's
namespace.

As Richard mentioned, if `x.y` is a mutable object (such as a list) you
can still mutate that object (e.g. add/remove items) and those changes
will be seen in both modules. That's because both are still bound to
the same object and you're mutating that existing object. If you assign
a new list to either, that won't be seen by the other.

--
Mark.

When using dot notation to change variable, no matter if 'x.y' is a mutable or 
immutable object, the change
will be seen in both modules except those early bindings.

--Jach


Yes, sorry, I'd used `x.y` as a way of referring to the variable `y` in 
module `x` as opposed to `y` in the current module.  It doesn't help 
that I added the second paragraph and didn't notice that the third was 
then out of context.


If you use `import x` and assign to `x.y`, that will as you say be seen 
in both modules.  On the other hand, if you use `from x import y`, then 
(as has been discussed) assigning to `y` in the module which has the 
import won't affect the value seen in module `x`.  However, if `y` is 
mutable (e.g. a list), and no new object is assigned to it, then `y` 
still points to the same object in both modules, so mutating that 
existing object (e.g. `y.append(123)`) *will* affect what's seen in both 
modules - they're both referencing the same object, and you've modified 
that object, as opposed to assigning a new object to `y` in one of the 
modules.


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

Re: Download Python 3.10.6 for windows

[Eryk Sun]

On 8/31/22, George Rwaga  wrote:
>
> I am not sure why the default for installing Python is
> C:\Users\x.x\AppData\local\programs\Python\Python310.

The "programs" folder in the above path is the default location to
install programs just for user "x.x." More precisely, the
default location is "%LOCALAPPDATA%\Programs". A user can easily
change this path to a custom location in Explorer, so one shouldn't
rely on the default value in general. Instead, use the shell protocol
path, shell:userprogramfiles. You can use the latter directly in
Explorer, such as the Win+R dialog. From the command line in CMD or
PowerShell, use the `start` command. For example:

>start shell:userprogramfiles

Python's installer defaults to the user program files directory when
installing just for the current user. When the setup is changed to
install for all users, it automatically switches to using
"%ProgramFiles%" or "%ProgramFiles(x86)%" (e.g. "C:\Program Files").
It will try to elevate to get administrator access when installing for
all users.
-- 
https://mail.python.org/mailman/listinfo/python-list