Paul Sokolovsky wrote:
Well, here it itches to ask if C++-like offsetting of subclass to base
class "this" pointer was considered,
I suppose in theory it would be possible to build a new
set of __slot__ descriptors for the subclass. It mightn't
even be all that difficult. My guess would be tha
2014-04-30 3:58 GMT+01:00 Steven D'Aprano :
> On Tue, Apr 29, 2014 at 07:48:00PM -0700, Jessica McKellar wrote:
>> Hi Adam,
>>
>> Gentlemen,
>> >
>>
>> Thanks for contributing to Python! But not everyone on this list is a guy.
>
> And not all of the guys are gentlemen :-)
And I thought "guys" coul
On 29 April 2014 17:02, Stefan Krah wrote:
> Mike Miller wrote:
>> I have to say I'm a bit baffled. I expected disagreement, but
>> didn't expect that multiple reasons against would be made up
>> seemingly at random? I and a company I work for (that distributes
>> Py) have been installing Pytho
On 29 April 2014 21:38, Guido van Rossum wrote:
> When I redesigned and reimplemented this part of Python inheritance
> (somewhere in the 2.1 - 2.3 time frame, I forget the exact timing) I was
> well aware of the C++ approach and decided against it, preferring an
> approach requiring less compiler
On Tue, Apr 29, 2014 at 07:48:00PM -0700, Jessica McKellar wrote:
> Hi Adam,
>
> Gentlemen,
> >
>
> Thanks for contributing to Python! But not everyone on this list is a guy.
And not all of the guys are gentlemen :-)
The term I sometimes use is "gentlefolks", or even just "folks". "Ladies
and
Hi Adam,
Gentlemen,
>
Thanks for contributing to Python! But not everyone on this list is a guy.
Regards,
-Jessica
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.o
Gentlemen,
I'd like to politely ask for a second pair of eyes on [issue6839]. It's
been dragging for a very long time, and the fix is really a change from a
raise() to a debugging print.
Thanks in advance,
Adam Polkosnik
___
Python-Dev mailing list
Pyth
On Tue, Apr 29, 2014 at 8:02 PM, Nikolaus Rath wrote:
>
> Hello,
>
> I've just run the testsuite of hg tip with
>
> ./python -m test -u network,urlfetch -j 8 -G -v
"failfast" (from -G) is passed directly to unittest.TextTestRunner
(see test/support/__init__.py:_run_suite()). However, that's on a
Hello,
I've just run the testsuite of hg tip with
./python -m test -u network,urlfetch -j 8 -G -v
and it finished with
,
| [...]
| test_extract_dir (test.test_zipfile.TestWithDirectory) ... ok
| test_store_dir (test.test_zipfile.TestWithDirectory) ... ok
| test_different_file (test.test_zip
When I redesigned and reimplemented this part of Python inheritance
(somewhere in the 2.1 - 2.3 time frame, I forget the exact timing) I was
well aware of the C++ approach and decided against it, preferring an
approach requiring less compiler assistance that was easier for C
programmers to use and
Hello,
On Tue, 29 Apr 2014 10:47:26 -0400
PJ Eby wrote:
[]
>
> From memory of the last time I dealt with this, the rules were that
> you could mix two classes only if their __slots__ differed from their
> common __base__ by *at most* __dict__ and/or __weakref__. The dict
> and weakref slots ar
On 04/30/2014 04:14 AM, Steve Dower wrote:
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bothered
at its inclusion in the path.
Modifying PATH is not recommended by Microsoft...
Sorry, I mea
Mike Miller wrote:
> I have to say I'm a bit baffled. I expected disagreement, but
> didn't expect that multiple reasons against would be made up
> seemingly at random? I and a company I work for (that distributes
> Py) have been installing Python to ProgramFiles for almost a decade,
> and can a
On 04/30/2014 04:14 AM, Steve Dower wrote:
Here are some more minuses beyond those listed on the issue:
I have to say I'm a bit baffled. I expected disagreement, but didn't expect
that multiple reasons against would be made up seemingly at random? I and a
company I work for (that distribut
2014-04-28 21:24 GMT+01:00 Claudiu Popa :
> [...]
>
> If anyone agrees with the above, then I'll modify the patch. This will
> be its last iteration, any other bikeshedding
> should be addressed by the core dev who'll apply it.
I'm perfectly happy with those proposals.
Quoting "Stephen J. Turnbull" :
Mike Miller writes:
> However, this bug has been shitcanned for a decade. This is the
> last chance to fix this bug in a branch that's going to be
> supported until 2020!
Probably. I'm not convinced. But that doesn't really matter.
Your bigger concern is
Mike Miller writes:
> However, this bug has been shitcanned for a decade. This is the
> last chance to fix this bug in a branch that's going to be
> supported until 2020!
Probably. I'm not convinced. But that doesn't really matter.
Your bigger concern is the deafening silence from the seni
Mike Miller wrote:
> Every change has pluses and minuses. I can't guarantee 100% benefits, only
> trying to make the case that the benefits here outweigh them.
If this is your case about the benefits, it's a weak case. Feel free to blog
about how to secure a Python installation in multi-user envi
Thanks -- your memory is better than mine!
On Apr 29, 2014 8:16 AM, "PJ Eby" wrote:
>
>
>
> On Mon, Apr 28, 2014 at 7:26 PM, Paul Sokolovsky wrote:
>
>> Well, sure I did, as I mentioned, but as that's first time I see that
>> code (that specific piece is in typeobject.c:extra_ivars()), it would
>
On Mon, Apr 28, 2014 at 11:07 PM, Mike Miller wrote:
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>>
>> This would be an incredibly painful change that would surprise and hurt a
>> lot of
>> people.
>
>
> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
> talking about an
Hi,
Stepping back a bit...
I doubt you'd take the idea this far, but that Python should need assembly by
professionals before use doesn't match its "Batteries Included" spirit, nor the
PC revolution for that matter.
The reason I brought up the subject at 2.7.7 is because there are greater
c
On Mon, Apr 28, 2014 at 7:26 PM, Paul Sokolovsky wrote:
> Well, sure I did, as I mentioned, but as that's first time I see that
> code (that specific piece is in typeobject.c:extra_ivars()), it would
> take quite some time be sure I understand all aspects of it. Thanks for
> confirming that it's
Hi,
Every change has pluses and minuses. I can't guarantee 100% benefits, only
trying to make the case that the benefits here outweigh them.
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bot
On 04/29/2014 03:07 PM, Stephen J. Turnbull wrote:
> I have no objection *at all* to making the change in the next feature
> release. I think the "good citizenship" argument is more than
> sufficient, ...
> I'm questioning whether it is a sufficient reason to make a backwards-
> incompatible cha
24 matches
Mail list logo
