On 14.02.15 01:03, Neil Girdhar wrote:
Now the derived class knows who is asking for a copy. In the case of
defaultdict, for example, he can implement __make_me__ as follows:
def __make_me__(self, cls, *args, **kwargs):
if cls is dict: return default_dict(self.default_factory, *args,
**kwa
On 14.02.15 03:12, Ethan Furman wrote:
The third choice is to use different specially designed constructor.
class A(int):
--> class A(int):
... def __add__(self, other):
... return self.__make_me__(int(self) + int(other))
... def __repr__(self):
... return 'A(%d)' % sel
On 14Feb2015 11:35, Stephen J. Turnbull wrote:
Victor Stinner writes:
> *** Now the real question: is it useful to know the inode number
> (st_ino) without the device number (st_dev)? ***
>
> On POSIX, you can still get the st_dev from DirEntry.stat(), but it
> always require a system call. So y
Victor Stinner writes:
> *** Now the real question: is it useful to know the inode number
> (st_ino) without the device number (st_dev)? ***
>
> On POSIX, you can still get the st_dev from DirEntry.stat(), but it
> always require a system call. So you loose the whole purpose of
> DirEntry (
Hmm... super *is* a problem, because if we super, we can end up asking
superclasses that we then won't know how to mimic. So what we really want is to
move the superclasses we can mimic to the front of the MRO. If none of those
can indirectly mimic the base class, then we try the other classes i
On 15-02-13, 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, *args, **kwargs)
>
>
> and t
I think it works as Isaac explained if __make_me__ is an instance method
that also accepts the calling class type.
On Fri, Feb 13, 2015 at 8:12 PM, Ethan Furman wrote:
> On 02/13/2015 02:31 PM, Serhiy Storchaka wrote:
> > On 13.02.15 05:41, Ethan Furman wrote:
> >> So there are basically two cho
On 02/13/2015 02:31 PM, Serhiy Storchaka wrote:
> On 13.02.15 05:41, Ethan Furman wrote:
>> So there are basically two choices:
>>
>> 1) always use the type of the most-base class when creating new instances
>>
>> pros:
>> - easy
>> - speedy code
>> - no possible tracebacks on
You're right.
On Fri, Feb 13, 2015 at 7:55 PM, Isaac Schwabacher
wrote:
> On 15-02-13, Neil Girdhar wrote:
> > Unlike a regular method, you would never need to call super since you
> should know everyone that could be calling you. Typically, when you call
> super, you have something like this:
On 15-02-13, Neil Girdhar wrote:
> Unlike a regular method, you would never need to call super since you should
> know everyone that could be calling you. Typically, when you call super, you
> have something like this:
>
> A < B, C
>
>
> B < D
>
>
> so you end up with
>
>
> mro: A, B, C,
Isaac Schwabacher wrote:
IIUC, the argument is that the Liskov Substitution Principle is a statement
about how objects of a subtype behave relative to objects of a supertype, and
it doesn't apply to constructors because they aren't behaviors of existing
objects.
Another way to say that is that
On 14 Feb 2015 01:47, "Paul Moore" wrote:
>
> On 13 February 2015 at 14:27, Steve Dower
wrote:
> > If py.exe starts defaulting to whatever is on PATH then I don't see the
> > point of it. Knowing that you'll get the latest 2.x version by default
is
> > quite handy (I'd be quite okay changing that
Unlike a regular method, you would never need to call super since you
should know everyone that could be calling you. Typically, when you call
super, you have something like this:
A < B, C
B < D
so you end up with
mro: A, B, C, D
And then when A calls super and B calls super it gets C which i
On 13 February 2015 at 22:49, Zachary Ware wrote:
> It's strange that
> you're getting modifications, though; I can't reproduce on Linux (and
> don't have quick access to Windows right now). Make sure you're
> definitely at tip, and if it's still changing please open an issue.
Definitely at tip.
On Fri, Feb 13, 2015 at 4:56 PM, Eric Snow wrote:
> On Fri, Feb 13, 2015 at 3:49 PM, Zachary Ware
> wrote:
>> Yes, importlib.h changes should never be included in a patch (it would
>
> Unless they should. :) E.g. you modified importlib/_bootstrap.py, the
> marshal format, bytecodes, etc.
If I'm
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, *args, **kwargs)
and the idea is that any time you want to construct a typ
On Fri, Feb 13, 2015 at 3:49 PM, Zachary Ware
wrote:
> On Fri, Feb 13, 2015 at 4:09 PM, Paul Moore wrote:
>> I'm working on a patch for the Python launcher. I built Python
>> (current tip, on MS Windows, with VS 2015), and I've just noticed that
>> hg status shows:
>>
hg status -mard
>> M Doc
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 the top answers have
background in less capable languages than P
On Fri, Feb 13, 2015 at 4:09 PM, Paul Moore wrote:
> I'm working on a patch for the Python launcher. I built Python
> (current tip, on MS Windows, with VS 2015), and I've just noticed that
> hg status shows:
>
>>>hg status -mard
> M Doc\using\windows.rst
> M PC\launcher.c
> M Python\importlib.h
>
On 13.02.15 05:41, Ethan Furman wrote:
So there are basically two choices:
1) always use the type of the most-base class when creating new instances
pros:
- easy
- speedy code
- no possible tracebacks on new object instantiation
cons:
- a subclass that needs/wan
I'm working on a patch for the Python launcher. I built Python
(current tip, on MS Windows, with VS 2015), and I've just noticed that
hg status shows:
>>hg status -mard
M Doc\using\windows.rst
M PC\launcher.c
M Python\importlib.h
I didn't change importlib.h, and I don't see that the changes I did
I am still in favor of this PEP but have run out of time to review it and
the feedback. I'm going on vacation for a week or so, maybe I'll find time,
if not I'll start reviewing this around Feb 23.
--
--Guido van Rossum (python.org/~guido)
___
Python-De
On 15-02-13, Neil Girdhar wrote:
> Interesting:
> http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
You'd better believe I read that thread not 20 minutes ago. :)
> On Fri, Feb 13, 2015 at 3:37 PM, Isaac Schwabacher
> target="1">ischw
Interesting:
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
On Fri, Feb 13, 2015 at 3:37 PM, 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
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 relative to objects of a supertype, and
it doesn't apply
On 12 February 2015 at 19:44, Paul Moore wrote:
> Impact on Script Launching
> ==
Now that I'm looking into the details of the code for the launcher,
I've noticed that a shebang line of "#!/usr/bin/env python" will first
of all search PATH for a python executable, before f
On Fri, Feb 13, 2015 at 5:07 AM, Victor Stinner
wrote:
> Now I see 3 choices:
>
> - take the full C implementation, because it's much faster (at least
> 3.4x faster!)
> - reject the whole PEP 471 (not nice), because it adds too much code
> for a minor speedup (not true on Windows: up to 44x faste
Are you willing to wait 10 days for an answer? I'm out of round tuits for a
while.
On Fri, Feb 13, 2015 at 10:22 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
> >>
> >> FWIW yo
On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>>
>> FWIW you're wrong when you claim that "a constructor is no different
from any other method". Someone else should probably explain this (it's an
old argument that's been thoroughly settled).
>
>
> We
On Fri, Feb 13, 2015 at 1:11 PM, Guido van Rossum wrote:
>
>
>> Note that the original pure python prototype of the datetime module had
>> date.__add__ and friends call self.__class__(year, month, day).
>> Unfortunately, it looks like the original sandbox did not survive the the
>> hg conversion,
On Fri, Feb 13, 2015 at 10:02 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Fri, Feb 13, 2015 at 12:35 PM, Guido van Rossum
> wrote:
>
>> IIUC you're proposing that the base class should *try* to construct an
>> instance of the subclass by calling the type with an argum
On Fri, Feb 13, 2015 at 12:35 PM, Guido van Rossum wrote:
> IIUC you're proposing that the base class should *try* to construct an
> instance of the subclass by calling the type with an argument, and fail if
> it doesn't work. But that makes the whole thing brittle in the light of
> changes to th
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 Windows attributes to
> a os.stat_result object).
Hopefully
On Thu, Feb 12, 2015 at 8:58 PM, Ethan Furman wrote:
> On 02/12/2015 08:01 PM, Guido van Rossum wrote:
> > On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:
> >>
> >> 2) always use the type of self when creating new instances
> >>
> >>cons:
> >> - if constructor signatures cha
I vote for the C implementation.
On Fri, Feb 13, 2015 at 2:07 AM, Victor Stinner
wrote:
> Hi,
>
> TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
> faster than os.listdir() when the file type is checked?
>
> I accepted the PEP 471 (os.scandir) a few months ago, but it is not
>
Can we at least make it use the constructor (if there's a custom one)?
Seems like a reasonable compromise to me (let whoever implements a custom
__new__ deal with argument variance).
Eg, make it use a __new__ like this:
>>> class FancyInt(int):
... def __new__(self, value):
... return
ACTIVITY SUMMARY (2015-02-06 - 2015-02-13)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4790 (+25)
closed 30430 (+32)
total 35220 (+57)
Open issues wit
On Thu, Feb 12, 2015 at 11:01 PM, Guido van Rossum wrote:
>
>> 2) always use the type of self when creating new instances
>> ..
>>cons:
>> - if constructor signatures change, must override all methods which
>>create new objects
>>
>
> Con for #2 is a showstopper. Forget about
On 02/13/2015 01:57 AM, Paul Moore wrote:
> 2. It would be a nice, although extremely obscure, feature to be able
> to allow people who want to keep Python off their path to set
> VIRTUAL_ENV but *not* set PATH, so that py.exe does the right thing
> but there's *still* no python.exe on PATH. Limit
On 02/13/2015 02:07 AM, Victor Stinner wrote:
> Hi,
>
> TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
> faster than os.listdir() when the file type is checked?
+1 for the all-C version.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
> Since there are many ways to split this huge file, I agree that it's
> just fine to add these 800 lines and *then* think how the huge file
> can be splitted. It's a different topic.
That's a good idea. Consider adding the new feature (scandir) and the
larger issue of refactoring posixmodule as s
On 13 February 2015 at 14:27, Steve Dower wrote:
> If py.exe starts defaulting to whatever is on PATH then I don't see the
> point of it. Knowing that you'll get the latest 2.x version by default is
> quite handy (I'd be quite okay changing that to 3.x, though it is specified
> in the original PEP
If I may humbly chime in this, with a hint...
On 13.02.2015 05:01, Guido van Rossum wrote:
> On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:
>> [snip]
>> 2) always use the type of self when creating new instances
>>
>>pros:
>> - subclasses automatically maintain type
>> - much
2015-02-13 15:36 GMT+01:00 Steve Dower :
> I think posixmodule is a great candidate for splitting up by platform rather
> than function, as the whole file is packed with ifdef. It's really only
> lacking a volunteer to do it, but we could start here (ie. make
> posixmodule_nt.c for the Windows impl
Launching non-Python scripts from py.exe is not going to work as well as you
may hope. There will be numerous subtle bugs due to the cmd->py.exe->cmd
wrapping (Powershell users would have seen this with some console apps or batch
files). I think having a global command to add a particular Python
I think posixmodule is a great candidate for splitting up by platform rather
than function, as the whole file is packed with ifdef. It's really only lacking
a volunteer to do it, but we could start here (ie. make posixmodule_nt.c for
the Windows impl, etc.) and progressively move function implem
On Fri, 13 Feb 2015 08:35:00 -0500
Ben Hoyt wrote:
>
> If we go ahead with the all C approach, I'd be in favour of
> refactoring a little and putting the new scandir code into a separate
> C file. There are two ways to do this: a) sticking with a single
> Python module and just referencing the no
> TL;DR: on POSIX, is it useful to know the inode number (st_ino)
> without the device number (st_dev)?
I can't answer this question (not being a Linux dev and not knowing
much about this), but I'm +1 for adding DirEntry.inode().
On Windows, we're exposing all the information FindFirst/FindNext g
> > * C implementation: scandir is at least 3.5x faster than listdir, up
> > to 44.6x faster on Windows
> > * C+Python implementation: scandir is not really faster than listdir,
> > between 1.3x and 1.4x faster
>
> So amusingly, the bottleneck is not so much the cost of system calls,
> but the cost
On Fri, 13 Feb 2015 11:07:03 +0100
Victor Stinner wrote:
>
> * C implementation: scandir is at least 3.5x faster than listdir, up
> to 44.6x faster on Windows
> * C+Python implementation: scandir is not really faster than listdir,
> between 1.3x and 1.4x faster
So amusingly, the bottleneck is no
On Fri, 13 Feb 2015 13:27:04 +0200
Serhiy Storchaka wrote:
> On 13.02.15 12:07, Victor Stinner wrote:
> > * C implementation: scandir is at least 3.5x faster than listdir, up
> > to 44.6x faster on Windows
>
> Results on Windows was obtained in the becnhmark that doesn't drop disk
> caches and
2015-02-13 11:52 GMT+01:00 Serhiy Storchaka :
> You can try to make Python implementation faster if
>
> 1) Don't set attributes to None in constructor.
The class uses __slots__. Setting attributes in the class body is
forbidden when __slots__ is used.
> 3) Or pass DirEntry to _scandir:
>
> def sc
On 13 February 2015 at 20:33, Victor Stinner wrote:
> 2015-02-13 11:19 GMT+01:00 Paul Moore :
>> On 13 February 2015 at 10:07, Victor Stinner
>> wrote:
>>> => IMO the best option is to take the C implementation. What do you think?
>>
>> FWIW (as I'm not a core dev) I agree. The Windows speedup i
2015-02-13 12:27 GMT+01:00 Serhiy Storchaka :
> On 13.02.15 12:07, Victor Stinner wrote:
>>
>> * C implementation: scandir is at least 3.5x faster than listdir, up
>> to 44.6x faster on Windows
>
>
> Results on Windows was obtained in the becnhmark that doesn't drop disk
> caches and runs listdir b
On 13.02.15 12:07, Victor Stinner wrote:
* C implementation: scandir is at least 3.5x faster than listdir, up
to 44.6x faster on Windows
Results on Windows was obtained in the becnhmark that doesn't drop disk
caches and runs listdir before scandir.
___
On 13 February 2015 at 10:15, Glenn Linderman wrote:
> Maybe restricting it to running ".py" files or ".exe" files would be
> reasonable. That covers entry points (which should be the norm for
> newer projects) and Python scripts (which are the most likely things
> to be portable).
>
> The WINDOWS
On 13.02.15 12:07, Victor Stinner wrote:
TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
faster than os.listdir() when the file type is checked?
You can try to make Python implementation faster if
1) Don't set attributes to None in constructor.
2) Implement scandir as:
def
2015-02-13 11:19 GMT+01:00 Paul Moore :
> On 13 February 2015 at 10:07, Victor Stinner wrote:
>> => IMO the best option is to take the C implementation. What do you think?
>
> FWIW (as I'm not a core dev) I agree. The Windows speedup is huge, and
> well worth adding the code. I'm assuming that the
On 2/13/2015 1:13 AM, Paul Moore wrote:
On 13 February 2015 at 06:59, Thomas Heller wrote:
To make it clear: My suggestion is (or was, maybe it isn't a good idea)
to have some way to start 'something' that is in the Scripts
directory of a Python installation (which is usually a python script
or
On 13 February 2015 at 10:07, Victor Stinner wrote:
> => IMO the best option is to take the C implementation. What do you think?
FWIW (as I'm not a core dev) I agree. The Windows speedup is huge, and
well worth adding the code. I'm assuming that the majority of the C
code is cross-platform, so we
Hi,
TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
faster than os.listdir() when the file type is checked?
I accepted the PEP 471 (os.scandir) a few months ago, but it is not
implement yet in Python 3.5, because I didn't make a choice on the
implementation.
Ben Hoyt wrote diff
With Python's cooperative inheritance, I think you want to do everything
through one constructor sending keyword arguments up the chain. The
keyword arguments are popped off as needed. With this setup I don't think
you need "overloaded constructors".
Best,
Neil
On Fri, Feb 13, 2015 at 4:44 AM,
On 13 February 2015 at 09:47, Vinay Sajip wrote:
> I just thought of something ... as far as I know, we've enabled searching for
> a command on the path - since when a venv is active in the sense of
> VIRTUAL_ENV being defined, PATH is also set up so that the venv's Scripts
> folder is on it -
- Original Message -
From: Paul Moore
> I'd also appreciate your views on the spin-off thread and PEP 486
> ("Make the Python Launcher aware of virtual environments").
I just thought of something ... as far as I know, we've enabled searching for a
command on the path - since when a v
Hi,
TL;DR: on POSIX, is it useful to know the inode number (st_ino)
without the device number (st_dev)?
While reading feedback on the Python 3.5 alpha 1 release, I saw a
comment saying that the current design of os.scandir() (PEP 471)
doesn't fit a very specific usecase where the inode number is
If I may humbly chime in this, with a hint...
On 13.02.2015 05:01, Guido van Rossum wrote:
> On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:
>> [snip]
>> 2) always use the type of self when creating new instances
>>
>>pros:
>> - subclasses automatically maintain type
>> - much
On 13 February 2015 at 07:25, Nick Coghlan wrote:
> PEP 441 was aimed at giving the feature more visibility, in addition
> to making appropriately designed archives easier to create (IIRC, my
> main request for that PEP was to change the proposed module name to
> the more prosaic, but also more se
On 13 February 2015 at 06:59, Thomas Heller wrote:
> To make it clear: My suggestion is (or was, maybe it isn't a good idea)
> to have some way to start 'something' that is in the Scripts
> directory of a Python installation (which is usually a python script
> or an exe-wrapper for it), without ty
On 13 February 2015 at 00:15, Vinay Sajip wrote:
> I remembered that I added a feature (with the help of Pawel Jasinski) to
> allow e.g. py -ipy to pick
> a command 'ipy' configured in the .ini file (this is used to launch
> IronPython, but it could be used
> for other things too).
At the time
69 matches
Mail list logo
