Re: [Python-Dev] When should pathlib stop being provisional?
On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan wrote: > On 6 April 2016 at 15:57, Serhiy Storchaka wrote: >> On 06.04.16 05:44, Nick Coghlan wrote: >>> >>> The most promising option for that is probably "getattr(path, 'path', >>> path)", since the "path" attribute is being added to pathlib, and the >>> given idiom can be readily adopted in Python 2/3 compatible code >>> (since normal strings and any other object without a "path" attribute >>> are passed through unchanged). Alternatively, since it's a protocol, >>> double-underscores on the property name may be appropriate (i.e. >>> "getattr(path, '__path__', path)") >> >> This was already discussed. Current conclusion is using the "path" >> attribute. See http://bugs.python.org/issue22570 . > > I'd missed the existing precedent in DirEntry.path, so simply taking > that and running with it sounds good to me. This makes me twitch slightly, because NumPy has had a whole set of problems due to the ancient and minimally-considered decision to assume a bunch of ad hoc non-namespaced method names fulfilled some protocol -- like all .sum methods will have a signature that's compatible with numpy's, and if an object has a .log method then surely that computes the logarithm (what else in computing could "log" possibly refer to?), etc. This experience may or may not be relevant, I'm not sure -- sometimes these kinds of twitches are good guides to intuition, and sometimes they are just knee-jerk responses to an old and irrelevant problem :-). But you might want to at least think about how common it might be to have existing objects with unrelated attributes that happen to be called "path", and the bizarro problems that might be caused if someone accidentally passes one of them to a function that expects all .path attributes to be instances of this new protocol. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 16:25, Ethan Furman wrote: > On 04/05/2016 10:50 PM, Serhiy Storchaka wrote: >> On 06.04.16 05:44, Nick Coghlan wrote: >>> The next challenge would then be to make a list of APIs to be updated >>> for 3.6 to implicitly accept "rich path" objects via the agreed >>> convention, with pathlib.PurePath used as a test class: >>> >>> * open() >>> * codecs.open() (et al) >>> * io.* >>> * os.path.* >>> * other os functions >>> * shutil.* >>> * tempfile.* >>> * shelve.* >>> * csv.* >> >> >> Not sure about os.path.*. The purpose of os.path module is manipulating >> string paths. From the perspective of pathlib it can look lower level. > > The point is that a function that receives a "path" object (whether str or > Path) shouldn't have to care: it should be able to call os.path.split on the > thing it received and get back a usable answer. I actually think it makes sense to pursue this question in a test driven manner: create "test_pathlib_support" as a new test case, start passing pathlib.PurePath instances to a relatively high level API like shutil, and see what low level interfaces need to be updated accept filesystem path objects (in addition to strings) in order to make that work. If shutil can be updated to support pathlib with changes solely at at the io and os module layer, then that bodes well for transparently enabling support in 3rd party APIs as well. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 04/05/2016 10:00 PM, Guido van Rossum wrote: On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: [...] we can't do: app_root = Path(...) config = app_root/'settings.cfg' with open(config) as blah: # whatever It feels like instead of addressing this basic disconnect, the answer has instead been: add that to pathlib! Which works great -- until a user or a library gets this path object and tries to use something from os on it. I agree that asking for config.open() isn't the right answer here (even if it happens to work). But in this example, once 3.5.2 is out, the solution would be to use open(config.path), and that will also work when passing it to a library. Is it still unacceptable then? On the one hand that is definitely more palatable. On the other hand it doesn't address having the stdlib itself directly support Path. On the gripping hand this feels reminiscent of the arguments over bytes vs unicode, but without any of the "This is why unicode is better!" bits. Why is pathlib better than plain strings? - attribute access to different parts such as the dirname, the filename, the extension (suffix) - easy access to on-disk answers such as .exists(), .stat(), .chdir - easy creation/modification of Path objects What problem is it solving that makes the pain worth dealing with? - no idea This is an especially important point considering the str-derived Path libraries already out there that have the same advantages as pathlib, but none of the pain. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 15:57, Serhiy Storchaka wrote: > On 06.04.16 05:44, Nick Coghlan wrote: >> >> The most promising option for that is probably "getattr(path, 'path', >> path)", since the "path" attribute is being added to pathlib, and the >> given idiom can be readily adopted in Python 2/3 compatible code >> (since normal strings and any other object without a "path" attribute >> are passed through unchanged). Alternatively, since it's a protocol, >> double-underscores on the property name may be appropriate (i.e. >> "getattr(path, '__path__', path)") > > This was already discussed. Current conclusion is using the "path" > attribute. See http://bugs.python.org/issue22570 . I'd missed the existing precedent in DirEntry.path, so simply taking that and running with it sounds good to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 04/05/2016 10:50 PM, Serhiy Storchaka wrote: On 06.04.16 05:44, Nick Coghlan wrote: The next challenge would then be to make a list of APIs to be updated for 3.6 to implicitly accept "rich path" objects via the agreed convention, with pathlib.PurePath used as a test class: * open() * codecs.open() (et al) * io.* * os.path.* * other os functions * shutil.* * tempfile.* * shelve.* * csv.* Not sure about os.path.*. The purpose of os.path module is manipulating string paths. From the perspective of pathlib it can look lower level. The point is that a function that receives a "path" object (whether str or Path) shouldn't have to care: it should be able to call os.path.split on the thing it received and get back a usable answer. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Wed, Apr 6, 2016 at 3:37 PM, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > Outside of deliberate tests, we don't create files on our disks > > whose names are strings of random bytes; > > Wishful thinking. First, names made of control characters have often > been deliberately used by miscreants to conceal their warez. Second, > in some systems it's all too easy to create paths with components in > different locales (the place I've seen it most frequently is in NFS > mounts). I think that's much less true today, but perhaps that's only > because my employer figured out that it was much less pain if system > paths were pure ASCII so that it mostly didn't matter what encoding > users chose for their subtrees. Control characters are still characters, though. You can take a bytestring consisting of byte values less than 32, decode it as UTF-8, and have a series of codepoints to work with. If your employer has "solved" the problem by restricting system paths to ASCII, that's a fine solution for a single system with a single ASCII-compatible encoding; a better solution is to mandate UTF-8 as the file system encoding, as that's what most people are expecting anyway. > It remains important to be able to handle nearly arbitrary bytestrings > in file names as far as I can see. Please note that 100 million > Japanese and 1 billion Chinese by and large still prefer their > homegrown encodings (plural!!) to Unicode, while many systems are now > defaulting filenames to UTF-8. There's plenty of room remaining for > copying bytestrings to arguments of open and friends. Why exactly do they prefer these other encodings? Are they representing characters that Unicode doesn't contain? If so, we have a fundamental problem (no Python program is going to be able to cope with these, without a third party library or some stupid mess of local code); if not, you can always represent it as Unicode and encode it as UTF-8 when it reaches the file system. Re-encoding is something that's easy when you treat something as text, and impossible when you treat it as bytes. So far, you're still actually agreeing with me: paths are *text*, but sometimes we don't know the encoding (and that's a problem to be solved). ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 15:59, Serhiy Storchaka wrote: > On 06.04.16 08:52, Greg Ewing wrote: >> >> Nick Coghlan wrote: >>> >>> The most promising option for that is probably "getattr(path, 'path', >>> path)", >> >> >> Is there something seriously wrong with str(path)? > > What if path is None or bytes? Or an int, float, list, dict, or arbitrary other object. To be more explicit, the problem isn't what happens when the API doing "str(path)" internally is used correctly, it's what happens when it's used incorrectly: you end up proceeding with a nonsense string as your path name, rather than failing early with TypeError or AttributeError. Doing "getattr(path, 'path', path)" instead means that in the error case (i.e. no "path" attribute), any existing argument checking is still triggered normally. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 04/05/2016 10:40 PM, Stephen J. Turnbull wrote: Ethan Furman writes: > No, Stephen, that is not what this is about. Wrong Steven. Spelling matters in email too. Yes, it absolutely does. My apologies. -1 Not good enough. I wouldn't do it that often that "ugly" overrides the reasoning Brett presented [...] But we don't object to (de)serializing dicts to (from) str (as JSON or pickle). Amusingly enough, I don't have to deal with serializing dicts. :) However, as a comparison: imagine you had to transform your dict to JSON every time some function wanted a dict as input. And had to transform returned JSON strings in to dicts. I think Path vs. string is similarly different to justify saying so (especially when treating user input). [...] Thus, strings that look like paths (as strings) actually will have multiple internal representations, similarly to the way that a dict can have multiple serializations. I don't follow. When dealing with the file system one passes a string* representing the path of the object one wants -- pretty much the same string that was passed in to Path. -- ~Ethan~ * or bytes, but the same sameness, really. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 06.04.16 08:52, Greg Ewing wrote: Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", Is there something seriously wrong with str(path)? What if path is None or bytes? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 06.04.16 05:44, Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", since the "path" attribute is being added to pathlib, and the given idiom can be readily adopted in Python 2/3 compatible code (since normal strings and any other object without a "path" attribute are passed through unchanged). Alternatively, since it's a protocol, double-underscores on the property name may be appropriate (i.e. "getattr(path, '__path__', path)") This was already discussed. Current conclusion is using the "path" attribute. See http://bugs.python.org/issue22570 . ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", Is there something seriously wrong with str(path)? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 06.04.16 05:44, Nick Coghlan wrote: The next challenge would then be to make a list of APIs to be updated for 3.6 to implicitly accept "rich path" objects via the agreed convention, with pathlib.PurePath used as a test class: * open() * codecs.open() (et al) * io.* * os.path.* * other os functions * shutil.* * tempfile.* * shelve.* * csv.* Not sure about os.path.*. The purpose of os.path module is manipulating string paths. From the perspective of pathlib it can look lower level. Supporting pathlib.Path will complicate and slow down os.path functions (they are already more complex and slow than were in Python 2). Since os.path functions often called several times in a loop, their performance is important. On other hand, some Path methods are more efficient than os.path functions, and Path specialized code at higher level can be more preferable. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 15:03, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote: >> Option 4: define a rich-object-to-text path serialisation convention, > > Unfortunately that sounds like a classic "serious programming" > solution (objects, abstractions, serialization, all big important > words :-). Yeah, my choice of phrasing made the idea sound more complicated than it is. The actual change would be to add the following to some Python standard library APIs that accept a filesystem path as an argument: arg = getattr(arg, "path", arg) and the C API based equivalent to some C modules. (With the main bike-sheddable part being whether to use the generic "path" or something more explicit like "__fspath__" for the property name, since pathlib can readily support either/both of them, and "__fspath__" would be in line with the "os.fsencode" and "os.fsdecode" abbreviations) The key goal of this approach would be to make it so that most third party libraries would "just work" with path objects if they were already using os.path and other standard library APIs for path manipulation (rather than using string methods directly), while still avoiding the type confusion that comes from inheriting directly from str. >From a testing perspective, it would arguably make sense to tackle it as a separate "test_path_protocol" test case that checked pathlib compatibility with the APIs of interest, simply to avoid adding a pathlib dependency to all those module tests. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
Ethan Furman writes: > No, Stephen, that is not what this is about. Wrong Steven. Spelling matters in email too. And he's more worth paying attention to than I am. But I'll have my say anyway. ;-) > This is about the ugliness of code with str(path) this and > str(path) that -1 Not good enough. I wouldn't do it that often that "ugly" overrides the reasoning Brett presented, and if you do, I bet one or two personal helpers would clean up 95% of your cases. But see Nick's comment that "str(var)" is too permissive. I'll have to think about that, but my first take is he's right, and we need to do something about making use of Path more straightforward within the stdlib. Whatever that is, preferably would make life easier for 3rd party usage too, of course. Is error-checking within Path sufficiently robust in the light of "too permissive"? (I don't know exactly what I mean by that, but something like if "str(var_purporting_to_be_Path)" is too permissive, are we sure that "str(really_is_Path_var)" is "safe"? Apparently we haven't had a lot of beta testing.) > and let's not forget the Path(this_returned_string) and > Path(that_returned_string), But we don't object to (de)serializing dicts to (from) str (as JSON or pickle). I think Path vs. string is similarly different to justify saying so (especially when treating user input). Note, too, that based on discussion in that thread it seems likely that Path is likely to be inappropriate as an internal representation of URL.RFC3986.Path. Thus, strings that look like paths (as strings) actually will have multiple internal representations, similarly to the way that a dict can have multiple serializations. If representation transformation is not invertible, EIBTI says we need the "boilerplate". YMMV, but that's my take. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
Chris Angelico writes: > Outside of deliberate tests, we don't create files on our disks > whose names are strings of random bytes; Wishful thinking. First, names made of control characters have often been deliberately used by miscreants to conceal their warez. Second, in some systems it's all too easy to create paths with components in different locales (the place I've seen it most frequently is in NFS mounts). I think that's much less true today, but perhaps that's only because my employer figured out that it was much less pain if system paths were pure ASCII so that it mostly didn't matter what encoding users chose for their subtrees. It remains important to be able to handle nearly arbitrary bytestrings in file names as far as I can see. Please note that 100 million Japanese and 1 billion Chinese by and large still prefer their homegrown encodings (plural!!) to Unicode, while many systems are now defaulting filenames to UTF-8. There's plenty of room remaining for copying bytestrings to arguments of open and friends. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 06.04.16 01:41, Brett Cannon wrote: After a rather extensive discussion on python-ideas about pathlib.PurePath not inheriting from str, another point that came up was that the use of pathlib has been rather light. Unfortunately even the stdlib doesn't really use pathlib because it's currently marked as provisional (or at least that's why I haven't tried to use it where possible in importlib). Do we have a plan of what is required to remove the provisional label from pathlib? The behavior of the Path.resolve() method likely should be changed with breaking backward compatibility. There is an open issue about this. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote: > Option 4: define a rich-object-to-text path serialisation convention, Unfortunately that sounds like a classic "serious programming" solution (objects, abstractions, serialization, all big important words :-). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: > [...] we can't do: > > app_root = Path(...) > config = app_root/'settings.cfg' > with open(config) as blah: > # whatever > > It feels like instead of addressing this basic disconnect, the answer has > instead been: add that to pathlib! Which works great -- until a user or a > library gets this path object and tries to use something from os on it. I agree that asking for config.open() isn't the right answer here (even if it happens to work). But in this example, once 3.5.2 is out, the solution would be to use open(config.path), and that will also work when passing it to a library. Is it still unacceptable then? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 13:06, Alexander Walters wrote: > I think the naysayers would be satisfied with an object that... while not > str or bytes or a derived class of either... acted like str when it had to. > Is that possible without deriving from str or bytes? Only if the consuming code explicitly casts with "str()", and that's *too* permissive for most use cases (since __str__ and the __repr__ fallback are completely inappropriate as a "convert to a text representation of a filesystem path" command). A "__text__" protocol for non-lossy conversions to str would arguably be feasible, but its scope goes way beyond what's needed for a "rich path object" conversion protocol. Implementing that model in the general case would require something more akin to https://www.python.org/dev/peps/pep-0357/, which added __index__ as a guaranteed-non-lossy conversion from other types to a builtin integer, allowing non-builtin integers to accepted for things like slicing and sequence repetition, without inadvertently also accepting non-integral types like builtin floats. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 04/05/2016 07:40 PM, Steven D'Aprano wrote: On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote: To me it seems to basically be a question of whether people can be patient during a transition and embrace pathlib over time or if they will simply refuse to add support in libraries and refuse to use `getattr(path, 'path', path)` or `str(path)` in the mean time. Wait, what? Is that what the whole fuss is about? That some people refuse to call str(path) when passing a path object to a function that expects a string? No, Stephen, that is not what this is about. This is about the ugliness of code with str(path) this and str(path) that and let's not forget the Path(this_returned_string) and Path(that_returned_string), not to mention the frustrations of forgetting to cast a str to Path or a Path to str. It's about the horror of boiler-plate infecting our otherwise beautiful Python code. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 04/05/2016 03:55 PM, Guido van Rossum wrote: It's been provisional since 3.4. I think if it is still there in 3.6.0 it should be considered no longer provisional. But this may indeed be a test case for the ultimate fate of provisional modules -- should we remove it? We should either remove it or make the rest of the stdlib work with it. Currently, pathlib.*Paths are second-class citizens, and working with them is not significantly better than working with os.path.* simply because we have to cast to str every time we want to deal with any other part of the stdlib. Would making it inherit from str cause most hostility to disappear? I don't think that is necessary. The hostility (of which I have some) is because we can't do: app_root = Path(...) config = app_root/'settings.cfg' with open(config) as blah: # whatever It feels like instead of addressing this basic disconnect, the answer has instead been: add that to pathlib! Which works great -- until a user or a library gets this path object and tries to use something from os on it. To come at this from a different angle: Python now has Enum; it is arguable that Path is more important, or at least much more useful. We have IntEnum whose sole purpose in life is to make it possible to (mostly) seamlessly work with the stdlib and other libraries where ints are being used to represent enumerations; and in pathlib we have . . . absolutely nothing. We have the promise of great things and wonderful usability, but in reality we have just as much pain as before -- or more if we forget to str(path) somewhere. I said that pathlib.Path does not need to inherit from str, and I still think that; however, to be a good stepping stone / transitional library I think the pathlib backport does need to have its Paths inherit from str. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Wed, Apr 6, 2016 at 12:51 PM, Steven D'Aprano wrote: > On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote: > >> My personal view on the text/bytes debate is that a path is >> fundamentally a human concept, and consists therefore of text. The >> fact that some file systems store (at the low level) bytes and some >> store (I think) UTF-16 code units should be immaterial; path >> components exist for people. We can smuggle unrecognized bytes around, >> but ultimately, those bytes came from characters at some point - we >> just don't know the encoding. So a Path object has no relationship >> with bytes, only with str. > > That might be usually true in practice, but it is incorrect in > principle. Paths in POSIX systems like Linux are fundamentally > byte-strings with only two restrictions: \0 and \x2f are forbidden. That's the file system level. But more fundamentally than that, a path exists so that humans can refer to files. That's why they have *names*, not just dirent numbers. We could assign dirent number -1 to mean "parent directory", and then represent everything with tuples of directory entries. Follow the chain and you get an inode. Absolute paths would start with an inode (the root directory being inode 2) and proceed with dirents thereafter. Maybe we'd need a pseudo-inode to mean "current directory". Should we do paths like this? No way! Much better to have either "/home/rosuav/cpython/python" or (P.ROOT, "home", "rosuav", "cpython", "python") to represent them, because they exist for the human. The POSIX file system rules aren't insignificant, but my point is that every byte value seen in a file name was once representing a character. Outside of deliberate tests, we don't create files on our disks whose names are strings of random bytes; the normal use of a file system is to store files that a human has named. Hence my recommendation that a Path object be tied to str, but *not* to bytes. > The fact that paths in Linux mostly happen to look like English words > (often heavily abbreviated) is a historical accident. The file system > itself supported paths containing (say) \xff even back in the days when > text was pure US-ASCII and bytes over \x7f had no textual meaning, and > these days paths still support sequences of bytes that have no human > meaning in any encoding. > > I don't know if this makes the tiniest lick of difference for Pathlib. I > would be perfectly content if we stuck with the design decision that > Pathlib can only represent paths representable as Unicode strings, and > left weird POSIX filenames to the legacy byte-string interface. I'd prefer to keep the surrogateescape compatibility hack with U+DC00 to U+DCFF being used to smuggle bytes around. That means that every path can be represented as a Unicode string, with only minor loss of functionality (imagine a path with only a single character that can't be decoded - chances are a human can figure out what the file is), but it still strongly pushes to a Unicode interpretation of the path. An *actual* byte-string interface (such as os.listdir and friends support) would be completely outside of anything involving Pathlib. If you give bytes, you'll get bytes. And I'd deprecate that once Path objects are more broadly accepted. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 4/5/2016 22:44, Nick Coghlan wrote: Option 4: define a rich-object-to-text path serialisation convention, as paths are not conceptually the same as arbitrary strings Just as a nit to pick, it is perfectly acceptable for hypothetical path objects to raise when someone tries to shoehorn them into acting like arbitrary strings - open() will gladly halt and set fire if you try and pass the text of war and peace as an argument. I think the naysayers would be satisfied with an object that... while not str or bytes or a derived class of either... acted like str when it had to. Is that possible without deriving from str or bytes? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?
Robert Collins writes: > Sadly that has the ordering bug of assigning __wrapped__ first and appears > a little unmaintained based on the bug tracker :( You can fix two problems with one patch, then! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bugs.python.org email blockage at gmail
R. David Murray writes: > again. However, the IPV4 address has a poor reputation, and Verizon > at least appears to be blocking it. So more work is still needed. Don't take Verizon's policy as meaningful. Tell Verizon customers to get another address. That is the only solution that works for Verizon subscribers for very long (based on 15 years of Mailman-Users posts), they have never been a high-quality email provider. Further, Verizon (as an email provider) is in the process of dying anyway (they are very much alive as the new owner of AOL), so improvements in their email practices have a likelihood of zero to the resolution of a C float. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote: > My personal view on the text/bytes debate is that a path is > fundamentally a human concept, and consists therefore of text. The > fact that some file systems store (at the low level) bytes and some > store (I think) UTF-16 code units should be immaterial; path > components exist for people. We can smuggle unrecognized bytes around, > but ultimately, those bytes came from characters at some point - we > just don't know the encoding. So a Path object has no relationship > with bytes, only with str. That might be usually true in practice, but it is incorrect in principle. Paths in POSIX systems like Linux are fundamentally byte-strings with only two restrictions: \0 and \x2f are forbidden. The fact that paths in Linux mostly happen to look like English words (often heavily abbreviated) is a historical accident. The file system itself supported paths containing (say) \xff even back in the days when text was pure US-ASCII and bytes over \x7f had no textual meaning, and these days paths still support sequences of bytes that have no human meaning in any encoding. I don't know if this makes the tiniest lick of difference for Pathlib. I would be perfectly content if we stuck with the design decision that Pathlib can only represent paths representable as Unicode strings, and left weird POSIX filenames to the legacy byte-string interface. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 6 April 2016 at 09:45, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters >> wrote: >>> * pathlib should be improved (specifically by making it inherit from str) >> >> I'd like to see this specific change settled on in the PEP, actually. >> There are some arguments on both sides, and some hybrid solutions >> being proposed, and it looks to be an important enough issue to people >> for there to be an answer somewhere. It seems to come down to a >> sloppiness vs strictness concern, I think, but I'm not sure. > > This does sound like it's the crucial issue, and it is worth writing > up clearly the pros and cons. Let's draft those lists in a thread > (this one's fine) and then add them to the PEP. We can then decide to: > > - keep the status quo > - change PurePath to inherit from str > - decide it's never going to be settled and kill pathlib.py Option 4: define a rich-object-to-text path serialisation convention, as paths are not conceptually the same as arbitrary strings, and we can define a new protocol accepted by builtins and standard library modules, while third parties can't The most promising option for that is probably "getattr(path, 'path', path)", since the "path" attribute is being added to pathlib, and the given idiom can be readily adopted in Python 2/3 compatible code (since normal strings and any other object without a "path" attribute are passed through unchanged). Alternatively, since it's a protocol, double-underscores on the property name may be appropriate (i.e. "getattr(path, '__path__', path)") The next challenge would then be to make a list of APIs to be updated for 3.6 to implicitly accept "rich path" objects via the agreed convention, with pathlib.PurePath used as a test class: * open() * codecs.open() (et al) * io.* * os.path.* * other os functions * shutil.* * tempfile.* * shelve.* * csv.* The list wouldn't necessarily need to be 100% comprehensive (similar to the rollout of context management, "support rich path objects in API " may appear as future RFEs), but it should be comprehensive enough for rich path objects to mostly "just work" with other APIs that aren't specifically limiting their inputs to str objects (although using lower level APIs may force a conversion to the lower level plain text representation as a side-effect). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
I haven't really been following this discussion, but a couple of comments... On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote: > http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str Nice write-up, thanks. [...] > To me it seems to basically be a question of whether people can be patient > during a transition and embrace pathlib over time or if they will simply > refuse to add support in libraries and refuse to use `getattr(path, 'path', > path)` or `str(path)` in the mean time. Wait, what? Is that what the whole fuss is about? That some people refuse to call str(path) when passing a path object to a function that expects a string? Really? That's it? The mind boggles. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bugs.python.org email blockage at gmail
On 6 April 2016 at 11:27, Terry Reedy wrote: > On 4/5/2016 3:56 PM, R. David Murray wrote: >> >> We think we have a partial (and hopefully temporary) solution to the >> bugs email blockage: ipv6 has been turned off on bugs, so it is sending >> only from the ipv4 address. Google appears to be accepting the emails >> again. However, the IPV4 address has a poor reputation, and Verizon >> at least appears to be blocking it. So more work is still needed. > > Switching back to Google from Verizon. > > How is bugs email sent differently from list email? What the latter does > works fine, at least for gmail. bugs.python.org is currently sending notification emails directly to recipients, rather than routing them via the outbound SMTP server on mail.python.org. Reconfiguring it to relay notifications via the main outgoing server is the longer term fix, but an initial attempt at enabling that resulted in errors in the bugs.python.org mail logs, so David reverted to the direct email configuration for the time being. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 4/5/2016 7:45 PM, Guido van Rossum wrote: This does sound like it's the crucial issue, and it is worth writing up clearly the pros and cons. Let's draft those lists in a thread (this one's fine) and then add them to the PEP. We can then decide to: - keep the status quo - change PurePath to inherit from str - decide it's never going to be settled and kill pathlib.py (And yes, I'm dead serious about the latter, rather Solomonic option.) My sense of the discussion was that some people think that the new-in-upcoming 3.5.2 PurePath.path should serve as a substitute for inheriting from str. In particular, it should make it easy for stringpath functions to also accept path objects. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bugs.python.org email blockage at gmail
On 4/5/2016 3:56 PM, R. David Murray wrote: We think we have a partial (and hopefully temporary) solution to the bugs email blockage: ipv6 has been turned off on bugs, so it is sending only from the ipv4 address. Google appears to be accepting the emails again. However, the IPV4 address has a poor reputation, and Verizon at least appears to be blocking it. So more work is still needed. Switching back to Google from Verizon. How is bugs email sent differently from list email? What the latter does works fine, at least for gmail. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Wed, Apr 6, 2016 at 9:45 AM, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters >> wrote: >>> * pathlib should be improved (specifically by making it inherit from str) >> >> I'd like to see this specific change settled on in the PEP, actually. >> There are some arguments on both sides, and some hybrid solutions >> being proposed, and it looks to be an important enough issue to people >> for there to be an answer somewhere. It seems to come down to a >> sloppiness vs strictness concern, I think, but I'm not sure. > > This does sound like it's the crucial issue, and it is worth writing > up clearly the pros and cons. Let's draft those lists in a thread > (this one's fine) and then add them to the PEP. We can then decide to: > > - keep the status quo > - change PurePath to inherit from str > - decide it's never going to be settled and kill pathlib.py > > (And yes, I'm dead serious about the latter, rather Solomonic option.) Summarizing from memory to get things started. Inheriting from str makes it easier for code to support pathlib without really caring about the details. NOT inheriting from str forces code to be aware that it's working with a path, in the same way that text and bytes are fundamentally different things, and the Unicode string doesn't inherit from the byte string, nor vice versa. If a few crucial built-in functions support Path objects (notably open() and a handful of os.* functions), the bulk of stdlib support will be easy (sometimes trivial) to implement. Paths are [or are not] fundamentally different from strings. <-- argued point Paths might be backed by Unicode text, and might be backed by bytes. Should a Path be able to be implicitly constructed from either? Should there be some sort of "Path literal"? <-- possibly a completely separate question, to be resolved after this one How should .. be handled? Can you canonicalize a Path? Can Path handle URIs as well as file system paths? - My personal view on the text/bytes debate is that a path is fundamentally a human concept, and consists therefore of text. The fact that some file systems store (at the low level) bytes and some store (I think) UTF-16 code units should be immaterial; path components exist for people. We can smuggle unrecognized bytes around, but ultimately, those bytes came from characters at some point - we just don't know the encoding. So a Path object has no relationship with bytes, only with str. Whether a Path is fundamentally "a text string that uses slashes to separate components" or "a tuple of path components" is up for debate. Both make a lot of sense, and I'm somewhat inclined to the latter view; it allows for other forms of path component, such as an open directory (for statat/openat etc), or a special thing representing "current directory" or "root directory". ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Tue, 5 Apr 2016 at 15:55 Guido van Rossum wrote: > It's been provisional since 3.4. I think if it is still there in 3.6.0 > it should be considered no longer provisional. But this may indeed be > a test case for the ultimate fate of provisional modules -- should we > remove it? > > I have to admit I got tired of the discussions and muted them all. > :) I figured. I was close myself until I decided to be the "not inheriting from str is a sane decision" camp because people weren't understanding where the design decision probably came from, hence http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str . > Personally I am not worried about the light use (I always expected it > would take a long time to get adoption) Ditto. My expectation/hope is that once we stop having it be provisional and we start using it in the stdlib then usage will pick up, especially if libraries pick up the `getattr(path, 'path', path)` idiom as an easy transition technique until they decide to drop support for str-based paths. The main motivation of this email is actually to have newcomers to the sprints at PyCon US sprint on adding support for pathlib (after we add "path-like object" to the glossary to say something like "a `str` object or an object that has a `path` attribute that itself is a `str`"). > but I am worried about the > hostility towards the module. My last/only comment in the discussion > was about there possibly being a dichotomy between people who use > Python for scripting and those who use it to write more substantial > programs (I'm trying not to judge one group more important than > another -- I'm just observing there seem to be these two groups). But > I didn't stick around long enough to watch for responses to this idea. > Nope, no response (as Alexander pointed out). > > Would making it inherit from str cause most hostility to disappear? > Probably. Most people were upset with pathlib because they couldn't use it immediately with all of the third-party libraries out there on top of the stdlib because adoption has been so low. Now if we make a concerted effort to accept pathlib in the stdlib then this may be the kick in the pants that it takes to start getting people to accept it externally and the transition band-aid of inheriting from str may not be needed. To me it seems to basically be a question of whether people can be patient during a transition and embrace pathlib over time or if they will simply refuse to add support in libraries and refuse to use `getattr(path, 'path', path)` or `str(path)` in the mean time. Personally, if we can wait out the Python 3 transition I have no issue waiting on a transition like this that has no backward-compatibility issues and has a one-liner solution for adding shallow support (and thus is ripe for quick patches to projects). After the whole str thing the only other major topic was coming up with some easier way to produce pathlib.Path instances (e.g. the p-string suggestion). Nothing really came of those discussions that seemed concrete and reach consensus, though (I think that may have been where your scripting/substantial programming comment came from). > I'm sure there was a discussion about this when PEP 428 was originally > proposed, and I recall I was strongly in the camp of "it should not > inherit from str", but unfortunately the PEP has no mention of this > discussion or even the stated reason. > https://www.python.org/dev/peps/pep-0428/#no-confusion-with-builtins is the best you get in the PEP. -Brett > > --Guido > > > On Tue, Apr 5, 2016 at 3:41 PM, Brett Cannon wrote: > > After a rather extensive discussion on python-ideas about > pathlib.PurePath > > not inheriting from str, another point that came up was that the use of > > pathlib has been rather light. Unfortunately even the stdlib doesn't > really > > use pathlib because it's currently marked as provisional (or at least > that's > > why I haven't tried to use it where possible in importlib). > > > > Do we have a plan of what is required to remove the provisional label > from > > pathlib? > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: > On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters > wrote: >> * pathlib should be improved (specifically by making it inherit from str) > > I'd like to see this specific change settled on in the PEP, actually. > There are some arguments on both sides, and some hybrid solutions > being proposed, and it looks to be an important enough issue to people > for there to be an answer somewhere. It seems to come down to a > sloppiness vs strictness concern, I think, but I'm not sure. This does sound like it's the crucial issue, and it is worth writing up clearly the pros and cons. Let's draft those lists in a thread (this one's fine) and then add them to the PEP. We can then decide to: - keep the status quo - change PurePath to inherit from str - decide it's never going to be settled and kill pathlib.py (And yes, I'm dead serious about the latter, rather Solomonic option.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters wrote: > * pathlib should be improved (specifically by making it inherit from str) I'd like to see this specific change settled on in the PEP, actually. There are some arguments on both sides, and some hybrid solutions being proposed, and it looks to be an important enough issue to people for there to be an answer somewhere. It seems to come down to a sloppiness vs strictness concern, I think, but I'm not sure. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On 4/5/2016 18:55, Guido van Rossum wrote: My last/only comment in the discussion was about there possibly being a dichotomy between people who use Python for scripting and those who use it to write more substantial programs (I'm trying not to judge one group more important than another -- I'm just observing there seem to be these two groups). But I didn't stick around long enough to watch for responses to this idea. This was all but ignored. The opinions mentioned in the thread, without throwing my opinion behind any of them were: * pathlib should be improved (specifically by making it inherit from str) * the stdlib should be made to deal with pathlib without changing pathlib * pathlib is redundant to third party modules which work better * the continued existence of pathlib was briefly discussed You can insert the never-ending arguments for and against each of those points in your head - none of them were particularly convincing (in that i don't think anyone changed their position.) the split between utility scripting and application development was not really discussed. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
I think the provisional status can be safely lifted now. Even though pathlib hasn't seen that much use, there have been enough reports and discussion since its acception that I think the API has proven it's sane for general use. (as for importlib, pathlib might have too many dependencies for sane bootstrapping) Regards Antoine. Le 06/04/2016 00:41, Brett Cannon a écrit : > After a rather extensive discussion on python-ideas about > pathlib.PurePath not inheriting from str, another point that came up was > that the use of pathlib has been rather light. Unfortunately even the > stdlib doesn't really use pathlib because it's currently marked as > provisional (or at least that's why I haven't tried to use it where > possible in importlib). > > Do we have a plan of what is required to remove the provisional label > from pathlib? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
It's been provisional since 3.4. I think if it is still there in 3.6.0 it should be considered no longer provisional. But this may indeed be a test case for the ultimate fate of provisional modules -- should we remove it? I have to admit I got tired of the discussions and muted them all. Personally I am not worried about the light use (I always expected it would take a long time to get adoption) but I am worried about the hostility towards the module. My last/only comment in the discussion was about there possibly being a dichotomy between people who use Python for scripting and those who use it to write more substantial programs (I'm trying not to judge one group more important than another -- I'm just observing there seem to be these two groups). But I didn't stick around long enough to watch for responses to this idea. Would making it inherit from str cause most hostility to disappear? I'm sure there was a discussion about this when PEP 428 was originally proposed, and I recall I was strongly in the camp of "it should not inherit from str", but unfortunately the PEP has no mention of this discussion or even the stated reason. --Guido On Tue, Apr 5, 2016 at 3:41 PM, Brett Cannon wrote: > After a rather extensive discussion on python-ideas about pathlib.PurePath > not inheriting from str, another point that came up was that the use of > pathlib has been rather light. Unfortunately even the stdlib doesn't really > use pathlib because it's currently marked as provisional (or at least that's > why I haven't tried to use it where possible in importlib). > > Do we have a plan of what is required to remove the provisional label from > pathlib? > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] When should pathlib stop being provisional?
After a rather extensive discussion on python-ideas about pathlib.PurePath not inheriting from str, another point that came up was that the use of pathlib has been rather light. Unfortunately even the stdlib doesn't really use pathlib because it's currently marked as provisional (or at least that's why I haven't tried to use it where possible in importlib). Do we have a plan of what is required to remove the provisional label from pathlib? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bugs.python.org email blockage at gmail
We think we have a partial (and hopefully temporary) solution to the bugs email blockage: ipv6 has been turned off on bugs, so it is sending only from the ipv4 address. Google appears to be accepting the emails again. However, the IPV4 address has a poor reputation, and Verizon at least appears to be blocking it. So more work is still needed. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Anyone want to lead the sprints at PyCon US 2016?
The call has started to go out for sprint groups to list themselves online. Anyone want to specifically lead the core sprint this year? If no one specifically does then I will sign us up and do my usual thing of pointing people at the devguide and encourage people to ask questions but not do a lot of hand-holding (I'm expecting to be busy either working on GitHub migration stuff or doing other things that I have been neglecting due to my GitHub migration work). -- Forwarded message - From: Ewa Jodlowska Date: Mon, 4 Apr 2016 at 07:14 Subject: [PSF-Community] Sprinting at PyCon US 2016 To: Are you coming to PyCon US? Have you thought about sprinting? The coding Sprints are the hidden gem of PyCon, up to 4 days (June 2-5) of coding with many Python projects and their maintainers. And if you're coming to PyCon, taking part in the Sprints is easy! You don’t need to change your registration* to join the Sprints. There’s no additional registration fee, and you even get lunch. You do need to cover the additional lodging and other meals, but that’s it. If you’ve booked a room through the PyCon registration system, you'll need to contact the registration team at pycon2...@cteusa.com as soon as possible to request the extra nights. The sprinting itself (along with lunch every day) is free, so your only expenses are your room and other meals. If you're interested in what projects will be sprinting, just keep an eye on the sprints page on the PyCon web site at https://us.pycon.org/2016/community/sprints/ Be sure to check back, as groups are being added all the time. If you haven't sprinted before, or if you just need to brush up on sprinting tools and techniques, there will again be an 'Intro to Sprinting' session the evening of June 1, lead by Shauna Gordon-McKeon and other members of Python community. To grab a free ticket for this session, just visit https://www.eventbrite.com/e/introduction-to-open-source-the-pycon-sprints-tickets-22435151141 . *Please note that conference registration is sold out, but you do not need a conference registration to come to the Sprints. ___ PSF-Community mailing list psf-commun...@python.org https://mail.python.org/mailman/listinfo/psf-community ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help/advice needed with JyNI issue #4 (Tkinter on OSX)
Since this seems tcl/tk related your best bet is the tkinter mailing list: https://mail.python.org/mailman/listinfo/tkinter-discuss On Mon, Apr 4, 2016 at 8:38 PM, Stefan Richthofer wrote: > Hey everybody, > > I need help/advice for this JyNI-related issue: > https://github.com/Stewori/JyNI/issues/4 > Especially I need advice from someone familiar with TCL and TK internals, > preferably also Tkinter. > The issue is rather strange in the sense that it works well on Linux, while > the program hangs on OSX. Everything we found out so far was collected in the > thread linked above. Briefly speaking, on OSX TCL/TK does not produce a > particular event the loop is waiting for and does not display the window. > However logging suggests that calls to TCL/TK API are identical between Linux > and OSX runs, so we are really stuck here in finding out what is different on > Linux (our current logging does not cover function argument values though). > Any advise how I can debug interaction with TCL/TK to find the reason for the > missing event would be helpful. > > (Sorry if you might regard this off-topic for Python-dev; since JyNI is > somewhat a crossover-project (also containing lots of CPython 2.7 code) I am > asking in various locations. Starting here, because in this list I see best > chances to find someone who can help within the Python ecosystem. Next I > would look for a TCL/TK forum or something.) > > Thanks! > > Stefan > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?
Sadly that has the ordering bug of assigning __wrapped__ first and appears a little unmaintained based on the bug tracker :( On 5 Apr 2016 8:10 PM, "Victor Stinner" wrote: > See https://pypi.python.org/pypi/functools32 for the functools backport > for Python 2.7. > > Victor > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?
See https://pypi.python.org/pypi/functools32 for the functools backport for Python 2.7. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
