On 15 November 2017 at 16:13, Steve Barnes wrote:
> - "pip -X[.Y][-32|-64] operation ..." tries to find a python matching
> -X[.Y][-32|-64] and if it succeeds executes "python -m pip operation
> ..." with that python, (if it doesn't find a matching python is should
> fail with a sensible error
On Wed, Nov 15, 2017 at 8:44 AM, Nick Coghlan wrote:
>
> I like the idea in principle, but highlighting a particular backwards
> compatibility pain point: one of the complications in importlib is that we
> promise to keep the "sys.modules[__name__] = some_other_object" idiom
> working. That means
On 15 November 2017 at 08:22, Nick Coghlan wrote:
> On 15 November 2017 at 16:13, Steve Barnes wrote:
>>
>> - "pip -X[.Y][-32|-64] operation ..." tries to find a python matching
>> -X[.Y][-32|-64] and if it succeeds executes "python -m pip operation
>> ..." with that python, (if it doesn't find
On 14 November 2017 at 10:27, Brett Cannon wrote:
>
> On Mon, Nov 13, 2017, 15:55 Steven D'Aprano, wrote:
>
>> On Mon, Nov 13, 2017 at 06:37:05PM -0500, Barry Warsaw wrote:
>> > Brett Cannon wrote:
>> >
>> > > And possibly the easiest way to reach them is on the pyqa-dev mailing
>> list.
>> >
>>
14.11.17 22:34, Neil Schemenauer пише:
This is an idea I have been playing with and seems to hold some
promise. I think we should use a module instance as the standard
global namespace rather than directly using its dict. I have a
prototype version of CPython that does this, not working 100% ye
On 15 November 2017 at 19:51, Paul Moore wrote:
> On 15 November 2017 at 08:22, Nick Coghlan wrote:
> > On 15 November 2017 at 16:13, Steve Barnes
> wrote:
> >>
> >> - "pip -X[.Y][-32|-64] operation ..." tries to find a python matching
> >> -X[.Y][-32|-64] and if it succeeds executes "python
Here are some thoughts––maybe even a proposal––for type-related
terminology, because clear terminology makes discussion and reasoning
easier, and helps avoid errors.
(And related to the PEP 560 thread, the question of what should go into
class attributes like __bases__).
Terminology regarding typ
On Tue, Nov 14, 2017 at 4:49 AM, Nick Coghlan wrote:
> On 14 November 2017 at 09:41, Guido van Rossum wrote:
> >
> > Thanks, I am happy now with the PEP, except for one detail: maybe
> > `__mro_entry__` should always return a tuple and then maybe renamed to
> > `__mro_entries__`. (See debate at
On Nov 12, 2017 14:21, "Paul Moore" wrote:
[]
> Virtualenvs are a hard tool to use for beginners.
Agreed. Genuine beginners just install Python, then use it. If they
install extra packages, they want them to be available to all of their
scripts.
Agreed.
>From personal experience, I do
Le 13/11/2017 à 19:57, Chris Barker a écrit :
> This has gotten to be a big thread, and it's a pretty intractable
> problem, but I think there are a few fairly small things that could be
> done to at least make it a bit easier:
>
> 1) Add python2.exe and python3.exe files to the Windows installers
On 15 November 2017 at 22:46, Michel Desmoulin
wrote:
> Le 13/11/2017 à 19:57, Chris Barker a écrit :
> > 3) Make --user be be automatic for pip install. Not actually the
> > default, but pip could do a user install if you don't have the
> > permissions for a non-user install.
>
> Breaking compat
On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven wrote:
[..]
> What do we call such a "type"? Maybe we have both "concrete" and "strictly
> concrete" types. Perhaps we also have both "abstract" and "strictly
> abstract" types. An ABC with some concrete default implementations might
> then be both
On 2017-11-15, Koos Zevenhoven wrote:
> Another point, perhaps more difficult to address: Would for instance
> globals() then return a module instead of a dict/mapping?
For compatibility, it would definitely have to return a dict. As a
result, calling globals() would cause the "fast globals" fla
At some point it was proposed to distinguish two things: types (static) and
classes (runtime).
I don't think we need more fine grained terminology here.
--
Ivan
On 15 November 2017 at 17:54, Koos Zevenhoven wrote:
> On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven
> wrote:
> [..]
>
>> What d
On 15Nov2017 0617, Nick Coghlan wrote:
On 15 November 2017 at 22:46, Michel Desmoulin
mailto:[email protected]>> wrote:
Should I do a PEP with a summary of all the stuff we discussed ?
I think a Windows-specific PEP covering adding PATH updates back to the
default installer behaviou
On Wed, Nov 15, 2017 at 1:07 PM, Steve Dower wrote:
> My preferred solution for this is to rename "py.exe" to "python.exe" (or
> rather, make a copy of it with the new name), and extend (or more likely,
> rewrite) the launcher such that:
>
> * if argv[0] == "py.exe", use PEP 514 company/tag resolu
On 15 November 2017 at 19:29, Zachary Ware wrote:
> On Wed, Nov 15, 2017 at 1:07 PM, Steve Dower wrote:
>> My preferred solution for this is to rename "py.exe" to "python.exe" (or
>> rather, make a copy of it with the new name), and extend (or more likely,
>> rewrite) the launcher such that:
>>
>
Hi,
I've been lurking for quite a time and just wanted to let you know I'm
out here.
Thanks for making Python the best!
Robert Kaplan
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code
Sometimes I get MRO failures when defining classes. For example, if
R < E, C
B < S, E
S < C
Z < B, R
Then Z cannot be instantiated because C precedes E in B and E precedes C in
R. The problem is that when the inheritance graph was topologically-sorted
in B, the order was S, C, E. It could ju
On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar
wrote:
> Sometimes I get MRO failures when defining classes. For example, if
>
> R < E, C
> B < S, E
> S < C
> Z < B, R
>
> Then Z cannot be instantiated because C precedes E in B and E precedes C
> in R. The problem is that when the inheritance gr
On Wed, Nov 15, 2017 at 8:41 PM, Ivan Levkivskyi
wrote:
>
> At some point it was proposed to distinguish two things: types (static)
> and classes (runtime).
> I don't think we need more fine grained terminology here.
>
>
Yeah, well I was trying to wrap my head around this runtime vs static
th
On Wed, Nov 15, 2017 at 01:49:03PM -0800, Neil Girdhar wrote:
> Sometimes I get MRO failures when defining classes. For example, if
>
> R < E, C
> B < S, E
> S < C
> Z < B, R
>
> Then Z cannot be instantiated because C precedes E in B and E precedes C in
> R. The problem is that when the inher
On Wednesday, November 15, 2017 at 5:32:00 PM UTC-5, Koos Zevenhoven wrote:
>
> On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar > wrote:
>
>> Sometimes I get MRO failures when defining classes. For example, if
>>
>> R < E, C
>> B < S, E
>> S < C
>> Z < B, R
>>
>> Then Z cannot be instantiated be
Steven D'Aprano wrote:
These are not equivalent:
B < S, E
B < E, S
Not in general, but in many cases they will be, e.g. if
E and S have no method names in common. I think the OP is
implying that his case is one of those.
Maybe what's really wanted is a way to say "B inherits from
S and E, but
On 16 November 2017 at 05:29, Zachary Ware
wrote:
> On Wed, Nov 15, 2017 at 1:07 PM, Steve Dower
> wrote:
> > My preferred solution for this is to rename "py.exe" to "python.exe" (or
> > rather, make a copy of it with the new name), and extend (or more likely,
> > rewrite) the launcher such that
25 matches
Mail list logo
