On 15 February 2015 at 00:44, Paul Moore wrote:
> I'm looking at putting together a patch for CPython to implement PEP
> 441. In doing so, there are a few issues that I'd like to raise with
> the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
> Nick proposed renaming this to "pyza
On Sat, Feb 14, 2015 at 01:26:36PM -0500, Alexander Belopolsky wrote:
> On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano
> wrote:
>
> > Why can't int, str, list, tuple etc. be more like datetime?
>
>
> They are. In all these types, class methods call subclass constructors but
> instance method
I'm about to start doing a rework on distutils.msvc[9]compiler.MSVCCompiler for
Python 3.5 to be able to handle forward-compatibility better. Right now I've
tweaked msvc9compiler enough for VS 2015, but it won't handle later VS versions
automatically.
Is there any reason to keep the old msvcco
Le 14 févr. 2015 18:47, "Gregory P. Smith" a écrit :
> I think the "or None" semantics are a bad idea.
Oh, in fact it shouldn't be None but 0 onWindows to be consistent with
DirEntry.stat().st_ino which is also equal to 0.
The value 0 is not a valid inode number.
Victor
>> The whole point of scandir is to expose low-level system calls in a
>> cross-platform way.
>
> Cross-platform is great and preferable, but low-level system facilities
> should be made available even when they are unique to a particular OS.
Yes, but this can be made cross-platform fairly easily,
Antoine Pitrou :
> The whole point of scandir is to expose low-level system calls in a
> cross-platform way.
Cross-platform is great and preferable, but low-level system facilities
should be made available even when they are unique to a particular OS.
Marko
_
>> +1 for inode support. I agree with the above -- it should either raise
>> AttributeError on Windows if it's not going to be set ... or it should
>> be more like Victor's original proposal where .inode() is a method
>> that calls stat on Windows. I don't have strong feelings.
>
> The whole point
That suggests the .inode() method approach makes more sense then.
On Sat, Feb 14, 2015, 12:44 PM Antoine Pitrou wrote:
> On Sat, 14 Feb 2015 15:32:07 -0500
> Ben Hoyt wrote:
> > > +1 we need to provide the inode (we shouldn't be throwing anything
> from the
> > > underlying directory entry away
On Sat, Feb 14, 2015 at 2:36 PM, Georg Brandl wrote:
> > In the case of int, there is a good reason for this behavior - bool. In
> python,
> > we want True + True == 2. In numpy, where binary operations preserve
> > subclasses, you have
> >
> import numpy
> numpy.bool_(1) + numpy.bool
On Sat, 14 Feb 2015 15:32:07 -0500
Ben Hoyt wrote:
> > +1 we need to provide the inode (we shouldn't be throwing anything from the
> > underlying directory entry away when possible). But...
> >
> > I think the "or None" semantics are a bad idea. It'd be better for this to
> > raise AttributeError
Oops, I meant to call super if necessary:
@classmethod
def __make_me_cls__(cls, arg_cls, *args, **kwargs):
if arg_cls is C:
pass
elif arg_cls is D:
args, kwargs = modified_args_for_D(args, kwargs)
elif arg_cls is E:
args, kwargs =
> +1 we need to provide the inode (we shouldn't be throwing anything from the
> underlying directory entry away when possible). But...
>
> I think the "or None" semantics are a bad idea. It'd be better for this to
> raise AttributeError on Windows so that someone can't write the most natural
> for
I think the __make_me__ pattern discussed earlier is still the most generic
cooperative solution. Here it is with a classmethod version too:
class C(D, E):
def some_method(self):
return __make_me__(self, C)
def __make_me__(self, arg_cls, *args, **kwargs):
if arg_cls is C:
On 02/14/2015 07:26 PM, Alexander Belopolsky wrote:
> In the case of int, there is a good reason for this behavior - bool. In
> python,
> we want True + True == 2. In numpy, where binary operations preserve
> subclasses, you have
>
import numpy
numpy.bool_(1) + numpy.bool_(1)
> True
On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano
wrote:
> Why can't int, str, list, tuple etc. be more like datetime?
They are. In all these types, class methods call subclass constructors but
instance methods don't.
>>> class Int(int):
... pass
...
>>> Int.from_bytes(bytes([1,2,3]), 'big
On Sat Feb 14 2015 at 3:17:51 AM Victor Stinner
wrote:
> 2015-02-14 11:57 GMT+01:00 Victor Stinner :
> > I propose something else: a DirEntry.inode read-only property (...)
>
> Full DirEntry API:
>
> - name (str) attribute
> - path (str) read-only property, created at the first call
> - inode (in
"Instead of requiring *every* subclass to override all the methods,
couldn't we require the base classes (like int) to assume that the
signature is unchanged and call type(self), and leave it up to the
subclass to override all the methods *only* if the signature has
changed?"
I assumed everyone wa
I'm looking at putting together a patch for CPython to implement PEP
441. In doing so, there are a few issues that I'd like to raise with
the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
Nick proposed renaming this to "pyzapp", which I like, but it's not a
big deal either way).
On Fri, Feb 13, 2015 at 06:03:35PM -0500, Neil Girdhar wrote:
> I personally don't think this is a big enough issue to warrant any changes,
> but I think Serhiy's solution would be the ideal best with one additional
> parameter: the caller's type. Something like
>
> def __make_me__(self, cls, *ar
2015-02-14 11:57 GMT+01:00 Victor Stinner :
> I propose something else: a DirEntry.inode read-only property (...)
Full DirEntry API:
- name (str) attribute
- path (str) read-only property, created at the first call
- inode (int or None) attribute <=== my proposition
- is_dir(*, follow_symlinks=Tr
Le samedi 14 février 2015, Stephen J. Turnbull a
écrit :
>
> IMO: Document the limitation (if no extra syscall) or inefficiency
> (with the syscall), and let the user choose.
Hum, by the way, I don't know if we should dd the method on Windows. As I
said, I don't want to cache The result of the
On 14 Feb 2015 08:57, "Alexander Belopolsky"
wrote:
>
>
> On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar
wrote:
>>
>> Interesting:
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
>
>
> Let me humbly conjecture that the people who wrote t
On 14 Feb 2015 07:39, "Isaac Schwabacher" wrote:
>
> On 15-02-13, Guido van Rossum wrote:
> > Are you willing to wait 10 days for an answer? I'm out of round
tuits for a while.
>
> IIUC, the argument is that the Liskov Substitution Principle is a
statement about how objects of a subtype behave re
On 14 Feb 2015 13:17, "Cameron Simpson" wrote:
>
> -1 on that. People will use it! Given the doco above, it should be
obvious under what circumstances one might choose to call stat, and making
that stat overt means it is less likely to be called unwisely.
>
> Since scandir is all about efficiency,
On 14 Feb 2015 07:31, "Paul Moore" wrote:
>
> (By the way, on a procedural note, how do I update a PEP? Do I just
> send an updated version to p...@python.org, or is there a better way?)
If you're happy to handle the PEP editor responsibilities described in PEP
1 yourself, you can also ask for co
On 14 Feb 2015 03:43, "Nathaniel Smith" wrote:
>
> On 13 Feb 2015 02:09, "Victor Stinner" wrote:
> >
> > A alternative is to add a new _scandir.c module to host the new C
> > code, and share some code with posixmodule.c: remove "static" keyword
> > from required C functions (functions to convert
26 matches
Mail list logo
