Re: [Python-Dev] Python 2.7.7. on Windows
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 change in a bugfix release. Normally I would completely agree. 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! An unknown portion of Python 2.x users will never upgrade to 3. Do we continue on this path in good conscience for at least six more years? -Mike ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 bothered at its inclusion in the path. -Mike On 04/29/2014 06:31 PM, anatoly techtonik wrote: You don't take into account many tutorials and internal docs that make the job of new users easier by using this default. Human processes will be broken, newbies will suffer. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 governed essentially by CPython implementation > details and not some language-level semantics like metaclasses (I > mentioned them because error message in Python2 did so, though Python3 > doesn't refer to metaclasses). > > An example would really help me to get a feel of the issue, but I > assume lack of them means that there's no well-known idiom where such > inheritance is used, and that's good enough on its own. I also tried to > figure how it's important to support such multi-base cases, so the code > I write didn't require complete rewrite if it hits one day, but > everything seems to turn out to be pretty extensible. > >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 are special, in that the type structure contains their offsets, which makes them relocatable in subclasses. But any other __slots__ aren't relocatable in subclasses, because the type structure doesn't directly keep track of the offsets. (The slot descriptors do.) But I don't think there's anything in principle that requires this, it's just the implementation. You could in theory relocate __slots__ defined from Python code in order to make a merged subclass. It's just that the effective "__slots__" of C code can't be moved, because C code is expecting to find them at specific offsets. Therefore, if two types define their own struct fields, they can't be inherited from unless one is a subtype of the other. In the C code (again if I recall correctly), this is done using the __base__ attribute of the type, which indicates what struct layout the object will use. A type can have a larger struct than its base type, adding its own fields after the base type's struct fields. (The dict and weakref fields are added -- if they are added -- *after* the base struct fields. If your __base__ already has them, those offsets within the existing layout are used, which is why them being in another base class's __slots__ isn't a problem.) When you create a new type, CPython looks at your bases to find a suitable __base__. If two of your bases inherit from each other, the ancestor can be ignored, keeping the more-derived one as a candidate __base__. If a base adds only __dict__ and/or __weakref__ (or neither) to its __base__, then its __base__ is a candidate (not recursively, though). If at the end there is more than one base left standing, then it's an error, since you have bases with incompatible layouts. That is not a precise description of the algorithm, but that's the gist of how it works. __base__ is a slot on the type object and is tracked at the C level in order to sort out layouts like this. ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 changes than normal in this release, and people are expecting security fixes. This is realistically the last chance to fix this vulnerability in 2.X. We should help people do the right thing and be safe, while keeping the possibility to customize. Yes, I can imagine a few people in the world unhappy with any change, but a large majority of "millions" will not notice and reap the benefits. There are also quite a few people unhappy the change hasn't been made (see the bug). However, those that want a less safe setting on brand new installs may still change it manually, script it with the command-line parameter, or could stay with 2.7.6 until they do. The porting effort is tiny and would effect few compared to those who'd benefit. -Mike p.s. I'm available to help with maintaining the 2.7 installer, unfortunately I've only used Inno so not sure how long it would take me to ramp up. On 04/29/2014 12:04 PM, Steve Dower wrote: ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 installer default, a setting that would still be changeable > as it always has, that by definition only will affect brand new installs. You don't take into account many tutorials and internal docs that make the job of new users easier by using this default. Human processes will be broken, newbies will suffer. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 >> take quite some time be sure I understand all aspects of it. Thanks for >> confirming that it's governed essentially by CPython implementation >> details and not some language-level semantics like metaclasses (I >> mentioned them because error message in Python2 did so, though Python3 >> doesn't refer to metaclasses). >> >> An example would really help me to get a feel of the issue, but I >> assume lack of them means that there's no well-known idiom where such >> inheritance is used, and that's good enough on its own. I also tried to >> figure how it's important to support such multi-base cases, so the code >> I write didn't require complete rewrite if it hits one day, but >> everything seems to turn out to be pretty extensible. >> > > 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 are special, in that the type structure contains their offsets, which > makes them relocatable in subclasses. But any other __slots__ aren't > relocatable in subclasses, because the type structure doesn't directly keep > track of the offsets. (The slot descriptors do.) > > But I don't think there's anything in principle that requires this, it's > just the implementation. You could in theory relocate __slots__ defined > from Python code in order to make a merged subclass. It's just that the > effective "__slots__" of C code can't be moved, because C code is expecting > to find them at specific offsets. Therefore, if two types define their own > struct fields, they can't be inherited from unless one is a subtype of the > other. > > In the C code (again if I recall correctly), this is done using the > __base__ attribute of the type, which indicates what struct layout the > object will use. A type can have a larger struct than its base type, > adding its own fields after the base type's struct fields. (The dict and > weakref fields are added -- if they are added -- *after* the base struct > fields. If your __base__ already has them, those offsets within the > existing layout are used, which is why them being in another base class's > __slots__ isn't a problem.) > > When you create a new type, CPython looks at your bases to find a suitable > __base__. If two of your bases inherit from each other, the ancestor can > be ignored, keeping the more-derived one as a candidate __base__. If a > base adds only __dict__ and/or __weakref__ (or neither) to its __base__, > then its __base__ is a candidate (not recursively, though). If at the end > there is more than one base left standing, then it's an error, since you > have bases with incompatible layouts. > > That is not a precise description of the algorithm, but that's the gist of > how it works. __base__ is a slot on the type object and is tracked at the > C level in order to sort out layouts like this. > > ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 environments, or contribute docs to python.org, or just go ahead and make your own secure installer (seriously - there are enterprises/IT departments that will prefer a "secure by default" version rather than having to secure it themselves). A change that will break many existing users is a huge minus. Even putting this into 3.5 would worry me unless there is a *much* higher-than-usual usage of the prereleases. Here are some more minuses beyond those listed on the issue: * Longer install time (due to having to compile the stdlib to pyc and pyo eagerly) * Larger installed size (same reason) * Incompatibility with existing non-elevating package installers (every bdist_wininst is in this category, I believe) * Incompatibility with tools that don't recognize user site-packages Incidentally, forcing normal users to elevate to install packages is a bigger security risk than we currently have, since installers (or setup.py's) do not run elevated. Once everyone "knows" that you need to elevate for this (and trust me, people already expect it), *any* package could become the delivery mechanism for malicious code that will be run with admin privileges - no exploits, just social engineering. Right now, we are actually more secure for the vast majority of single-user environments, since people aren't expecting a UAC prompt and will view it with suspicion. > 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 (App Paths are - http://msdn.microsoft.com/en-US/ee872121.aspx), and your entire argument in support of using Program Files is that it is Microsoft's recommendation. It's only a minor inconsistency, but be aware that you are weakening your own argument here :) "Heard about ProgramFiles" and "inclusion in the path" are two very different ideas. My grandmother knows about Program Files (though the "x86" still confuses her), but doesn't know anything about PATH. If someone installed Python for her and her "trick" of typing "news.txt" into the Run dialog* suddenly broke, I'm sure she would be unhappy. (*She has no such trick, to my knowledge, but this is one of the side-effects of modifying PATH.) Or if someone dropped a "sol.py" ahead of sol.exe (the user profile directory will work, provided the file is not in App Paths) and the PATHEXT change caused the Python file to be run instead of the EXE. The unintended consequences are significant, which is why I argue that python.org Python should not be installed on my grandmother's computer - there is a difference between the Python development environment and the runtime environment. My basic argument is not that you are wrong, but that it is too late to change. If we were starting from scratch right now, the reference installers from python.org would absolutely install Python into Program Files. But it is far too late to change it for 2.7.x, and it would require a serious education campaign for 3.5 to make sure as many users as possible are not burned. Now is the time to start publicly making a noise about the risks of the current installer and how to mitigate them (the second part is important - otherwise you are just making noise). Cheers, Steve ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 senior committers, which suggests you're going to need to come up with a stronger argument. Maybe there's a relevant CVE? ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 the deafening silence from the senior committers, which suggests you're going to need to come up with a stronger argument. Maybe there's a relevant CVE? *My* silence is easy to explain: I don't maintain Python 2.7 any longer. So my view doesn't really matter (although I do support Steve's position). In any case, I think Mike is following a lost cause. If the maintainer in charge (i.e. Steve) doesn't want to make a specific change, the only way to force him would be from "higher up", which could be the release manager, the BDFL, or a PEP. Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API and process questions (sparked by Claudiu Popa on 16104
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. ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 distributes Py) have been installing Python to ProgramFiles for almost a decade, and can assure that none of those things you mention have yet happened. Also, your security point contradicts industry best practice. Mac and Linux require sudo to install system packages, with user packages and venv as alternatives. My basic argument is not that you are wrong, but that it is too late to change. That's a fine argument. The problem is that we and others like us are not able to move to Py3 (for work) and won't be able to for a long-enough time that it could be considered to be "never". -Mike ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 assure that none of those things you mention have yet > happened. Relax, I don't think Steve is making things up. That said, I can confirm what you wrote: I've always installed Python to "Program Files" and I've never had any issues (then again, I'm mostly using Linux). Stefan Krah ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 meant the install path in that sentence, not the environment var. -Mike ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 are special, in that the type structure contains
> their offsets, which makes them relocatable in subclasses. But any
> other __slots__ aren't relocatable in subclasses, because the type
> structure doesn't directly keep track of the offsets. (The slot
> descriptors do.)
>
> But I don't think there's anything in principle that requires this,
> it's just the implementation. You could in theory relocate __slots__
> defined from Python code in order to make a merged subclass. It's
Ok, so one can gather from this that __slot__'ed class can't be used as
multiple bases, as in this example:
class B1:
__slots__ = ('a', 'b')
class B2:
__slots__ = ('a', 'b', 'c')
class C(B2, B1):
pass
> just that the effective "__slots__" of C code can't be moved, because
> C code is expecting to find them at specific offsets. Therefore, if
> two types define their own struct fields, they can't be inherited
> from unless one is a subtype of the other.
Well, here it itches to ask if C++-like offsetting of subclass to base
class "this" pointer was considered, but I already feel like a child
asking all those stupid questions. One obvious answer would be that
there's little point to complicate the matter, as it's just emulation
of inheritance via enclosing, and explicit enclosing offers more
flexibility anyway (but then it's less efficient).
[]
> That is not a precise description of the algorithm, but that's the
> gist of how it works. __base__ is a slot on the type object and is
> tracked at the C level in order to sort out layouts like this.
Thanks much for the detailed description, will serve as a good
reference when in MicroPython we'll hit actual case when CPython
accepts some inheritance patterns and uPy doesn't.
--
Best regards,
Paul mailto:[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 understand. If as a Python programmer you want a
more general multiple inheritance, you just shouldn't use slots. As a C
programmer writing extension modules, the single-inheritance model (which
this effectively is, at that level) is much easier to deal with.
On Tue, Apr 29, 2014 at 6:03 PM, Paul Sokolovsky wrote:
> 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 are special, in that the type structure contains
> > their offsets, which makes them relocatable in subclasses. But any
> > other __slots__ aren't relocatable in subclasses, because the type
> > structure doesn't directly keep track of the offsets. (The slot
> > descriptors do.)
> >
> > But I don't think there's anything in principle that requires this,
> > it's just the implementation. You could in theory relocate __slots__
> > defined from Python code in order to make a merged subclass. It's
>
> Ok, so one can gather from this that __slot__'ed class can't be used as
> multiple bases, as in this example:
>
> class B1:
> __slots__ = ('a', 'b')
>
> class B2:
> __slots__ = ('a', 'b', 'c')
>
> class C(B2, B1):
> pass
>
> > just that the effective "__slots__" of C code can't be moved, because
> > C code is expecting to find them at specific offsets. Therefore, if
> > two types define their own struct fields, they can't be inherited
> > from unless one is a subtype of the other.
>
> Well, here it itches to ask if C++-like offsetting of subclass to base
> class "this" pointer was considered, but I already feel like a child
> asking all those stupid questions. One obvious answer would be that
> there's little point to complicate the matter, as it's just emulation
> of inheritance via enclosing, and explicit enclosing offers more
> flexibility anyway (but then it's less efficient).
>
> []
>
> > That is not a precise description of the algorithm, but that's the
> > gist of how it works. __base__ is a slot on the type object and is
> > tracked at the C level in order to sort out layouts like this.
>
> Thanks much for the detailed description, will serve as a good
> reference when in MicroPython we'll hit actual case when CPython
> accepts some inheritance patterns and uPy doesn't.
>
>
> --
> Best regards,
> Paul mailto:[email protected]
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Aborting unit tests on first failure
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_zipfile.TestsWithMultipleOpens) ... ok | test_interleaved (test.test_zipfile.TestsWithMultipleOpens) ... ok | test_same_file (test.test_zipfile.TestsWithMultipleOpens) ... ok | | -- | Ran 163 tests in 14.522s | | OK (skipped=25) | 368 tests OK. | 2 tests failed: | test_decimal test_itertools | 1 test altered the execution environment: | test___all__ | 17 tests skipped: | test_bz2 test_curses test_dbm_gnu test_devpoll test_idle | test_kqueue test_msilib test_ossaudiodev test_readline | test_startfile test_tcl test_tk test_ttk_guionly test_ttk_textonly | test_winreg test_winsound test_zipfile64 ` I thought the -G option is would cause the test to stop as soon as an error occured: | -G, --failfastfail as soon as a test fails (only with -v or -W) But it my case it seems that it actually continued to run all the other test modules. Did I misunderstand what -G is supposed to do, or is this a bug in the test runner? It seems to work fine within a single test module, i.e. if I run | ./python -m test -u network,urlfetch -j 8 -G -v test_decimal ..then execution stops right after the failed test. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aborting unit tests on first failure
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 per-process basis. When running with -j, each test (test case?) is run in a separate process. Unless the processes are sharing some state (which I didn't see), any existing processes will run to completion. Furthermore, I don't know if the "pending" tests are cleared out under "failfast", but it doesn't look like it. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [issue6839] zipfile can't extract file
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue6839] zipfile can't extract file
Hi Adam, Gentlemen, > Thanks for contributing to Python! But not everyone on this list is a guy. Regards, -Jessica ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue6839] zipfile can't extract file
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 gentlemen" is just too old-fashioned and formal. "Folks" is nicely informal and all-inclusive, regardless of sex or class we're all just folks. -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 assistance that was easier for C > programmers to use and understand. If as a Python programmer you want a more > general multiple inheritance, you just shouldn't use slots. As a C > programmer writing extension modules, the single-inheritance model (which > this effectively is, at that level) is much easier to deal with. Also related to the "single inheritance is easier to deal with when writing C extensions" aspect, C extension code is also far more likely than Python code to call the base class method implementations directly - getting hold of super() objects from C to do cooperative multiple inheritance isn't straightforward (I actually don't know how to do it myself - I'd have to go trawling through the C API docs to figure it out). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 2.7.7. on Windows
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 Python to ProgramFiles for almost a decade, >> and can assure that none of those things you mention have yet >> happened. > > Relax, I don't think Steve is making things up. That said, I can confirm > what you wrote: I've always installed Python to "Program Files" and I've > never had any issues (then again, I'm mostly using Linux). It's important to note that the feature backport exceptions in the network security enhancements PEP were granted specifically because they had security implications *beyond* the specific systems and applications still running Python 2.7. Unfortunately, I lost some of that rationale when I trimmed it down to the more specific proposal: == The key requirement for a feature to be considered for inclusion in this policy is that it must have security implications *beyond* the specific application that is written in Python and the system that application is running on. Thus the focus on network security protocols, password storage and related cryptographic infrastructure - Python is a popular choice for the development of web services and clients, and thus the capabilities of widely used Python versions have implications for the security design of other services that may themselves be using newer versions of Python or other development languages, but need to interoperate with clients or servers written using older versions of Python. The intent behind this requirement is to minimise any impact that the introduction of this policy may have on the stability and compatibility of maintenance releases. It would be thoroughly counterproductive if end users became as cautious about updating to new Python 2.7 maintenance releases as they are about updating to new feature releases within the same release series. == I'll find a place to add that back in (not tonight, though), since it's an important part of the reason Mike's suggested installer changes are *not* remotely in scope for 2.7.7. However, that's currently not obvious to folks that have only read the final version of the PEP, and didn't see the earlier more open ended versions that included that text. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue6839] zipfile can't extract file
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" could be used to address mixed-gender groups (I'm pretty sure I've heard some "ladies" use it in this setting), but I'm not a native speaker. The idea being that one should not infer too much from a salutation from someone who might not be a native speaker (some languages default to masculine for a mixed audience), although in this case "Ladies and gentlemen" is really famous. In any case, I'm sure he'd like to have his code reviewed by someone, regardless of its gender! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?
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 that it wasn't considered worth the effort, if it was considered at all. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
