[Python-ideas] Re: Custom literals, a la C++

[Eryk Sun]

On 4/11/22, Chris Angelico  wrote:
>
> Which raises the question: what if the current directory no longer has
> a path name? Or is that simply not possible on Windows?

The process working directory is opened without FILE_SHARE_DELETE
sharing. This prevents opening the directory with DELETE access from
any security context in user mode, even by the SYSTEM account.

If the handle for the working directory is forcefully closed (e.g. via
Process Explorer) and the directory is deleted, then accessing a
relative path in the affected process fails with ERROR_INVALID_HANDLE
(6) until the working directory is changed to a valid directory.

> (Don't even get me started on prefixing paths with \\?\ and what that
> changes. Windows has bizarre backward compatibility constraints.)

Paths prefixed by \\?\ or \\.\ are not supported for the process
working directory and should not be used in this case. The Windows API
is buggy if the working directory is set to a prefixed path. For
example, it fails to identify a drive such as r"\\?\C:" or
r"\\?\UNC\server\share" in the working directory, in which case a
rooted path such as r"\spam" can't be accessed.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5A4RYPI6T7FHGRP7KOEL2ISQHHNUPLCJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Ethan Furman]

On 4/11/22 11:06, Chris Angelico wrote:


Steven is, as are a few who have agreed that namespaces are the One
True Way™ to do things.


That seems a grossly unfair characterization of those who don't agree with you.

I think everyone should take a break from this thread -- it is apparent that no one is convincing any one else, so the 
final decision will be by the SC (assuming a PEP is ever made).


--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EVAFFRPJ4VG2G7X323QDNY263IL6AGJ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[MRAB]

On 2022-04-11 20:01, Chris Angelico wrote:
[snip]


Which raises the question: what if the current directory no longer has
a path name? Or is that simply not possible on Windows? I know that on
Linux, I can unlink a directory while being in it (which creates
interesting problems for bash, git, and other tools, but not
fundamental ones for the process model itself), and many references
WILL be resolved correctly. Or I can move the directory to another
parent, and "pwd" says the original name (because that's a shell
feature), but "ls .." will list the contents of the new directory.


Windows won't let you delete a directory that's currently being used.

[snip]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/N4K77HCYDXYOKAA5N7UGY5PCC77J7I34/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Chris Angelico]

On Tue, 12 Apr 2022 at 05:14, Christopher Barker  wrote:
>
> On Mon, Apr 11, 2022 at 11:10 AM Chris Angelico  wrote:
>>
>> > I don’t know about anyone else, but I’m not arguing for module scope. I’m 
>> > arguing against implicit global configuration.
>> >
>>
>> Steven is, as are a few who have agreed that namespaces are the One
>> True Way™ to do things.
>
>
> I'm agreeing with namespaces as well -- which I think is different than the 
> idea of module scope for impict contexts
>
> Then we are using names, and can use all the rules form managing the cope of 
> teh names:
>
> To use the example of one proposed unit syntax:
>
> distance = 500[miles]
>
> "miles" would need to be a valid name accessible to that scope -- the writer 
> of that code can choose exactly what that name is, likely by some sort of 
> import:
>
> from my_unit_system import miles
>
> as oped what I understand was being proposed via a "global registry", which 
> is that code:
>
> distance = 500[miles]
>
> would work even if there were no name "miles" in that namespace(s) -- and it 
> would, instead go look for it in the global registry -- which could have been 
> manipulated by the application to mean nautical miles, or statute miles, or 
> whatever.
>
> And THAT I think is a bad idea.

It's a good thing we don't have a mutable builtins module, then. Oh right. :)

> What I'm not suggesting, because I think it wouldn't be that helpful, and 
> maybe not possible would be to have something like:
>
> set_units_registry_to(my_units system)
>
> and then have:
>
> distance = 500[miles]
>
> use my_units_system's definition of miles in that module without having 
> explicitly imported the name.
>

The trouble is, you now force everyone to do bulk imports - almost
certainly star imports. How are you going to populate the namespace
appropriately if not with a star import? What happens if you don't
want the entire contents of the module?

Having a registry means you can get finer granularity with
registration functions, without a massively complex module and
submodule system, or heaps of manual imports.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SF5FWCEZN3Y7I5AYLVMJWKU5E7TERFON/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Christopher Barker]

On Mon, Apr 11, 2022 at 11:10 AM Chris Angelico  wrote:

> > I don’t know about anyone else, but I’m not arguing for module scope.
> I’m arguing against implicit global configuration.
> >
>
> Steven is, as are a few who have agreed that namespaces are the One
> True Way™ to do things.
>

I'm agreeing with namespaces as well -- which I think is different than the
idea of module scope for impict contexts

Then we are using names, and can use all the rules form managing the cope
of teh names:

To use the example of one proposed unit syntax:

distance = 500[miles]

"miles" would need to be a valid name accessible to that scope -- the
writer of that code can choose exactly what that name is, likely by some
sort of import:

from my_unit_system import miles

as oped what I understand was being proposed via a "global registry", which
is that code:

distance = 500[miles]

would work even if there were no name "miles" in that namespace(s) -- and
it would, instead go look for it in the global registry -- which could have
been manipulated by the application to mean nautical miles, or statute
miles, or whatever.

And THAT I think is a bad idea.

What I'm not suggesting, because I think it wouldn't be that helpful, and
maybe not possible would be to have something like:

set_units_registry_to(my_units system)

and then have:

distance = 500[miles]

use my_units_system's definition of miles in that module without having
explicitly imported the name.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q3A2YT4WZTWFXVYKZDLL3MFZDKXQXWF5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Chris Angelico]

On Tue, 12 Apr 2022 at 04:46, Eryk Sun  wrote:
>
> On 4/11/22, Chris Angelico  wrote:
> >
> > If you say `open("/spam")`, Windows uses "default drive" + "explicit
> > directory".
>
> You can think of a default drive as being the drive of the current
> working directory, but there is no "default drive" per se that's
> stored separate from the working directory.

Ah, fair. I described it that way because I thought that it was
equivalent, but I stand corrected.

> Python and most other filesystem libraries generalize a UNC
> "\\server\share" path as a 'drive', in addition to drive-letter drives
> such as "Z:". However, the working directory is only remembered
> separately from the process working directory in the case of
> drive-letter drives, not UNC shares.
>
> If the working directory is r"\\server\share\foo\bar", then r"\spam"
> resolves to r"\\server\share\spam".
>
> If the working directory is r"\\server\share\foo\bar", then "spam"
> resolves to r"\\server\share\foo\bar\spam". However, the system will
> actually access this path relative to an open handle for the working
> directory.

Which raises the question: what if the current directory no longer has
a path name? Or is that simply not possible on Windows? I know that on
Linux, I can unlink a directory while being in it (which creates
interesting problems for bash, git, and other tools, but not
fundamental ones for the process model itself), and many references
WILL be resolved correctly. Or I can move the directory to another
parent, and "pwd" says the original name (because that's a shell
feature), but "ls .." will list the contents of the new directory.

> A handle for the process working directory is always kept open and
> thus protected from being renamed or deleted. Per-drive working
> directories are not kept open. They're just stored as path names in
> reserved environment variables.
>
> > Hence there are 26 current directories (one per drive), plus the
> > selection of current drive, which effectively chooses your current
> > directory.
>
> If the process working directory is a DOS drive path, then 26 working
> directories are possible. If the process working directory is a UNC
> path, then 27 working directories are possible.

Yup yup. This is what I get for oversimplifying and forgetting that
UNC names are paths/drives too.

(Don't even get me started on prefixing paths with \\?\ and what that
changes. Windows has bizarre backward compatibility constraints.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3P677SA7ENGBKIK2YFIPYLERYT6KLRXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Eryk Sun]

On 4/11/22, Chris Angelico  wrote:
>
> If you say `open("/spam")`, Windows uses "default drive" + "explicit
> directory".

You can think of a default drive as being the drive of the current
working directory, but there is no "default drive" per se that's
stored separate from the working directory.

Python and most other filesystem libraries generalize a UNC
"\\server\share" path as a 'drive', in addition to drive-letter drives
such as "Z:". However, the working directory is only remembered
separately from the process working directory in the case of
drive-letter drives, not UNC shares.

If the working directory is r"\\server\share\foo\bar", then r"\spam"
resolves to r"\\server\share\spam".

If the working directory is r"\\server\share\foo\bar", then "spam"
resolves to r"\\server\share\foo\bar\spam". However, the system will
actually access this path relative to an open handle for the working
directory.

A handle for the process working directory is always kept open and
thus protected from being renamed or deleted. Per-drive working
directories are not kept open. They're just stored as path names in
reserved environment variables.

> Hence there are 26 current directories (one per drive), plus the
> selection of current drive, which effectively chooses your current
> directory.

If the process working directory is a DOS drive path, then 26 working
directories are possible. If the process working directory is a UNC
path, then 27 working directories are possible.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OR65GYLNYOV4LT3ZEM3YFIVHSOP3D664/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Chris Angelico]

On Tue, 12 Apr 2022 at 02:51, Christopher Barker  wrote:
>
>
>> The context manager changes the entire process's WD for a section of
>> code. This makes sense, although it has its own consequences.
>
>
> Actually, now that you say that— I think it makes my point: the fact that 
> this context manager is necessary, and “has consequences” is because the 
> working dir is global — not a good choice.
>
>> The module-scope hammer does not fit every nail. Stop trying to hammer
>> in screws.
>
>
> I don’t know about anyone else, but I’m not arguing for module scope. I’m 
> arguing against implicit global configuration.
>

Steven is, as are a few who have agreed that namespaces are the One
True Way™ to do things.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SMZI4L2CWBYHV3JMPX2PXTLCXKHRMPCR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Chris Angelico]

On Tue, 12 Apr 2022 at 03:49, Steven D'Aprano  wrote:
> > Windows has up to 27 working directories per process. There's the
> > overall working directory directory, plus one for each drive.
>
> Today I learned something new, thank you.
>
> How does that work in practice? In Windows, if you just say the
> equivalent to `open('spam')`, how does the OS know which drive
> and WD to use?

It uses the "default drive" + "current directory on that drive".

If you say `open("c:spam")`, Windows uses "drive C" + "current
directory on drive C".

If you say `open("/spam")`, Windows uses "default drive" + "explicit directory".

Hence there are 26 current directories (one per drive), plus the
selection of current drive, which effectively chooses your current
directory.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KTQZRVCDC47HEFP26LP3WH6IS3Z2X5TK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Eryk Sun]

On 4/11/22, Steven D'Aprano  wrote:
>
> How does that work in practice? In Windows, if you just say the
> equivalent to `open('spam')`, how does the OS know which drive
> and WD to use?

"spam" is resolved against the process working directory, which could
be a UNC path instead of a drive. OTOH, "Z:spam" is relative to the
working directory on drive "Z:". If the latter is r"Z:\foo\bar", then
"Z:spam" resolves to r"Z:\foo\bar\spam".

The working directory on a drive gets set via os.chdir() when the
process working directory is set to a path on the drive. It's
implemented via reserved environment variables with names that begin
with "=", such as "=Z:" set to r"Z:\foo\bar". Python's os.environ
doesn't support getting or setting these variables, but WinAPI
GetEnvironmentVariableW() and SetEnvironmentVariableW() do.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ULS4MZZNF6MIUEGGRF5GIJ2PSJJOUGYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Steven D'Aprano]

On Mon, Apr 11, 2022 at 11:53:18AM -0500, Eryk Sun wrote:
> On 4/11/22, Steven D'Aprano  wrote:
> >
> > You know how every OS process has its own working directory? Just like
> > that, except every module.
> 
> A per-thread working directory makes more sense to me.

Hmmm, yes, that does seem sensible.


> But it would be
> a lot of work to implement support for this in the os and io modules,
> for very little gain.

Sure.


> > "One WD per process" is baked so deep into file I/O on Posix
> > systems (and I presume Windows) that its probably impossible to
> > implement in current systems.
> 
> Windows has up to 27 working directories per process. There's the
> overall working directory directory, plus one for each drive.

Today I learned something new, thank you.

How does that work in practice? In Windows, if you just say the 
equivalent to `open('spam')`, how does the OS know which drive 
and WD to use?


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2A7YYS72ILRJKQTR3UU44HDTC4UYPA23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Christopher Barker]

> The context manager changes the entire process's WD for a section of
> code. This makes sense, although it has its own consequences.


Actually, now that you say that— I think it makes my point: the fact that
this context manager is necessary, and “has consequences” is because the
working dir is global — not a good choice.

The module-scope hammer does not fit every nail. Stop trying to hammer
> in screws.


I don’t know about anyone else, but I’m not arguing for module scope. I’m
arguing against implicit global configuration.

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FOPBF3DMN72JDJE2MMJI6WZT7KSV2JWM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Eryk Sun]

On 4/11/22, Steven D'Aprano  wrote:
>
> You know how every OS process has its own working directory? Just like
> that, except every module.

A per-thread working directory makes more sense to me. But it would be
a lot of work to implement support for this in the os and io modules,
for very little gain.

> "One WD per process" is baked so deep into file I/O on Posix
> systems (and I presume Windows) that its probably impossible to
> implement in current systems.

Windows has up to 27 working directories per process. There's the
overall working directory directory, plus one for each drive.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IJFHA3HTOHEANOXD34KSK7TYDHZYULWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Steven D'Aprano]

On Mon, Apr 11, 2022 at 07:32:12AM -0700, Ethan Furman wrote:

> My apologies for not understanding your example.  The counter example I had 
> in my head, and should have written down, was something like:
> 
>   15mpg * 7l == how many miles?
> 
> where
> 
>   mpg = miles per gallons
> l = litres
> 
> I'm pretty sure the answer there is not 105.

Indeed. The answer is 27.7 miles.

[steve ~]$ units "15mpg * 7l" miles
* 27.738065
/ 0.036051541


Or if you prefer an exact answer, Frink gives 62500/22532213 miles. 
Because one can never have too much precision *wink*

(By the way, those are US gallons and miles. If we use British units 
instead, the answer is 27.738114 miles. A difference of about 7.9cm in 
either direction. If you care.)


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZMAOV4SYJNVQE4HGXP3IPEDDBY3ZNGAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[André Roberge]

On Mon, Apr 11, 2022 at 11:33 AM Ethan Furman  wrote:

> On 4/10/22 21:33, Stephen J. Turnbull wrote:
>
> > I guess you could call the associative law of multiplication "dumb
> > luck", but most mathematicians will consider that hate speech.
>
> My apologies for not understanding your example.  The counter example I
> had in my head, and should have written down,
> was something like:
>
>15mpg * 7l == how many miles?
>
> where
>
>mpg = miles per gallons
>  l = litres
>
> I'm pretty sure the answer there is not 105.
>

Really? ;-) ;-)

>>> import pint
>>> ureg = pint.UnitRegistry()
>>> mpg = ureg.define('mpg = 1 * mile / gallon')
>>> dist = 15 * ureg.mpg * 7 * ureg.l
>>> dist


It is 105 ... but in some weird distance units.

>>> dist.to(ureg.miles)


Or, in a more readable way! ;-) ;-)

> python -m ideas -t easy_units
Ideas Console version 0.0.30. [Python version: 3.9.10]

>>> import pint
>>> ureg = pint.UnitRegistry()
>>> ureg.define('mpg = 1 * mile / gallon')
>>> dist = 15[mpg] * 7[l]
>>> dist.to(1[mile])


André Roberge

Thought: I should probably make it even easier to convert units within
ideas...


>
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OGHZSHZZEVHP4MLWXZSH45DGZYO7WDC6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FAVWNYTFQITTSUM6F667BDZXLEXFUP7Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ethan Furman]

On 4/10/22 21:33, Stephen J. Turnbull wrote:


I guess you could call the associative law of multiplication "dumb
luck", but most mathematicians will consider that hate speech.


My apologies for not understanding your example.  The counter example I had in my head, and should have written down, 
was something like:


  15mpg * 7l == how many miles?

where

  mpg = miles per gallons
l = litres

I'm pretty sure the answer there is not 105.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OGHZSHZZEVHP4MLWXZSH45DGZYO7WDC6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Joao S. O. Bueno]

On Mon, Apr 11, 2022 at 3:39 AM Chris Angelico  wrote:


On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull
>  wrote:
> > [1]  They don't have to be big problems or proprietary code; computing
> > Fibonacci sequences will do, if you can find a way to make MI relevant
> > to that task.
> >
>
>
> We shall now hold a funeral for the brain cells lost by everyone who
> just read that code.
>

Fortunately, I was still through my Monday morning cup of coffee -
it took most of the damage.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FMDT6JFLBN5SHOC6DLMUMAMG4AXCTXRQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Chris Angelico]

On Mon, 11 Apr 2022 at 19:30, Steven D'Aprano  wrote:
>
> On Mon, Apr 11, 2022 at 12:21:41PM +1000, Chris Angelico wrote:
> > On Mon, 11 Apr 2022 at 10:41, Steven D'Aprano  wrote:
> > >
> > > On Sat, Apr 09, 2022 at 02:52:50AM +1000, Chris Angelico wrote:
> > >
> > > > We aren't bothered by the fact that os.chdir()
> > > > is global, we just accept that it belongs to the application, not a
> > > > library.
> > >
> > > You might not be, but those of us who use it, or *would* use it if it
> > > wasn't so dangerous, think differently.
> >
> > Would you? What would the behaviour of os.chdir be if it had module
> > scope? Please explain, I am very curious.
>
> You know how every OS process has its own working directory? Just like
> that, except every module.

That's a really lovely theory. The problem is, it doesn't work that
way. Every process is spawned in the working directory of its parent
(modulo deliberate changes), and thereafter is completely independent.
If one process sends a signal to another process, they have
independent working directories. That doesn't make sense with modules,
since they constantly call back and forth to each other. Imagine:

import subprocess
import os
os.change_local_dir(...)

What's the working directory of the subprocess module? Is it
independent of the calling module? If so, what's the point of even
HAVING a per-module working directory, since no Python code can ever
directly open a file - it always calls a function in another module?

> Its probably too hard to implement in Python, at least for the benefit.
> (Lots of effort, only a small benefit, nett negative worth.)

Massive negative worth.

> This is not a PEP proposing per-module WDs, not even a serious proposal
> for it. "One WD per process" is baked so deep into file I/O on Posix
> systems (and I presume Windows) that its probably impossible to
> implement in current systems.

The context manager changes the entire process's WD for a section of
code. This makes sense, although it has its own consequences.
Per-module *simply does not work*, nor does it make any sense.

The module-scope hammer does not fit every nail. Stop trying to hammer
in screws.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RCKX7DYJXURZPHLAHLZ6SDOS23MVPZGL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Steven D'Aprano]

On Mon, Apr 11, 2022 at 12:21:41PM +1000, Chris Angelico wrote:
> On Mon, 11 Apr 2022 at 10:41, Steven D'Aprano  wrote:
> >
> > On Sat, Apr 09, 2022 at 02:52:50AM +1000, Chris Angelico wrote:
> >
> > > We aren't bothered by the fact that os.chdir()
> > > is global, we just accept that it belongs to the application, not a
> > > library.
> >
> > You might not be, but those of us who use it, or *would* use it if it
> > wasn't so dangerous, think differently.
> 
> Would you? What would the behaviour of os.chdir be if it had module
> scope? Please explain, I am very curious.

You know how every OS process has its own working directory? Just like 
that, except every module.

Its probably too hard to implement in Python, at least for the benefit. 
(Lots of effort, only a small benefit, nett negative worth.) 
Especially since we would probably want the WD to use dynamic scoping, 
not lexical scoping.

This is not a PEP proposing per-module WDs, not even a serious proposal 
for it. "One WD per process" is baked so deep into file I/O on Posix 
systems (and I presume Windows) that its probably impossible to 
implement in current systems.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M4MOTLBRAKUPQPJPSASZGE4B2FKYSFOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Steven D'Aprano]

On Sun, Apr 10, 2022 at 10:16:04PM -0700, Christopher Barker wrote:

> I have seen code that caches the workingdir, change it, then puts it back
> -- but that's very much not thread
> safe, and I'd only recommend it maybe in tests.

If you google for it, there are about a million recipes and blog posts 
etc for changing the current working directory in a context manager, and 
starting with 3.11 it will be available in the stdlib:

https://docs.python.org/3.11/library/contextlib.html#contextlib.chdir

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YDSDQD62JLTTDNDM5D4HRSG6WUGWRI36/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Steven D'Aprano]

On Sun, Apr 10, 2022 at 11:50:40AM -0700, Brendan Barnwell wrote:

>   You seem to be envisioning a system in which multiple inheritance 
>   gives a subclass a "menu" of behaviors from which it may explicitly 
> choose, 
> but does not actually combine the superclasses' behaviors into a single, 
> definite behavior of the subclass.  In that scheme, order of multiple 
> inheritance would not matter, because the superclasses don't need to be 
> "integrated" into the subclass; they just sit there waiting for the 
> subclass to explicitly decide which superclass it wants to delegate to.

Thanks Brendan, that has helped me understand where malmiteria is coming 
from. I think that your comments explains a lot of his ideas about MI.


>   Maybe that's how MI works in some other languages, but not Python. 
> Everything about a class --- super, MRO, everything --- is impacted by 
> its ENTIRE superclass hierarchy, including the order in which classes 
> are inherited.  When a subclass inherits from multiple superclasses, the 
> superclass behaviors are *combined* into a *single* set of behaviors for 
> the subclass.  They're not "held separate" somehow as alternative 
> inheritance hierarchies; they are joined into one.

+1

 
>   Likewise, the order in which a class inherits multiple superclasses 
> matters in Python.  That's just how Python works, and there's no way 
> that's going to change.  I don't want to sound harsh, but if `class A(B, 
> C)` doesn't "feel" different to you from `class(C, B)` then I think you 
> need to adjust your feelings rather than expect Python to adjust its 
> behavior.

And +1 to that too.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q7PLWUGJLWVDEFOGX6AMEBSKK3AGACRT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Ronald Oussoren via Python-ideas]

> On 10 Apr 2022, at 11:20, Chris Angelico  wrote:
> 
> On Sun, 10 Apr 2022 at 18:44, Ronald Oussoren via Python-ideas
> mailto:python-ideas@python.org>> wrote:
>> 
>> 
>> 
>> On 8 Apr 2022, at 16:33, Steven D'Aprano  wrote:
>> 
>> On Tue, Apr 05, 2022 at 02:17:00PM +1000, Chris Angelico wrote:
>> 
>> Do you ever have one module that's using statute miles and
>> another that's using nautical miles, but *not both in the same
>> module*? The only reason to have them namespaced to modules is to
>> allow different modules to use them independently. If your application
>> needs to use both statute and nautical miles in the same module (most
>> likely the main module), then it's going to have an issue, and your
>> proposal adds a ton of complexity (that's a real unit, by the way, I
>> totally didn't make it up) for no benefit whatsoever.
>> 
>> 
>> That's not the real problem.
>> 
>> The real problem is that my program may:
>> 
>> * import ham, which registers mile as 1609.3412 m
>> * import spam, which registers mile as 1609.344 m
>> * import cheese, which registers mile as 1609.3472 m
>> * import aardvark, which registers mile as 1609.3426 m
>> * import hovercraft, which registers mile as 1853.181 m
>> 
>> 
>> I’ve only scanned this thread and may have missed an explanation for this, 
>> but why must there be a global registry?
>> 
>> Explicit imports, possibly with a new dunder protocol for literal convertors 
>> feels like a better fit to the language to me. This also avoids the problem 
>> with a global registry you mention earlier.
>> 
> 
> That's precisely what Steven is arguing for, and I'm arguing against.
> Primarily because YAGNI, but also for a more fundamental reason: the
> registry of units is not simply a definition of name -> value, which a
> namespace is capable of (but I think is wrong for this situation), but
> it's also a definition of which units can be converted into which.

The registry is a mapping from names to objects implementing some kind of 
interface, and modules are a good solution for that.

> That would affect how two objects interact with each other - can you
> add meters and miles? Can you treat the electron-volt as a unit of
> mass? All these sorts of questions belong to the application, and
> there's no useful way to divide them on module boundaries, much less
> other scopes.

Why not, that’s what we do for all other types and interfaces?   Compatibility 
and interaction should IMHO be part of the implementation of a set of 
cooperating types, and that’s orthogonal to how you get access to those types.

> 
> There's no point trying to make this scoped, just as we don't have
> lots of other things scoped (like sys.modules). Shared state across
> the application is a *good* thing, not a bad one.

I’m pretty sure singletons are considered to be a code smell in general ;-)

But as I wrote earlier, I don’t have a use case for using this feature myself. 
The closest I get are tuples with the same shape but different interpretation, 
such as various color representations. For those using regular class syntax is 
obviously a better choice than using tuples (e.g. RBG(1,2,3)).  The few times I 
need to deal with units I can either ignore them, or use a normal type (e.g. 
meters(1)).

Ronald

> 
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org 
> 
> To unsubscribe send an email to python-ideas-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/IH2VPKRYBKXLJCVNRZL7PB5WKCWYAK2Z/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SRM72OSDWQWX7RNKZMHUNTIGAP7SWKKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Chris Angelico]

On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull
 wrote:
> [1]  They don't have to be big problems or proprietary code; computing
> Fibonacci sequences will do, if you can find a way to make MI relevant
> to that task.
>

Okay, I'll bite. Unfortunately for the OP, super() works perfectly here.


class Fibo0:
def get(self): return 0

def make_fibo(n):
if n <= 0: return Fibo0
if n <= 2:
class Fibo(Fibo0):
def get(self): return super().get() + 1
return Fibo
class Fibo(make_fibo(n - 1), make_fibo(n - 2)):
pass
return Fibo

for i in range(17):
print(i, make_fibo(i)().get())


We shall now hold a funeral for the brain cells lost by everyone who
just read that code.

ChrisA
PS. If you're surprised by the range(17) there, try range(18) and
you'll see how horrific this code is.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HTMMGRXEZAVLRDPYNSFOMFTNIMZUJ7WG/
Code of Conduct: http://python.org/psf/codeofconduct/