On Mon, Apr 11, 2022 at 12:22 PM Chris Angelico wrote:
> > 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
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
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
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,
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
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
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
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.
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
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
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,
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
> 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
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
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
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
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
> 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:
On Sun, Apr 10, 2022 at 7:25 PM Chris Angelico wrote:
> > 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.
>
I
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
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
On Mon, 11 Apr 2022 at 09:45, Ethan Furman wrote:
>
> On 4/10/22 14:09, Chris Angelico wrote:
> > On Mon, 11 Apr 2022 at 06:48, Ethan Furman wrote:
> >>
> >> On 4/10/22 10:17, Chris Angelico wrote:
> >>> On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
> >>
> But if I did that, then
On 4/10/22 14:09, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 06:48, Ethan Furman wrote:
On 4/10/22 10:17, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
But if I did that, then one lib registering my units with the global repository
might break some other
On Mon, 11 Apr 2022 at 06:48, Ethan Furman wrote:
>
> On 4/10/22 10:17, Chris Angelico wrote:
> > On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
>
> >> But if I did that, then one lib registering my units with the global
> >> repository might break some other lib's use of the global
On Sun, Apr 10, 2022 at 2:37 AM Chris Angelico wrote:
> 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,
Oh my god, no! I guess we do
On 4/10/22 10:17, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
But if I did that, then one lib registering my units with the global repository
might break some other lib's use of the global repository.
Then... libraries should not register units unless it's
I'll summarize by quoting only a small part, since most of the line of
argument is the same, with different examples.
On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
> Again, the behavior of some code should be clear and obvious to the person
> writing the code. If I write code such as:
Not sure this conversation actually relates to any proposals at this point,
but ...
On Fri, Apr 8, 2022 at 9:54 AM Chris Angelico wrote:
> You're misunderstanding the difference between "application" and
> "library" here.
No, I'm not -- your misunderstanding my (poorly made, I guess) point.
On Sun, 10 Apr 2022 at 18:44, Ronald Oussoren via Python-ideas
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,
> 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
On Mon, Apr 04, 2022 at 02:47:48PM -, Brian McCall wrote:
> Asked and answered!
>
> > * There are an unlimited number of derived (non-SI) and compound units
> > that people will want to use.
>
> Unlimited? You sure that problem can't be bounded?
Every problem can be bounded by the
On Sat, 9 Apr 2022 at 02:31, Christopher Barker wrote:
>
> On Fri, Apr 8, 2022 at 8:29 AM Chris Angelico wrote:
>>
>> > > another that's using nautical miles, but *not both in the same
>> > > module*?
>
>
> Absolutely!
>
> There is talk about "the Application" as though that's one thing, but
On Fri, Apr 8, 2022 at 8:29 AM Chris Angelico wrote:
> > > another that's using nautical miles, but *not both in the same
> > > module*?
Absolutely!
There is talk about "the Application" as though that's one thing, but
Python applications these days can be quite large collections of third
On Sat, 9 Apr 2022 at 00:34, 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
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
On 5/04/22 4:17 pm, Chris Angelico wrote:
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,
If there's a single global registry, and they both register the
unit under the same name, then there
Brian McCall writes:
> In terms of the internal representation of units, the
> representation that is use for machine calculations, there are only
> 7 units that need to be supported.
According to you. I would like dollars and shares to be supported as
well as perhaps "kg of apples" (vs "kg
On 2022-04-05 12:17 a.m., Chris Angelico wrote:
On Tue, 5 Apr 2022 at 13:00, Steven D'Aprano wrote:
Sure, we can demand that every application that needs to deal with US
survey miles and imperial miles and international miles give them all
distinct names. That's one solution, but not the
On Tue, 5 Apr 2022 at 13:00, Steven D'Aprano wrote:
>
> On Tue, Apr 05, 2022 at 04:02:24AM +1000, Chris Angelico wrote:
>
> > Is it really that much of a problem? Tell me: How often do you REALLY
> > expect to have collisions within an application, but in different
> > modules? YAGNI.
>
> You
On Tue, Apr 05, 2022 at 04:02:24AM +1000, Chris Angelico wrote:
> Is it really that much of a problem? Tell me: How often do you REALLY
> expect to have collisions within an application, but in different
> modules? YAGNI.
You have no idea how many different definitions there are for "mile", do
On Tue, 5 Apr 2022 at 00:48, Brian McCall
wrote:
>
> Asked and answered!
>
> > * There are an unlimited number of derived (non-SI) and compound units
> > that people will want to use.
>
> Unlimited? You sure that problem can't be bounded? There are few things I can
> think of that could bound
Asked and answered!
> * There are an unlimited number of derived (non-SI) and compound units
> that people will want to use.
Unlimited? You sure that problem can't be bounded? There are few things I can
think of that could bound this problem in a performance-friendly manner.
In terms of the
Asked and answered! Although, see below*, the additional representations of
these numbers does not mean that "int", "bool", and "float" have no place in
the core language.
*Here is a URL to a GIF of the good people of Letterkenny saying "to be fair":
On Mon, Apr 04, 2022 at 08:27:45AM -, Brian McCall wrote:
> Why don't we allow different libraries to use different, incompatible
> implementations of integers, floating points, and bool?
We do. numpy supports 32-bit and 64-bit ints and possibly others, gmpy
supports mpz integers. I don't
On Mon, 4 Apr 2022 at 18:28, Brian McCall
wrote:
>
> Why don't we allow different libraries to use different, incompatible
> implementations of integers, floating points, and bool? Standard units are
> just as immutable as any of these data types.
>
Those three data types are unambiguous, but
Why don't we allow different libraries to use different, incompatible
implementations of integers, floating points, and bool? Standard units are just
as immutable as any of these data types.
___
Python-ideas mailing list -- python-ideas@python.org
To
On 4/04/22 10:20 am, Chris Angelico wrote:
import sys
sys.register_numeric_suffix("m", lambda n: unit(n, "meter"))
sys.register_numeric_suffix("mol", lambda n: unit(n, "mole"))
A global registry seems like a really bad idea. What if two
libraries want to use different, incompatible
Looks like this segue moved on to a new thread, but I'm glad I'm not the only
one who thinks this way!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On Mon, 4 Apr 2022 at 04:53, Brian McCall
wrote:
> If you had asked me twenty years ago if I thought units should be a native
> part of any programming language, I would have said absolutely - because in
> my youthful ignorance I had no idea what it would take to make such a thing
> work. Five
HEAR HEAR!
BUT- SI units isn't enough. Engineers in the US and Canada (I have many
colleagues in Canada and when I ask they always say: we pretend to use SI
but we don't) have all kinds of units.
Give us native, customizable units, or give us death! Who's with me??!!
...
I'm kidding to a
*SOAP BOX WARNING*
It's not often that I would say that C++ is easier to read or more WYSIWYG than
Python, but in this case, C++ is clearly well ahead of Python. I have spent a
fair amount of my own time, and I have seen so many others' time wasted because
command line or input fields do not
On 2022-04-02 22:28, Steven D'Aprano wrote:
On Sun, Apr 03, 2022 at 01:09:00PM +0900, Stephen J. Turnbull wrote:
>There was a proposal to provide literal syntax for physical units like
>meters, kilograms, and seconds, along the the SI magnitude prefixes.
>I think that got to the "proto-PEP"
On Sun, Apr 03, 2022 at 01:09:00PM +0900, Stephen J. Turnbull wrote:
> There was a proposal to provide literal syntax for physical units like
> meters, kilograms, and seconds, along the the SI magnitude prefixes.
> I think that got to the "proto-PEP" stage, but it got a lot of weak
> opposition
53 matches
Mail list logo
