os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
On Wed, Oct 30, 2013 at 12:34 PM, anatoly techtonik <techtonik@gmail.com> wrote:
os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
No, the code is obviously wrong. What's your idea? To make the bit about absolute paths in the documentation all bold, red, and blinking?
On Wed, Oct 30, 2013 at 7:50 PM, Geoffrey Spear <geoffspear@gmail.com> wrote:
On Wed, Oct 30, 2013 at 12:34 PM, anatoly techtonik <techtonik@gmail.com> wrote:
os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
No, the code is obviously wrong. What's your idea? To make the bit about absolute paths in the documentation all bold, red, and blinking?
No. This won't help. The idea is to fill request for a change in behavior for future versions of Python. With rename if necessary. Perhaps even for this - http://www.python.org/dev/peps/pep-0428/ And also the idea is to listen to arguments to protect current behavior. And also what do people think about a library with cross-platform path operations behavior. Meaning that given all set of paths available on internet, this library will normalize operations with those paths, and will provide path handling rules (functions) that work identically on every platform. In cases where it is impossible, the documentation will contain description of the problem. -- anatoly t.
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands: cd /static cat /styles/largestyles,css I agree it might be confusing but it's pretty explicitly documented. On the other hand, this is also documented and it's wrong by the above standard
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
On Windows \def\g is a drive-relative path not an absolute path. To get the right result you need to do:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
This works even on systems that don't use drive letters. It would be nice if there was a less clumsy way to do this. It's worse than that because it also screws up UNC paths
os.path.join(r'\\abc\def\ghi', r'\x\y') '\\x\\y'
The result references a UNC share of \\x\y rather than a directory of x which is also wrong. It would be nice if there was a simpler way to get this right:
os.path.join(r'c:\abc', r'\x\y', keep_drive_unc=True) 'c:\\x\\y' os.path.join(r'\\abc\def\ghi', r'\x\y', keep_drive_unc=True) '\\\\abc\\def\\x\\y'
--- Bruce I'm hiring: http://www.cadencemd.com/info/jobs Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security On Wed, Oct 30, 2013 at 9:34 AM, anatoly techtonik <techtonik@gmail.com>wrote:
os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong? _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
On 30/10/2013 17:06, Bruce Leban wrote:
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands:
cd /static cat /styles/largestyles,css
I agree it might be confusing but it's pretty explicitly documented. On the other hand, this is also documented and it's wrong by the above standard
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
On Windows \def\g is a drive-relative path not an absolute path. To get the right result you need to do:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
This works even on systems that don't use drive letters. It would be nice if there was a less clumsy way to do this. It's worse than that because it also screws up UNC paths
os.path.join(r'\\abc\def\ghi', r'\x\y') '\\x\\y'
The result references a UNC share of \\x\y rather than a directory of x which is also wrong. It would be nice if there was a simpler way to get this right:
os.path.join(r'c:\abc', r'\x\y', keep_drive_unc=True) 'c:\\x\\y' os.path.join(r'\\abc\def\ghi', r'\x\y', keep_drive_unc=True) '\\\\abc\\def\\x\\y'
Shouldn't that be '\\\\abc\\x\\y'?
On Oct 30, 2013 11:25 AM, "MRAB" <python@mrabarnett.plus.com> wrote:
On 30/10/2013 17:06, Bruce Leban wrote:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
After I sent this I realized its more complicated than this. The above code will fail joining (r'C:\a\b', r'D:\x\y').
os.path.join(r'c:\abc', r'\x\y', keep_drive_unc=True) 'c:\\x\\y' os.path.join(r'\\abc\def\ghi', r'\x\y', keep_drive_unc=True) '\\\\abc\\def\\x\\y'
Shouldn't that be '\\\\abc\\x\\y'?
No. A UNC mount point is a server and a share name. \\server on its own isn't enough. E.g., \\server\C$ is the equivalent of C: --- Bruce
Bruce Leban wrote:
It references the same file as these commands:
cd /static cat /styles/largestyles,css
On the other hand, this is also documented and it's wrong by the above standard
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
Actually, it's not -- it gives the same result as the equivalent series of Windows CLI commands. Whether that's a *useful* result is another matter. :-( -- Greg
On Wed, Oct 30, 2013 at 3:10 PM, Greg Ewing <greg.ewing@canterbury.ac.nz>wrote:
On the other hand, this is also documented and it's wrong by the above
standard
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
Actually, it's not -- it gives the same result as the equivalent series of Windows CLI commands. Whether that's a *useful* result is another matter. :-(
I meant cd /D -- which does a true change working directory rather than bare cd which just changes the directory for the drive but doesn't change the working drive. Windows maintains separate working directories for each drive, which frequently surprises users. Perhaps an os.path.joinw or join_windows_paths would be a good idea. --- Bruce I'm hiring: http://www.cadencemd.com/info/jobs Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security
On Wed, Oct 30, 2013 at 8:06 PM, Bruce Leban <bruce@leapyear.org> wrote:
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands:
cd /static cat /styles/largestyles,css
I agree it might be confusing but it's pretty explicitly documented.
Yes. It is confusing. 1. How often the operations to join absolute paths is needed? 2. What is expected result of this operation? For me, as a user, the answer to 1 is 'never', for 2 I'd expect 2nd path to be treated as relative one. Thinking about this as 2nd path is an absolute path from the mountpoint specified in the 1st. -- anatoly t.
On 31 October 2013 10:30, anatoly techtonik <techtonik@gmail.com> wrote:
I agree it might be confusing but it's pretty explicitly documented.
Yes. It is confusing.
1. How often the operations to join absolute paths is needed?
Infrequently, but occasionally. Usually the first argument will be a fixed value which is a "base path" and the second will be a user-supplied (or similar) value which is to be interpreted as relative to the base, unless it's an absolute path when it's to be used unchanged.
2. What is expected result of this operation?
Exactly what Python currently does.
For me, as a user, the answer to 1 is 'never', for 2 I'd expect 2nd path to be treated as relative one. Thinking about this as 2nd path is an absolute path from the mountpoint specified in the 1st.
I would never want this behaviour in any real application I have encountered. Paul
Am 31.10.2013 13:56, schrieb Paul Moore:
On 31 October 2013 10:30, anatoly techtonik <techtonik@gmail.com> wrote:
I agree it might be confusing but it's pretty explicitly documented.
Yes. It is confusing.
1. How often the operations to join absolute paths is needed?
Infrequently, but occasionally. Usually the first argument will be a fixed value which is a "base path" and the second will be a user-supplied (or similar) value which is to be interpreted as relative to the base, unless it's an absolute path when it's to be used unchanged.
Exactly. Absolute paths are different from relative paths, and it should be made clear to everyone quite early that "foo" is different from "/foo". I hope nobody would expect path.join('C:\\xyz', 'D:\\abc') to result in 'C:\\xyz\\D:\\abc' on Windows. Georg
On Oct 31, 2013, at 5:56, Paul Moore <p.f.moore@gmail.com> wrote:
On 31 October 2013 10:30, anatoly techtonik <techtonik@gmail.com> wrote:
I agree it might be confusing but it's pretty explicitly documented.
Yes. It is confusing.
1. How often the operations to join absolute paths is needed?
Infrequently, but occasionally. Usually the first argument will be a fixed value which is a "base path" and the second will be a user-supplied (or similar) value which is to be interpreted as relative to the base, unless it's an absolute path when it's to be used unchanged.
Agreed. Any command line tool that takes an optional base path in an flag arg and paths to files in positional args works that way--or it works by first chdir-ing to the base path then using the paths, which names the same files. It would be very surprising if it didn't. Even the way base URLs and href URLs on web pages are combined is based on this behavior. Languages that don't do it this way are surprising. For example, Ruby's File.join always treats the argument as a relative path. So I had to write my own method that did the equivalent of "p2 if p2.startswith(os.sep) else p1.join(p2)". (Perl of course has at least 5 ways to do it, 2 that act like Python, 1 that acts like Ruby, and 2 that double up the separator with whatever meaning that happens to have on each platform--but that isn't surprising; it's perl.)
2. What is expected result of this operation?
Exactly what Python currently does.
For me, as a user, the answer to 1 is 'never', for 2 I'd expect 2nd path to be treated as relative one. Thinking about this as 2nd path is an absolute path from the mountpoint specified in the 1st.
I would never want this behaviour in any real application I have encountered.
Agreed. I've never seen anyone argue that the other behavior would be more "natural". I _have_ seen an argument that it's more "secure", but this seems like a silly argument. After all, Ruby's File.join doesn't stop you from joining "../../../etc", so why should it stop you from joining "/etc"? And, if there _is_ a good reason to stop you, why does it return a path that's likely to silently work (but not in the way the user intended) rather than raise? And what if you're writing a command line tool intended for system administration rather than a web app? Even with a web app, if you run inside a chroot or similar jail, how do you provide access to the entire jail? It seems like the kind of "security" feature that PHP hacks would devise, like using extra quoting so an attacker has to throw an extra quote in if he wants to inject SQL...
On 10/31/2013 03:30 AM, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 8:06 PM, Bruce Leban <bruce@leapyear.org> wrote:
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands:
cd /static cat /styles/largestyles,css
2. What is expected result of this operation?
for 2 I'd expect 2nd path to be treated as relative one.
If 2 is a relative path, it shouldn't be leading with a slash. -- ~Ethan~
On Thu, Oct 31, 2013 at 6:15 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/31/2013 03:30 AM, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 8:06 PM, Bruce Leban <bruce@leapyear.org> wrote:
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands:
cd /static cat /styles/largestyles,css
2. What is expected result of this operation?
for 2 I'd expect 2nd path to be treated as relative one.
If 2 is a relative path, it shouldn't be leading with a slash.
Right. But I am working more with URL paths nowadays. In there if I want to join two paths, no matter if 2nd starts with slash or not, I don't really expect the 2nd to rewrite the first.
On Mon, Nov 4, 2013 at 7:29 AM, anatoly techtonik <techtonik@gmail.com>wrote:
Right. But I am working more with URL paths nowadays. In there if I want to join two paths, no matter if 2nd starts with slash or not, I don't really expect the 2nd to rewrite the first.
Joining url paths is different from joining file system paths. I wouldn't suggest using a function designed for one to do the other. urljoin('https://s/a/b/', 'x') => 'https://s/a/b/x') urljoin('https://s/a/b/', '/x/y') => 'https://s/x/y') urljoin('https://s/a/b/', '//t/x/y') => 'https://t/x/y') urljoin('https://s/a/b/', '//t') => 'https://t/a/b') urljoin('https://s/a/b/', 'http:') => 'http://s/a/b') urljoin('http:', '//s', 'x/y') => 'http://s/x/y') Note that I'm ignoring the issue of whether or not the last part of the url on the left should be stripped off. --- Bruce I'm hiring: http://www.cadencemd.com/info/jobs Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security
anatoly techtonik <techtonik@gmail.com> writes:
Right. But I am working more with URL paths nowadays. In there if I want to join two paths, no matter if 2nd starts with slash or not, I don't really expect the 2nd to rewrite the first.
Then you're not using the right tool: ‘os.path’ is specifically about filesystem paths. URLs follow different rules, as you say; you should be using ‘urllib.parse’ <URL:http://docs.python.org/3/library/urllib.parse.html>. -- \ “Our task must be to free ourselves from our prison by widening | `\ our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney
anatoly techtonik <techtonik@gmail.com> writes:
Right. But I am working more with URL paths nowadays. In there if I want to join two paths, no matter if 2nd starts with slash or not, I don't really expect the 2nd to rewrite the first.
Then you are using the wrong tool for the job: ‘os.path’ is specifically for manipulating OS filesystem paths. URLs follow different rules, as you say. For those, use the standard library <URL:http://docs.python.org/3/library/urllib.parse.html> ‘urllib.parse’ module. -- \ “When I was born I was so surprised I couldn't talk for a year | `\ and a half.” —Gracie Allen | _o__) | Ben Finney
On Thu, Oct 31, 2013 at 3:30 AM, anatoly techtonik <techtonik@gmail.com> wrote:
On Wed, Oct 30, 2013 at 8:06 PM, Bruce Leban <bruce@leapyear.org> wrote:
I don't know if the code is wrong but if you're asking if the *result* of join is wrong, I don't think it is. It references the same file as these commands:
cd /static cat /styles/largestyles,css
I agree it might be confusing but it's pretty explicitly documented.
Yes. It is confusing.
1. How often the operations to join absolute paths is needed?
Whenever user-provided paths are given relative to another directory, but you'd like them to be allowed to give an absolute path instead, the current behaviour is quite convenient. Otherwise, as you say, it won't come up.
2. What is expected result of this operation?
The expected result is the current behaviour. If it helps, I consider it this way: os.path.join(a, b, c) gives you the directory you'd be in if you cd into a, b, and c in turn. -- Devin
On Wed, Oct 30, 2013, at 13:06, Bruce Leban wrote:
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
On Windows \def\g is a drive-relative path not an absolute path. To get the right result you need to do:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
What should it do in the opposite case: where the path is a relative path on another drive? I.e. os.path.join('c:\\abc','d:efg'). This is archaic, sure, but if we're going to say it's always equivalent to "as if the first argument were the cwd", this needs to be handled too. Fortunately, I don't think there's any way to specify this with a UNC share.
IIRC correctly the form 'd:efg' refers to a relative path on the d: drive, based on the current working directory _of that drive_. Since it requires a default base path to be relative on, that form wouldn't work cross drives. However if we used the same drive, we might be willing to allow a relative path prefixed with a drive letter. os.path.join(r'c:\abc\foo', 'd:efg') # ERROR os.path.join(r'd:\abc\foo', 'd:efg') # returns r'd:\abc\efg' On Sat, Nov 2, 2013 at 9:15 PM, <random832@fastmail.us> wrote:
On Wed, Oct 30, 2013, at 13:06, Bruce Leban wrote:
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
On Windows \def\g is a drive-relative path not an absolute path. To get the right result you need to do:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
What should it do in the opposite case: where the path is a relative path on another drive? I.e. os.path.join('c:\\abc','d:efg'). This is archaic, sure, but if we're going to say it's always equivalent to "as if the first argument were the cwd", this needs to be handled too. Fortunately, I don't think there's any way to specify this with a UNC share. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
On 11/02/2013 08:12 PM, Ryan Hiebert wrote:
IIRC correctly the form 'd:efg' refers to a relative path on the d: drive, based on the current working directory _of that drive_. Since it requires a default base path to be relative on, that form wouldn't work cross drives. However if we used the same drive, we might be willing to allow a relative path prefixed with a drive letter.
os.path.join(r'c:\abc\foo', 'd:efg') # ERROR os.path.join(r'd:\abc\foo', 'd:efg') # returns r'd:\abc\efg'
Surely you meant r'd:\abc\foo\efg'. -- ~Ethan~
On Sat, Nov 2, 2013 at 8:12 PM, Ryan Hiebert <ryan@ryanhiebert.com> wrote:
IIRC correctly the form 'd:efg' refers to a relative path on the d: drive, based on the current working directory _of that drive_.
Correct
Since it requires a default base path to be relative on, that form wouldn't work cross drives.
os.path.join doesn't require a full base path and isn't required to return an absolute path.
However if we used the same drive, we might be willing to allow a relative path prefixed with a drive letter.
os.path.join(r'c:\abc\foo', 'd:efg') # ERROR
This shouldn't be an error. The correct result is 'd:efg', i.e., relative to the current path on the D drive at the time the path is used, just as '\abc' is relative to the current drive at the time the path is used. --- Bruce I'm hiring: http://www.cadencemd.com/info/jobs Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security
On Wed, 30 Oct 2013 10:06:03 -0700 Bruce Leban <bruce@leapyear.org> wrote:
I agree it might be confusing but it's pretty explicitly documented. On the other hand, this is also documented and it's wrong by the above standard
os.path.join(r'c:\abc', r'\def\g') # Windows paths '\\def\\g'
On Windows \def\g is a drive-relative path not an absolute path. To get the right result you need to do:
drive, path = os.path.splitdrive(r'c:\abc') drive + os.path.join(path, r'/def/g') 'c:/def/g'
Note that pathlib gets it right:
PureWindowsPath(r'c:\abc') / r'\def\g' PureWindowsPath('c:/def/g')
PureWindowsPath(r'\\abc\def\ghi') / r'\x\y' PureWindowsPath('//abc/def/x/y')
Regards Antoine.
On 30/10/2013 16:34, anatoly techtonik wrote:
os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...? -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 30/10/2013 16:34, anatoly techtonik wrote:
os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
-- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer
Both Python ML and SO are bad for inventing new languages. -- anatoly t.
On 31/10/2013 10:31, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 30/10/2013 16:34, anatoly techtonik wrote:
>>> os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
-- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer
Both Python ML and SO are bad for inventing new languages. -- anatoly t.
I'm completely baffled by your comment, so please explain yourself. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
On Thu, Oct 31, 2013 at 5:07 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 31/10/2013 10:31, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 30/10/2013 16:34, anatoly techtonik wrote:
>>> os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
-- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer
Both Python ML and SO are bad for inventing new languages. -- anatoly t.
I'm completely baffled by your comment, so please explain yourself.
I mean that if you're going to invent new language or improve existing one, you need a place to keep notes about things that need to be improved, so that you can find them when the time comes. Neither ML nor StackOverflow (SO) are such place.
On 04/11/2013 15:25, anatoly techtonik wrote:
On Thu, Oct 31, 2013 at 5:07 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 31/10/2013 10:31, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 30/10/2013 16:34, anatoly techtonik wrote:
>>> os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
-- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer
Both Python ML and SO are bad for inventing new languages. -- anatoly t.
I'm completely baffled by your comment, so please explain yourself.
I mean that if you're going to invent new language or improve existing one, you need a place to keep notes about things that need to be improved, so that you can find them when the time comes. Neither ML nor StackOverflow (SO) are such place.
What on earth has this got to do with your original question, a trivial thing about os.path.join? I'd say this is definitely not the place to be asking this particular question, in fact I'd say anywhere but here. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
On Mon, Nov 4, 2013 at 6:37 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 04/11/2013 15:25, anatoly techtonik wrote:
On Thu, Oct 31, 2013 at 5:07 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 31/10/2013 10:31, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 30/10/2013 16:34, anatoly techtonik wrote:
>>> os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css'
Is it only me who thinks that the code above is wrong?
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
-- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer
Both Python ML and SO are bad for inventing new languages. -- anatoly t.
I'm completely baffled by your comment, so please explain yourself.
I mean that if you're going to invent new language or improve existing one, you need a place to keep notes about things that need to be improved, so that you can find them when the time comes. Neither ML nor StackOverflow (SO) are such place.
What on earth has this got to do with your original question, a trivial thing about os.path.join? I'd say this is definitely not the place to be asking this particular question, in fact I'd say anywhere but here.
The question was: 1. if this specific behavior for joining paths is still actual 2. if there are other people who don't expect it to work in this way I find Ruby approach more useful, and it's quite valuable info that the call can not be directly converted between stdlibs.
On 10/31/2013 03:31 AM, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
Both Python ML and SO are bad for inventing new languages.
If you're inventing a new language, why are you wasting time on a Python venue? -- ~Ethan~
On Thu, Oct 31, 2013 at 6:16 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/31/2013 03:31 AM, anatoly techtonik wrote:
On Wed, Oct 30, 2013 at 10:41 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Is this the appropriate place for such a question? What is wrong with the main Python mailing list, Stackoverflow...?
Both Python ML and SO are bad for inventing new languages.
If you're inventing a new language, why are you wasting time on a Python venue?
NIH + stand on the shoulders of giants.
participants (16)
-
anatoly techtonik -
Andrew Barnert -
Antoine Pitrou -
Ben Finney -
Bruce Leban -
Devin Jeanpierre -
Ethan Furman -
Geoffrey Spear -
Georg Brandl -
Greg Ewing -
Janzert -
Mark Lawrence -
MRAB -
Paul Moore -
random832＠fastmail.us -
Ryan Hiebert