Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
2014-07-14 2:33 GMT+02:00 Ben Hoyt : > If we go with Victor's link-following .is_dir() and .is_file(), then > we probably need to add his suggestion of a follow_symlinks=False > parameter (defaults to True). Either that or you have to say > "stat.S_ISDIR(entry.lstat().st_mode)" instead, which is a little bit > less nice. You forgot one of my argument: we must have exactly the same API than os.path.is_dir() and pathlib.Path.is_dir(), because it would be very confusing (source of bugs) to have a different behaviour. Since these functions don't have any parameter (there is no such follow_symlink(s) parameter), I'm opposed to the idea of adding such parameter. If you really want to add a follow_symlink optional parameter, IMO you should modify all os.path.is*() functions and all pathlib.Path.is*() methods to add it there too. Maybe if nobody asked for this feature before, it's because it's not useful in practice. You can simply test explicitly is_symlink() before checking is_dir(). Well, let's imagine DirEntry.is_dir() does not follow symlinks. How do you test is_dir() and follow symlinks? "stat.S_ISDIR(entry.stat().st_mode)" ? You have to import the stat module, and use the ugly C macro S_ISDIR(). 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] Remaining decisions on PEP 471 -- os.scandir()
2014-07-14 4:17 GMT+02:00 Nick Coghlan : > Or the ever popular symlink to "." (or a directory higher in the tree). "." and ".." are explicitly ignored by os.listdir() an os.scandir(). > I think os.walk() is a good source of inspiration here: call the flag > "followlink" and default it to False. IMO the specific function os.walk() is not a good example. It includes symlinks to directories in the dirs list and then it does not follow symlink, it is a recursive function and has a followlinks optional parameter (default: False). Moreover, in 92% of cases, functions using os.listdir() and os.path.isdir() *follow* symlinks: https://mail.python.org/pipermail/python-dev/2014-July/135435.html 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] Remaining decisions on PEP 471 -- os.scandir()
2014-07-14 6:52 GMT+02:00 Ethan Furman : > We shoIf you put the option on scandir(), you uld have a flag for that, and > default it to False: > > scandir(path, *, followlinks=False, info=None, onerror=None) What happens to name and full_name with followlinks=True? Do they contain the name in the directory (name of the symlink) or name of the linked file? So it means that is_dir() may or may not follow symlinks depending how the object was built? 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] Remaining decisions on PEP 471 -- os.scandir()
First, just to clarify a couple of points. > You forgot one of my argument: we must have exactly the same API than > os.path.is_dir() and pathlib.Path.is_dir(), because it would be very > confusing (source of bugs) to have a different behaviour. Actually, I specifically included that argument. It's item (b) in the list in my original message yesterday. :-) > Since these functions don't have any parameter (there is no such > follow_symlink(s) parameter), I'm opposed to the idea of adding such > parameter. > > If you really want to add a follow_symlink optional parameter, IMO you > should modify all os.path.is*() functions and all pathlib.Path.is*() > methods to add it there too. Maybe if nobody asked for this feature > before, it's because it's not useful in practice. You can simply test > explicitly is_symlink() before checking is_dir(). Yeah, this is fair enough. > Well, let's imagine DirEntry.is_dir() does not follow symlinks. How do > you test is_dir() and follow symlinks? > "stat.S_ISDIR(entry.stat().st_mode)" ? You have to import the stat > module, and use the ugly C macro S_ISDIR(). No, you don't actually need stat/S_ISDIR in that case -- if DirEntry.is_dir() does not follow symlinks, you just say: entry.is_symlink() and os.path.isdir(entry.full_name) Or for the full test: (entry.is_symlink() and os.path.isdir(entry.full_name)) or entry.is_dir() On the other hand, if DirEntry.is_dir() does follow symlinks per your proposal, then to do is_dir without following symlinks you need to use DirEntry. lstat() like so: stat.S_ISDIR(entry.lstat().st_mode) So from this perspective it's somewhat nicer to have DirEntry.is_X() not follow links and use DirEntry.is_symlink() and os.path.isX() to supplement that if you want to follow links. I think Victor has a good point re 92% of the stdlib calls that use listdir and isX do follow links. However, I think Tim Delaney makes some good points above about the (not so) safety of scandir following symlinks by default -- symlinks to network file systems, nonexist files, or huge directory trees. In that light, this kind of thing should be opt-*in*. I guess I'm still slightly on the DirEntry-does-not-follow-links side of the fence, due to the fact that it's a method on the *directory entry* object, due to simplicity of implementation, and due to Tim Delaney's "it should be safe by default" point above. However, we're *almost* bikeshedding at this point, and I think we just need to pick one way or the other. It's straight forward to implement one in terms of the other in each case. -Ben ___ 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] == on object tests identity in 3.x - list delegation to members?
Am 14.07.2014 04:55, schrieb Ethan Furman: On 07/13/2014 08:13 AM, Andreas Maier wrote: Test #8: Same object of class C (C.__eq__() implemented with equality of x, C.__ne__() returning NotImplemented): obj1: type=, str=C(256), id=39406504 obj2: type=, str=C(256), id=39406504 a) obj1 is obj2: True C.__eq__(): self=39406504, other=39406504, returning True This is interesting/weird/odd -- why is __eq__ being called for an 'is' test? The debug messages are printed before the result is printed. So this is the debug message for the next case, 8.b). Sorry for not explaining it. Andy ___ 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] Remaining decisions on PEP 471 -- os.scandir()
Nick Coghlan writes: > On 13 Jul 2014 20:54, "Tim Delaney" wrote: >> >> On 14 July 2014 10:33, Ben Hoyt wrote: >>> >>> >>> >>> If we go with Victor's link-following .is_dir() and .is_file(), then >>> we probably need to add his suggestion of a follow_symlinks=False >>> parameter (defaults to True). Either that or you have to say >>> "stat.S_ISDIR(entry.lstat().st_mode)" instead, which is a little bit >>> less nice. >> >> >> Absolutely agreed that follow_symlinks is the way to go, disagree on the > default value. >> >>> >>> Given the above arguments for symlink-following is_dir()/is_file() >>> methods (have I missed any, Victor?), what do others think? >> >> >> I would say whichever way you go, someone will assume the opposite. IMO > not following symlinks by default is safer. If you follow symlinks by > default then everyone has the following issues: >> >> 1. Crossing filesystems (including onto network filesystems); >> >> 2. Recursive directory structures (symlink to a parent directory); >> >> 3. Symlinks to non-existent files/directories; >> >> 4. Symlink to an absolutely huge directory somewhere else (very annoying > if you just wanted to do a directory sizer ...). >> >> If follow_symlinks=False by default, only those who opt-in have to deal > with the above. > > Or the ever popular symlink to "." (or a directory higher in the tree). > > I think os.walk() is a good source of inspiration here: call the flag > "followlink" and default it to False. > Let's not multiply entities beyond necessity. There is well-defined *follow_symlinks* parameter https://docs.python.org/3/library/os.html#follow-symlinks e.g., os.access, os.chown, os.link, os.stat, os.utime and many other functions in os module support follow_symlinks parameter, see os.supports_follow_symlinks. os.walk is an exception that uses *followlinks*. It might be because it is an old function e.g., newer os.fwalk uses follow_symlinks. As it has been said: os.path.isdir, pathlib.Path.is_dir in Python File.directory? in Ruby, System.Directory.doesDirectoryExist in Haskell, `test -d` in shell do follow symlinks i.e., follow_symlinks=True as default is more familiar for .is_dir method. `cd path` in shell, os.chdir(path), `ls path`, os.listdir(path), and os.scandir(path) itself follow symlinks (even on Windows: http://bugs.python.org/issue13772 ). GUI file managers such as `nautilus` also treat symlinks to directories as directories -- you may click on them to open corresponding directories. Only *recursive* functions such as os.walk, os.fwalk do not follow symlinks by default, to avoid symlink loops. Note: the behavior is consistent with coreutils commands such as `cp` that follows symlinks for non-recursive actions but e.g., `du` utility that is inherently recursive doesn't follow symlinks by default. follow_symlinks=True as default for DirEntry.is_dir method allows to avoid easy-to-introduce bugs while replacing old os.listdir/os.path.isdir code or writing a new code using the same mental model. -- Akira ___ 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] Bluetooth 4.0 support in "socket" module
I was interested in providing patches for the socket module to add Bluetooth 4.0 support. I couldn't find any details on how to provide contributions to the Python project, though... Is there some online documentation with guidelines on how to contribute? Should I just provide a patch to this mailing list? Also, is there a method to test changes against all the different *nix variations? Is Bluez the standard across the different *nix variations? -Tim ___ 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] PEP 3121, 384 Refactoring Issues
Am 12.07.14 17:19, schrieb Nick Coghlan: > Using the stable ABI for standard library extensions also serves to > decouple them further from the internal details of the CPython runtime, > making it more likely they will be able to run correctly on alternative > interpreters (since emulating or otherwise supporting the limited API is > easier than supporting the whole thing). There are two features to be gained for the standard library from that A. with proper module shutdown support, it will be possible to release objects that are currently held in C global/static variables, as the C global variables will go away. This, in turn, is a step forward in the desire to allow for proper leak-free interpreter shutdown, and in the desire to base interpreter shutdown on GC. B. with proper use of heap types (instead of the static type objects), support for the multiple-interpreter feature will be improved, since type objects will be per-interpreter, instead of being global. This, in turn, is desirable since otherwise state changes can leak from one interpreter to the other. So I still maintain that the change is desirable even for the standard library. Regards, Martin ___ 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] Bluetooth 4.0 support in "socket" module
On Mon, Jul 14, 2014 at 3:57 PM, Tim Tisdall wrote: > I was interested in providing patches for the socket module to add > Bluetooth 4.0 support. I couldn't find any details on how to provide > contributions to the Python project, though... Is there some online > documentation with guidelines on how to contribute? Should I just provide > a patch to this mailing list? > > Also, is there a method to test changes against all the different *nix > variations? Is Bluez the standard across the different *nix variations? > > -Tim > > ___ > 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/g.rodola%40gmail.com > > Hello there, you can take a look at: https://docs.python.org/devguide/#contributing Patches must be submitted on the Python bug tracker: http://bugs.python.org/ -- Giampaolo - http://grodola.blogspot.com ___ 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] Bluetooth 4.0 support in "socket" module
On Mon, Jul 14, 2014 at 8:57 AM, Tim Tisdall wrote: > Is there some online documentation with guidelines on how to contribute? http://lmgtfy.com/?q=contribute+to+python Skip ___ 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] PEP 3121, 384 Refactoring Issues
On Mon Jul 14 2014 at 11:27:34 AM, "Martin v. Löwis" wrote: > Am 12.07.14 17:19, schrieb Nick Coghlan: > > Using the stable ABI for standard library extensions also serves to > > decouple them further from the internal details of the CPython runtime, > > making it more likely they will be able to run correctly on alternative > > interpreters (since emulating or otherwise supporting the limited API is > > easier than supporting the whole thing). > > There are two features to be gained for the standard library from that > > A. with proper module shutdown support, it will be possible to release >objects that are currently held in C global/static variables, as the >C global variables will go away. This, in turn, is a step forward in >the desire to allow for proper leak-free interpreter shutdown, and >in the desire to base interpreter shutdown on GC. > > B. with proper use of heap types (instead of the static type objects), >support for the multiple-interpreter feature will be improved, since >type objects will be per-interpreter, instead of being global. This, >in turn, is desirable since otherwise state changes can leak from >one interpreter to the other. > > So I still maintain that the change is desirable even for the standard > library. > I agree for PEP 3121 which is the initialization/finalization work. The stable ABi is not necessary. So maybe we should re-examine the patches and accept the bits that clean up init/finalization and leave out any ABi-related changes. ___ 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] Bluetooth 4.0 support in "socket" module
On Mon, Jul 14, 2014 at 10:30 AM, Skip Montanaro wrote: > On Mon, Jul 14, 2014 at 8:57 AM, Tim Tisdall wrote: > > Is there some online documentation with guidelines on how to contribute? > > http://lmgtfy.com/?q=contribute+to+python This response is unacceptable. Tim: check out https://docs.python.org/devguide/ and perhaps look at the core-mentorship[0] mailing list while coming up with your first contributions. It's a good first step to getting some guidance on the process and getting some eyes on your early patches. [0] https://mail.python.org/mailman/listinfo/core-mentorship/ ___ 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] Bluetooth 4.0 support in "socket" module
On Mon, Jul 14, 2014 at 10:53 AM, Brian Curtin wrote: >> > Is there some online documentation with guidelines on how to contribute? >> >> http://lmgtfy.com/?q=contribute+to+python > > > This response is unacceptable. Tim and I already discussed this offline. I admitted to being in a bit of a snarky mood today, and he seems to have accepted my post in good natured fashion. I should have at least added a smiley to my post. I will refrain from attempts at unadorned levity in the future. As penance, Tim or Brian, if you are are in or near Chicago, look me up. I'd be happy to buy y'all a beer. Skip ___ 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] Python Job Board
has now been dead for five months. -- ~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] Bluetooth 4.0 support in "socket" module
Would http://lmbtfy.com/?q=contribute+to+python# be more or less acceptable? -- H On 14 July 2014 09:09, Skip Montanaro wrote: > On Mon, Jul 14, 2014 at 10:53 AM, Brian Curtin wrote: > >> > Is there some online documentation with guidelines on how to > contribute? > >> > >> http://lmgtfy.com/?q=contribute+to+python > > > > > > This response is unacceptable. > > Tim and I already discussed this offline. I admitted to being in a bit > of a snarky mood today, and he seems to have accepted my post in good > natured fashion. I should have at least added a smiley to my post. I > will refrain from attempts at unadorned levity in the future. > > As penance, Tim or Brian, if you are are in or near Chicago, look me > up. I'd be happy to buy y'all a beer. > > Skip > ___ > 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/hasan.diwan%40gmail.com > -- Sent from my mobile device Envoyé de mon portable ___ 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] Bluetooth 4.0 support in "socket" module
Naw, I'd accept that response. I think I searched on Friday, but forgot about finding that. :) There's enough traffic on a mailing list without useless noise. Thanks for all the responses. On Mon, Jul 14, 2014 at 11:53 AM, Brian Curtin wrote: > On Mon, Jul 14, 2014 at 10:30 AM, Skip Montanaro wrote: > >> On Mon, Jul 14, 2014 at 8:57 AM, Tim Tisdall wrote: >> > Is there some online documentation with guidelines on how to contribute? >> >> http://lmgtfy.com/?q=contribute+to+python > > > This response is unacceptable. > > Tim: check out https://docs.python.org/devguide/ and perhaps look at the > core-mentorship[0] mailing list while coming up with your first > contributions. It's a good first step to getting some guidance on the > process and getting some eyes on your early patches. > > [0] https://mail.python.org/mailman/listinfo/core-mentorship/ > ___ 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] Python Job Board
On Mon Jul 14 2014 at 12:17:03 PM, Ethan Furman wrote: > has now been dead for five months. > This is the wrong place to ask about this. It falls under the purview of the web site who you can email at webmaster@ or submit an issue at https://github.com/python/pythondotorg . But I know from PSF status reports that it's being actively rewritten and fixed to make it manageable for more than one person to run easily. ___ 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] Python Job Board
On Mon, Jul 14, 2014 at 11:59 AM, Brett Cannon wrote: > This is the wrong place to ask about this. It falls under the purview of the > web site who you can email at webmaster@ or submit an issue at > https://github.com/python/pythondotorg . But I know from PSF status reports > that it's being actively rewritten and fixed to make it manageable for more > than one person to run easily. Agree with that. I originally skipped this post because I'm pretty sure MAL who is heavily involved with the rewrite effort) still hangs out here. I will modify Brett's admonition a bit though. A better place to comment about the job board (and perhaps volunteer to help with the current effort) is j...@python.org. Skip ___ 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] PEP 3121, 384 Refactoring Issues
On Mon, Jul 14, 2014 at 11:41 AM, Brett Cannon wrote: > So maybe we should re-examine the patches and accept the bits that clean > up init/finalization and leave out any ABI-related changes. This is precisely what I suggested two years ago. http://bugs.python.org/issue15390#msg170249 I am not against ABI-related changes in principle, but I think these changes should be carefully considered on a case by case basis and not applied wholesale. ___ 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] Python Job Board
On 07/14/2014 10:43 AM, Skip Montanaro wrote: On Mon, Jul 14, 2014 at 11:59 AM, Brett Cannon wrote: This is the wrong place to ask about this. It falls under the purview of the web site who you can email at webmaster@ or submit an issue at https://github.com/python/pythondotorg . But I know from PSF status reports that it's being actively rewritten and fixed to make it manageable for more than one person to run easily. Agree with that. I originally skipped this post because I'm pretty sure MAL who is heavily involved with the rewrite effort) still hangs out here. I will modify Brett's admonition a bit though. A better place to comment about the job board (and perhaps volunteer to help with the current effort) is j...@python.org. Mostly just hoping to raise awareness in case anybody here is able/willing to pitch in. -- ~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] Bluetooth 4.0 support in "socket" module
On 7/14/2014 9:57 AM, Tim Tisdall wrote: 2 questions not answered yet. Also, is there a method to test changes against all the different *nix variations? We have a set of buildbots. https://www.python.org/dev/buildbot/ Is Bluez the standard across the different *nix variations? No idea. -- 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] Bluetooth 4.0 support in "socket" module
Tim, Are you aware of https://code.google.com/p/pybluez/ ? -- H On 14 July 2014 13:42, Terry Reedy wrote: > On 7/14/2014 9:57 AM, Tim Tisdall wrote: > > 2 questions not answered yet. > > > Also, is there a method to test changes against all the different *nix >> variations? >> > > We have a set of buildbots. > https://www.python.org/dev/buildbot/ > > > Is Bluez the standard across the different *nix variations? >> > > No idea. > > -- > 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/ > hasan.diwan%40gmail.com > -- Sent from my mobile device Envoyé de mon portable ___ 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] Bluetooth 4.0 support in "socket" module
On Mon, 14 Jul 2014 16:42:25 -0400, Terry Reedy wrote: > On 7/14/2014 9:57 AM, Tim Tisdall wrote: > > 2 questions not answered yet. > > > Also, is there a method to test changes against all the different *nix > > variations? > > We have a set of buildbots. > https://www.python.org/dev/buildbot/ > > > Is Bluez the standard across the different *nix variations? > > No idea. It would be really nice to answer that and the related testing questions. The socket module has bluetooth support, but there are no tests. An effort to write some was started at the Bloomberg sprint last month, but nothing has been posted to the issue yet: http://bugs.python.org/issue7687 Is Bluetooth 4.0 something different from what the socket module already has? --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
Re: [Python-Dev] Bluetooth 4.0 support in "socket" module
Quite aware. I'm pretty sure it has no 4.x LE capabilities. Last I checked it seemed like a dead project, but there seems to be some activity there now. On Jul 14, 2014 4:47 PM, "Hasan Diwan" wrote: > Tim, > Are you aware of https://code.google.com/p/pybluez/ ? -- H > > > On 14 July 2014 13:42, Terry Reedy wrote: > >> On 7/14/2014 9:57 AM, Tim Tisdall wrote: >> >> 2 questions not answered yet. >> >> >> Also, is there a method to test changes against all the different *nix >>> variations? >>> >> >> We have a set of buildbots. >> https://www.python.org/dev/buildbot/ >> >> >> Is Bluez the standard across the different *nix variations? >>> >> >> No idea. >> >> -- >> 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/ >> hasan.diwan%40gmail.com >> > > > > -- > Sent from my mobile device > Envoyé de mon portable > > ___ > 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/tisdall%40gmail.com > > ___ 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] Bluetooth 4.0 support in "socket" module
The major change is to the Bluetooth address struct. It now has an added value for the distinction between "public" and "random" 4.x addresses. Also some added constants to open LE connections. On Jul 14, 2014 5:32 PM, "R. David Murray" wrote: > On Mon, 14 Jul 2014 16:42:25 -0400, Terry Reedy wrote: > > On 7/14/2014 9:57 AM, Tim Tisdall wrote: > > > > 2 questions not answered yet. > > > > > Also, is there a method to test changes against all the different *nix > > > variations? > > > > We have a set of buildbots. > > https://www.python.org/dev/buildbot/ > > > > > Is Bluez the standard across the different *nix variations? > > > > No idea. > > It would be really nice to answer that and the related testing questions. > The socket module has bluetooth support, but there are no tests. > An effort to write some was started at the Bloomberg sprint last month, > but nothing has been posted to the issue yet: > > http://bugs.python.org/issue7687 > > Is Bluetooth 4.0 something different from what the socket module already > has? > > --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/tisdall%40gmail.com > ___ 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] Python Job Board
>From >http://www.reddit.com/r/Python/comments/17c69p/i_was_told_by_a_friend_that_learning_python_for/c84bswd : >* http://www.python.org/community/jobs/ >* https://jobs.github.com/positions?description=python >* http://careers.joelonsoftware.com/jobs?searchTerm=python >* http://www.linkedin.com/jsearch?keywords=python >* http://www.indeed.com/q-Python-jobs.html >* http://www.simplyhired.com/a/jobs/list/q-python >* http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&FREE_TEXT=python >* http://careers.stackoverflow.com/jobs/tag/python >* http://www.pythonjobs.com/ >* http://www.djangojobs.org/ -- Wes Turner On Mon, Jul 14, 2014 at 1:24 PM, Ethan Furman wrote: > On 07/14/2014 10:43 AM, Skip Montanaro wrote: > >> On Mon, Jul 14, 2014 at 11:59 AM, Brett Cannon wrote: >>> >>> >>> This is the wrong place to ask about this. It falls under the purview of >>> the >>> web site who you can email at webmaster@ or submit an issue at >>> https://github.com/python/pythondotorg . But I know from PSF status >>> reports >>> that it's being actively rewritten and fixed to make it manageable for >>> more >>> than one person to run easily. >> >> >> Agree with that. I originally skipped this post because I'm pretty >> sure MAL who is heavily involved with the rewrite effort) still hangs >> out here. I will modify Brett's admonition a bit though. A better >> place to comment about the job board (and perhaps volunteer to help >> with the current effort) is j...@python.org. > > > Mostly just hoping to raise awareness in case anybody here is able/willing > to pitch in. > > -- > ~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/wes.turner%40gmail.com ___ 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] Remaining decisions on PEP 471 -- os.scandir()
> Let's not multiply entities beyond necessity. > > There is well-defined *follow_symlinks* parameter > https://docs.python.org/3/library/os.html#follow-symlinks > e.g., os.access, os.chown, os.link, os.stat, os.utime and many other > functions in os module support follow_symlinks parameter, see > os.supports_follow_symlinks. Huh, interesting. I didn't know os.stat() had a follow_symlinks parameter -- when False, it's equivalent to lstat. If DirEntry has a .stat(follow_symlinks=True) method, we don't actually need lstat(). > os.walk is an exception that uses *followlinks*. It might be because it > is an old function e.g., newer os.fwalk uses follow_symlinks. Yes, I'm sure that's correct. Today it'd be called follow_symlinks, but obviously one can't change os.walk() anymore. > Only *recursive* functions such as os.walk, os.fwalk do not follow > symlinks by default, to avoid symlink loops. [...] > > follow_symlinks=True as default for DirEntry.is_dir method allows to > avoid easy-to-introduce bugs while replacing old > os.listdir/os.path.isdir code or writing a new code using the same > mental model. I think these are good points, especially that of porting existing listdir()/os.path.isdir() code and avoiding bugs. As I mentioned, I was really on the fence about the link-following thing, but if it's a tiny bit harder to implement but it avoids bugs (and I already had a bug with this when implementing os.walk), that's a worthwhile trade-off. In light of that, I propose I update the PEP to basically follow Victor's model of is_X() and stat() following symlinks by default, and allowing you to specify follow_symlinks=False if you want something other than that. Victor had one other question: > What happens to name and full_name with followlinks=True? > Do they contain the name in the directory (name of the symlink) > or name of the linked file? I would say they should contain the name and full path of the entry -- the symlink, NOT the linked file. They kind of have to, right, otherwise they'd have to be method calls that potentially call the system. In any case, here's the modified proposal: scandir(path='.') -> generator of DirEntry objects, which have: * name: name as per listdir() * full_name: full path name (not necessarily absolute), equivalent of os.path.join(path, entry.name) * is_dir(follow_symlinks=True): like os.path.isdir(entry.full_name), but free in most cases; cached per entry * is_file(follow_symlinks=True): like os.path.isfile(entry.full_name), but free in most cases; cached per entry * is_symlink(): like os.path.islink(), but free in most cases; cached per entry * stat(follow_symlinks=True): like os.stat(entry.full_name, follow_symlinks=follow_symlinks); cached per entry The above may not be quite perfect, but it's good, and I think there's been enough bike-shedding on the API. :-) So please speak now or forever hold your peace. :-) I intend to update the PEP to reflect this and make a few other clarifications in the next few days. -Ben ___ 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] Python Job Board
On 07/14/2014 06:01 PM, Wes Turner wrote: From http://www.reddit.com/r/Python/comments/17c69p/i_was_told_by_a_friend_that_learning_python_for/c84bswd : * http://www.python.org/community/jobs/ * https://jobs.github.com/positions?description=python * http://careers.joelonsoftware.com/jobs?searchTerm=python * http://www.linkedin.com/jsearch?keywords=python * http://www.indeed.com/q-Python-jobs.html * http://www.simplyhired.com/a/jobs/list/q-python * http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&FREE_TEXT=python * http://careers.stackoverflow.com/jobs/tag/python * http://www.pythonjobs.com/ * http://www.djangojobs.org/ Nice, thanks! -- ~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] Remaining decisions on PEP 471 -- os.scandir()
On 07/14/2014 07:48 PM, Ben Hoyt wrote: In any case, here's the modified proposal: scandir(path='.') -> generator of DirEntry objects, which have: * name: name as per listdir() * full_name: full path name (not necessarily absolute), equivalent of os.path.join(path, entry.name) * is_dir(follow_symlinks=True): like os.path.isdir(entry.full_name), but free in most cases; cached per entry * is_file(follow_symlinks=True): like os.path.isfile(entry.full_name), but free in most cases; cached per entry * is_symlink(): like os.path.islink(), but free in most cases; cached per entry * stat(follow_symlinks=True): like os.stat(entry.full_name, follow_symlinks=follow_symlinks); cached per entry The above may not be quite perfect, but it's good, and I think there's been enough bike-shedding on the API. :-) Looks doable. Just make sure the cached entries reflect the 'follow_symlinks' setting -- so a symlink could end up with both an lstat cached entry and a stat cached entry. -- ~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
[Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
Le mardi 15 juillet 2014, Ben Hoyt a écrit : > > > Victor had one other question: > > > What happens to name and full_name with followlinks=True? > > Do they contain the name in the directory (name of the symlink) > > or name of the linked file? > > I would say they should contain the name and full path of the entry -- > the symlink, NOT the linked file. They kind of have to, right, > otherwise they'd have to be method calls that potentially call the > system. > Sorry, I don't remember who but someone proposed to add the follow_symlinks parameter in scandir() directly. If the parameter is added to methods, there is no such issue. I like the compromise of adding an optional follow_symlinks to is_xxx() and stat() method. No need for .lstat(). Again: remove any garantee about the cache in the definitions of methods, instead copy the doc from os.path and os. Add a global remark saying that most methods don't need any syscall in general, except for symlinks (with follow_symlinks=True). 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
