Re: Does os.path relpath produce an incorrect relative path?

On 26/05/2023 16:42, Eryk Sun wrote: On 5/26/23, cactus wrote: Surprisingly (for me at least) the alternative provided by the pathlib module 'relative_to' method doesn't provide for full relative path computation. I was expecting this would offer everything that os.path offers but it doesn't

Does os.path relpath produce an incorrect relative path?

I am wondering whether I have misunderstood the semantics of os.path relpath or whether it has a bug. Here is a short test program: --- from os.path import relpath, split src_path = 'C:\\lib\\src\\' vcx_path =

Re: comprehension parsing

On 05/11/2022 22:11, MRAB wrote: On 2022-11-05 18:52, cactus wrote: On Saturday, 5 November 2022 at 16:06:52 UTC, cactus wrote: I should have quoted the full comprehensions:   all((srt(m, n) in c_np) == (srt(a, b) in c_ap)  for (m, a), (n, b) in combinations(na8, 2))   all( srt(m, n) in c_np 

Re: Global VS Local Subroutines

On 10/02/2022 16:52, Rob Cliffe wrote: On 10/02/2022 12:13, BlindAnagram wrote: Is there any difference in performance between these two program layouts:    def a(): ...    def(b): c = a(b) or    def(b): def a():    ... c = a(b) I would appreciate any insights

Re: Global VS Local Subroutines

On 10/02/2022 15:20, Chris Angelico wrote: On Fri, 11 Feb 2022 at 02:13, BlindAnagram wrote: Is there any difference in performance between these two program layouts: def a(): ... def(b): c = a(b) or def(b): def a(): ... c = a(b) I would

Global VS Local Subroutines

Is there any difference in performance between these two program layouts: def a(): ... def(b): c = a(b) or def(b): def a(): ... c = a(b) I would appreciate any insights on which layout to choose in which circumstances. --

Re: Behaviour of pop() for dictionaries

On 15/06/2021 00:11, dn wrote: On 15/06/2021 09.18, BlindAnagram wrote: On 14/06/2021 20:43, Chris Angelico wrote: On Tue, Jun 15, 2021 at 5:41 AM BlindAnagram ... No it isn't hard to use popitem() but it evidently proved hard for me to remember that it was there. If that's a problem

Re: Behaviour of pop() for dictionaries

On 15/06/2021 01:36, Terry Reedy wrote: On 6/14/2021 5:18 PM, BlindAnagram wrote: I believe that consistency in how methods common to different types work is useful since it adds to the coherence of the language as a whole and avoids the need to remember special cases. Each collection class

Re: Behaviour of pop() for dictionaries

On 14/06/2021 20:43, Chris Angelico wrote: On Tue, Jun 15, 2021 at 5:41 AM BlindAnagram wrote: However, d.pop(key, [default]) returns the value (or the default) and consistency with other pops (a good thing in my view) would suggest that d.pop() could return a random value, which would serve

Re: Behaviour of pop() for dictionaries

On 14/06/2021 08:29, Greg Ewing wrote: On 14/06/21 4:19 am, BlindAnagram wrote: Am I missing the obvious way to obtain the value (or the key) from a dictionary that is known to hold only one item? v = d.popitem()[1] Thanks, Greg, I missed that. More importantly, is there a good reason why

Behaviour of pop() for dictionaries

The pop() method exists for five mainstream data items and shows a range of different behaviours for each of them. But, of the five, pop for dictionaries is the only one for which the first parameter is required and this makes d.pop() for dictionaries an error rather than doing something

Re: Behaviour of os.path.join

On 27/05/2020 23:39, Roel Schroeven wrote: > I find no hints of adding a backslash at the end to indicate directories. > > If you can point me to convincing evidence in the documentation I'll > change my mind. See the post from Eryk Sun, later in this thread. --

Re: Behaviour of os.path.join

On 28/05/2020 14:51, Eryk Sun wrote: > On 5/27/20, Chris Angelico wrote: >> On Thu, May 28, 2020 at 7:07 AM BlindAnagram >> wrote: >>> You can define a path however you want but it won't change the fact that >>> on Windows a path that ends in '\\' is

Re: Behaviour of os.path.join

On 27/05/2020 23:39, Roel Schroeven wrote: > BlindAnagram schreef op 27/05/2020 om 22:55: >> On 27/05/2020 18:42, Roel Schroeven wrote: >>> BlindAnagram schreef op 27/05/2020 om 18:53: >>>> Its not my bug to fix - the semantics of what I send is very cl

Re: Behaviour of os.path.join

On 27/05/2020 18:42, Roel Schroeven wrote: > BlindAnagram schreef op 27/05/2020 om 18:53: >> Its not my bug to fix - the semantics of what I send is very clear on >> any Windows system. > > That's the first time I see any mention of those semantics, and I've > been using W

Re: Behaviour of os.path.join

On 27/05/2020 18:37, Roel Schroeven wrote: > BlindAnagram schreef op 27/05/2020 om 18:39: >> On 27/05/2020 16:49, Rhodri James wrote: >>> On 27/05/2020 16:12, BlindAnagram wrote: >>>> I'm sorry that you don't believe me but all I know is how I intend the >>

Re: Behaviour of os.path.join

On 27/05/2020 16:53, Ben Bacarisse wrote: > BlindAnagram writes: > >> On 27/05/2020 13:30, Ben Bacarisse wrote: >>> BlindAnagram writes: >>> >>>> The issue that I raised here was whether the behaviour of os.path.join() >>>> in treating th

Re: Behaviour of os.path.join

On 27/05/2020 16:49, Rhodri James wrote: > On 27/05/2020 16:12, BlindAnagram wrote: >> I'm sorry that you don't believe me but all I know is how I intend the >> path to be used.  And the os.path functions aren't helpful here when >> they actually_change_  the meaning

Re: Behaviour of os.path.join

On 27/05/2020 14:53, Rhodri James wrote: > On 27/05/2020 14:41, BlindAnagram wrote: >> That is true if you know for sure how your path will be used. >> >> But if you don't, there is a world of difference between passing the >> paths 'name' and 'name\\' on for others to

Re: Behaviour of os.path.join

On 27/05/2020 13:30, Ben Bacarisse wrote: > BlindAnagram writes: > >> The issue that I raised here was whether the behaviour of os.path.join() >> in treating the Windows directory separator '\\' as an absolute path >> should be considered a bug. > > You

Re: Behaviour of os.path.join

On 27/05/2020 09:13, Barry Scott wrote: > > >> On 26 May 2020, at 18:01, BlindAnagram wrote: >> >> On 26/05/2020 17:09, Stefan Ram wrote: >>> Mats Wichmann writes: >>>> an absolute path is one that starts with the pathname separator. >>> &

Re: Behaviour of os.path.join

On 26/05/2020 18:51, Mats Wichmann wrote: > On 5/26/20 10:57 AM, BlindAnagram wrote: >> On 26/05/2020 16:59, Mats Wichmann wrote: >>> On 5/26/20 8:56 AM, BlindAnagram wrote: >>>> I came across an issue that I am wondering whether I should report as an >>&

Re: Behaviour of os.path.join

On 26/05/2020 16:59, Mats Wichmann wrote: > On 5/26/20 8:56 AM, BlindAnagram wrote: >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.pa

Re: Behaviour of os.path.join

On 26/05/2020 17:46, MRAB wrote: > On 2020-05-26 16:48, BlindAnagram wrote: >> On 26/05/2020 16:22, Ben Bacarisse wrote: >>> BlindAnagram writes: >>> >>>> I came across an issue that I am wondering whether I should report >>>> as an >>&

Re: Behaviour of os.path.join

On 26/05/2020 17:09, Stefan Ram wrote: > Mats Wichmann writes: >> an absolute path is one that starts with the pathname separator. > > The Python Library Reference does not use the term > "pathname separator". It uses "directory separator" > (os.sep) and "filename separator" ('/' on Unix).

Re: Behaviour of os.path.join

On 26/05/2020 16:59, Mats Wichmann wrote: > On 5/26/20 8:56 AM, BlindAnagram wrote: >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.pa

Re: Behaviour of os.path.join

On 26/05/2020 16:25, Stefan Ram wrote: > BlindAnagram writes: >> The documentation says that an absolute path in the parameter list for >> join will discard all previous parameters but '\\' is not an absoute path! > > The source code for "join" in "nt

Re: Behaviour of os.path.join

On 26/05/2020 16:22, Ben Bacarisse wrote: > BlindAnagram writes: > >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.path.join() as foll

Behaviour of os.path.join

I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') I obtain as expected from the documentation: 'C:\\Documents\\..\\..\\build\\' But if

Re: encapsulating a global variable (BlindAnagram)

On 25/02/2020 17:16, Christman, Roger Graydon wrote: >> On Tue, 25 Feb 2020 3:06 PM BlindAnagram wrote: > >> My interest in this stems from wanting to keep the dictionary only >> available to the function that uses it and also a worry about being >> called from thread

Re: encapsulating a global variable

On 25/02/2020 16:36, Rhodri James wrote: > On 25/02/2020 15:20, BlindAnagram wrote: >>> class GetIt: >>>    seen = dict() >>> >>>    def __call__(self, piece): >>> return GetIt.seen[piece] >>> >>> get_it = GetIt() >&

Re: encapsulating a global variable

On 25/02/2020 14:14, Rhodri James wrote: > On 25/02/2020 12:38, BlindAnagram wrote: >> I would appreciate advice on whether it is possible to avoid the use of >> a global variable used in a function by encapsulating it in a class >> without maaking any changes to the call inte

Re: encapsulating a global variable

On 25/02/2020 14:13, Chris Angelico wrote: > On Wed, Feb 26, 2020 at 12:11 AM BlindAnagram > wrote: >> >> On 25/02/2020 12:56, Chris Angelico wrote: >>> On Tue, Feb 25, 2020 at 11:41 PM BlindAnagram >>> wrote: >>>> >>>> I would

Re: encapsulating a global variable

On 25/02/2020 14:14, Rhodri James wrote: > On 25/02/2020 12:38, BlindAnagram wrote: >> I would appreciate advice on whether it is possible to avoid the use of >> a global variable used in a function by encapsulating it in a class >> without maaking any changes to the call inte

Re: encapsulating a global variable

On 25/02/2020 12:50, Musbur wrote: > > Am 25.02.2020 13:38 schrieb BlindAnagram: >> and I am wondering if it is possible to use a class something like >> >> class get_it(object): >> >>   seen = dict() >> >>   def __call__(piece): >>   

Re: encapsulating a global variable

On 25/02/2020 12:56, Chris Angelico wrote: > On Tue, Feb 25, 2020 at 11:41 PM BlindAnagram > wrote: >> >> I would appreciate advice on whether it is possible to avoid the use of >> a global variable used in a function by encapsulating it in a class >> without m

encapsulating a global variable

I would appreciate advice on whether it is possible to avoid the use of a global variable used in a function by encapsulating it in a class without maaking any changes to the call interface (which I cannot change). I have: seen = dict() def get_it(piece): ... return

Re: Enumerate - int object not subscriptable

On 20/08/2019 13:00, Sayth Renshaw wrote: > Hi > > I want to do basic math with a list. > > > for idx, num in enumerate(a): > print(idx, num) > > This works, but say I want to print the item value at the next index as well > as the current. > > for idx, num in enumerate(a): >

Re: 03 digression by brute force

On 14/12/2018 02:24, jf...@ms4.hinet.net wrote: > Just for fun:-) On my ooold PC, it takes 0.047 seconds to run the following > algorithm on the problem 'SNED + MORE == MONEY". > > - > import time > import itertools > > #S, E, N, D, M, O, R, Y > n = 0 > digits = {x

Re: Smarter algo, was Re: 03 digression by brute force

On 15/12/2018 09:56, jf...@ms4.hinet.net wrote: > Appreciate your thoughtfully analysis on this code. Before generalize it with > arbitrary additions, as Peter suggested:-), a recursive version is needed. I > may give it a try on this Sunday. > > > Avi Gross at 2018/12/15 UTC+8 AM8:13:37

Re: Python 3.7 Windows Help Behaviour

On 03/07/2018 03:41, Terry Reedy wrote: > On 7/2/2018 8:57 PM, Steven D'Aprano wrote: >> On Fri, 29 Jun 2018 12:53:15 -0400, Terry Reedy wrote: >> >>> On 6/29/2018 6:14 AM, BlindAnagram wrote: >>>> In Python 3.7.0 on Windows the help file (python370.chm) di

Re: Python 3.7 Windows Help Behaviour

On 30/06/2018 10:43, Steven D'Aprano wrote: > On Fri, 29 Jun 2018 12:53:15 -0400, Terry Reedy wrote: > >> On 6/29/2018 6:14 AM, BlindAnagram wrote: >>> In Python 3.7.0 on Windows the help file (python370.chm) displays with >>> a fixed line length and does not adjust

Re: Python 3.7 Windows Help Behaviour

On 29/06/2018 17:53, Terry Reedy wrote: > On 6/29/2018 6:14 AM, BlindAnagram wrote: >> In Python 3.7.0 on Windows the help file (python370.chm) displays with a >> fixed line length and does not adjust its line length when the user >> expands the help window horizont

Python 3.7 Windows Help Behaviour

In Python 3.7.0 on Windows the help file (python370.chm) displays with a fixed line length and does not adjust its line length when the user expands the help window horizontally. This behaviour is different to that of the Python 3.6 help file (python360.chm) which adjusts its text to fit the

Matplotlib and Python 3.7

Now that Python 3.7 has reached release candidate status, I thought that I should try it. But I use Matplotlib a lot and this fails to install with Python 3.7 because "freetype and png cannot be installed" (I am using Windows 10). I am wondering if anyone knows how to work around this issue? I

Re: pathlib PurePosixPath

On 10/10/2017 08:44, Sayth Renshaw wrote: > >>> Hi >>> >>> How do I create a valid file name and directory with pathlib? >>> >>> When I create it using PurePosixPath I end up with an OSError due to an >>> obvously invlaid path being created. >> >> You're on Windows. The rules for POSIX paths

Re: Proposed new syntax

On 10/08/2017 15:28, Steve D'Aprano wrote: > Every few years, the following syntax comes up for discussion, with some > people > saying it isn't obvious what it would do, and others disagreeing and saying > that it is obvious. So I thought I'd do an informal survey. > > What would you expect

Re: Enigma (Tantaliser 482)

On 19/05/2017 10:06, BlindAnagram wrote: > Hi Jim, > > I woke up this morning realising that my published code for this > tantaliser is not very good. > > I would hence be most grateful if you could substitute the attached version. > >best regards, > >

Enigma (Tantaliser 482)

Hi Jim, I woke up this morning realising that my published code for this tantaliser is not very good. I would hence be most grateful if you could substitute the attached version. best regards, Brian from itertools import combinations, permutations, product # enumerate the names A,

Enigma 1140 - link problem

Hi Jim, In my comment/solution for this Enigma I tried to post a link to my number theory library but my HTML got removed. Could you please replace the first sentence with: A solution using my http://173.254.28.24/~brgladma/number_theory.py;>number theory library: (without the line wrapping).

Re: Serious error in int() function?

On 15/04/2016 01:36, Dennis Lee Bieber wrote: > On Thu, 14 Apr 2016 13:07:03 +0100, blindanag...@nowhere.net declaimed the > following: > >> On 14/04/2016 09:13, blindanag...@nowhere.net wrote: >>> On 14/04/2016 08:59, blindanag...@nowhere.net wrote: On 14/04/2016 07:52, ast wrote: >>>

Re: Serious error in int() function?

On 14/04/2016 09:13, blindanag...@nowhere.net wrote: > On 14/04/2016 08:59, blindanag...@nowhere.net wrote: >> On 14/04/2016 07:52, ast wrote: > >> This means that the result will be correct provided it has 53 or less >> bits - just short of 16 decimal digits (i.e for square numbers with less >>

Re: Serious error in int() function?

On 14/04/2016 08:59, blindanag...@nowhere.net wrote: > On 14/04/2016 07:52, ast wrote: > This means that the result will be correct provided it has 53 or less > bits - just short of 16 decimal digits (i.e for square numbers with less > than 32 digits). > > With an integer square root function

Re: Serious error in int() function?

On 14/04/2016 07:52, ast wrote: > > a écrit dans le message de > news:52f7516c-8601-4252-ab16-bc30c59c8...@googlegroups.com... >> Hi, >> >> there may be a serious error in python's int() function: >> >> print int(float(2.8/0.1)) >> >> yields >> >> 27 >> >> instead of

Re: Serious error in int() function?

On 13/04/2016 08:41, martin.spic...@gmail.com wrote: > Hi, > > there may be a serious error in python's int() function: > > print int(float(2.8/0.1)) > > yields > > 27 > > instead of 28!! > > I am using Python Python 2.7.6, GCC 4.8.2 on Linux Ubuntu. > > Is that known? This arises because

Re: Cygwin and Python3

On 10/02/2016 23:05, Mike S wrote: > On 2/10/2016 5:05 AM, Mark Lawrence wrote: [snip] >>> Have you seen this? >>> http://www.davidbaumgold.com/tutorials/set-up-python-windows/ >>> >> >> I have now, but I'm perfectly happy with the free versions of Visual >> Studio. [snip] > I don't see any

Re: GCD in Fractions

On 24/09/2014 12:44, Steven D'Aprano wrote: blindanagram wrote: [snip] - Mathworld says that GCD of two negative numbers is a negative number; - but Mathematica says that GCD of two negative numbers is a positive; - Wikipedia agrees with Mathematica and disagrees with Mathworld; After

Re: GCD in Fractions

On 24/09/2014 17:13, Stefan Behnel wrote: blindanagram schrieb am 24.09.2014 um 15:25: On 24/09/2014 12:44, Steven D'Aprano wrote: [snip] We have an open tracker ticket now on changing *something* about the current situation. Let's just add some new functionality somewhere if people really

Re: GCD in Fractions

On 24/09/2014 17:34, Mark Lawrence wrote: On 24/09/2014 12:14, Mark Dickinson wrote: Mark Lawrence breamoreboy at yahoo.co.uk writes: Somebody got there first http://bugs.python.org/issue22477 I think there's good reason to suspect that Brian Gladman and blindanagram are one and the same

GCD in Fractions

What is the rationale for gcd(x, y) in Fractions returning a negative value when y is negtive? For example gcd(3, -7) returns -1, which means that a co-prime test that would work in many other languages 'if gcd(x, y) == 1' will fail in Python for negative y. And, of course, since -|x| is less

Re: GCD in Fractions

On 23/09/2014 12:53, Wolfgang Maier wrote: On 09/23/2014 10:16 AM, blindanagram wrote: What is the rationale for gcd(x, y) in Fractions returning a negative value when y is negtive? I guess it is implemented this way because its main use is in the Fraction constructor

Re: GCD in Fractions

On 23/09/2014 13:50, Steven D'Aprano wrote: blindanagram wrote: What is the rationale for gcd(x, y) in Fractions returning a negative value when y is negtive? Good question. Normally, gcd is only defined for non-negative integers. Wolfram Mathworld, for example, doesn't mention

Re: GCD in Fractions

On 23/09/2014 18:20, Ian Kelly wrote: On Tue, Sep 23, 2014 at 10:38 AM, Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de wrote: Maybe fractions.gcd could be renamed, but be wrapped or reimplemented correctly somewhere else in the stdlib or even in fractions ? +1 I don't think the

Re: GCD in Fractions

On 23/09/2014 18:26, Stefan Behnel wrote: Wolfgang Maier schrieb am 23.09.2014 um 18:38: While at first I thought this to be a rather irrelevant debate over module private vs public naming conventions, I now think the OP is probably right and renaming fractions.gcd to fractions._gcd may be a

Re: GCD in Fractions

On 23/09/2014 18:55, Stefan Behnel wrote: blindanagram schrieb am 23.09.2014 um 19:43: On 23/09/2014 18:26, Stefan Behnel wrote: Wolfgang Maier schrieb am 23.09.2014 um 18:38: While at first I thought this to be a rather irrelevant debate over module private vs public naming conventions, I

Re: GCD in Fractions

On 23/09/2014 20:30, Mark Lawrence wrote: On 23/09/2014 18:43, blindanagram wrote: On 23/09/2014 18:26, Stefan Behnel wrote: Wolfgang Maier schrieb am 23.09.2014 um 18:38: While at first I thought this to be a rather irrelevant debate over module private vs public naming conventions, I now

Re: Bad comment on Enigmatic Code

On 10/09/2014 07:05, Steven D'Aprano wrote: blindanagram wrote: Hi Jim, When you get a moment, can you please remove the wrongly formatted Python comment I made on your site? Thanks Brian Who is Jim, and what comment are you talking about? Perhaps you have sent this message

Bad comment on Enigmatic Code

Hi Jim, When you get a moment, can you please remove the wrongly formatted Python comment I made on your site? Thanks Brian -- https://mail.python.org/mailman/listinfo/python-list

Re: How keep Python 3 moving forward

On 24/05/2014 08:13, wxjmfa...@gmail.com wrote: Le vendredi 23 mai 2014 22:16:10 UTC+2, Mark Lawrence a écrit : An article by Brett Cannon that I thought might be of interest http://nothingbutsnark.svbtle.com/my-view-on-the-current-state-of-python-3 -- My fellow Pythonistas, ask not

indexing in format strings

With: l = [1,2,3] this: print('{0[0]:d}..{0[2]:d}'.format(l)) gives 1..3 but this: print('{0[0]:d}..{0[-1]:d}'.format(l)) gives: Traceback (most recent call last): File string, line 1, in fragment builtins.TypeError: list indices must be integers, not str which seems to

Re: indexing in format strings

On 11/04/2014 22:33, blindanagram wrote: Thanks, Mark and Terry, for your rapid responses. An interesting thread. Brian -- https://mail.python.org/mailman/listinfo/python-list

Snowed In?

Hi Geoff Are you snowed in? Its OK here. Brian -- http://mail.python.org/mailman/listinfo/python-list