rg/3/library/inspect.html#introspecting-callables-with-the-signature-object
The funcsigs project provides a backport of much of that functionality
to earlier Python versions: https://pypi.python.org/pypi/funcsigs
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
em out can lead to
> actual bugs.
>
> Anyone object if I update PEP 7 to remove the optionality of curly braces in
> PEP 7?
+1 from me, as I usually add them to code I'm editing anyway (I find
it too hard to read otherwise, especially when there's a long series
of them).
Cheers,
Error: not a chance
So if we bring *Python* into the comparison, we can see it splits the
difference between the two C variants by omitting the closing brace
and replacing the opening brace with ":":
x = do_something()
if (x != 10):
return None
do_some_more()
The additional &quo
equirement, so I've never explicitly checked CLA status for folks
contributing packaging related PEPs. (And looking at the
just-checked-in PEP 513, I apparently have a CLA to chase up...)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
ccept it - that maintenance branch is dead, which is what
the "End of Life" refers to.
Folks are still free to run it (all past Python releases remain
online, all the way back to 1.1), and downstreams may still offer
support for it, but that's their call.
Cheers,
Nick.
--
Nick
rt of the PEP.
(In looking into this, I found several of the docstrings in
platform.py still referred to Subversion, even though the
platform._sys_version() helping had been updated to handle Mercurial)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
$ ./python
Python 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00)
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._mercurial
('CPython&
em.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/arc
On 25 January 2016 at 03:40, francismb wrote:
> On 01/24/2016 01:17 PM, Nick Coghlan wrote:
>> Linux distros tend to build Python from a tarball rather than a source
>> checkout, for example, which means the build directory doesn't include
>> any VCS details:
>
g on
something else (such as the function specialisation infrastructure
underpinning Victor's optimiser project).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https
ing more
of their time on finding and assembling code other people have
*already written* into solutions to interesting problems. *That's* the
kind of improvement that turns enormously complex problems like facial
recognition into 25 line Python scripts:
https://realpython.com/blog/python/face
On 28 January 2016 at 04:40, Sven R. Kunze wrote:
> On 27.01.2016 12:16, Nick Coghlan wrote:
>> Umm, no, that's not how this works
> That's exactly how it works, Nick.
>
> INADA uses Python as I use crossroads each day. Daily human business.
>
> If you read hi
s on some of the simplified micro-benchmarks
popular in programming language shootouts.
There's no way you could have anticipated the subsequent tangential
discussion on motives for contributing to open source projects, and
the impact that has on what we can reasonably expect from fellow
contri
ebacks though, so
it's potentially worth exploring that option further.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
ey just want to *read* the source code, then leaving out
"--details" prints the full module source, and would work even if the
standard library were in a zip archive)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
eant that PyPy could still at least partially JIT the
Python code running on the CPython side of the boundary.
Cheers,
Nick.
[1] https://github.com/rguillebert/pymetabiosis
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
he current dictnotes.txt, listsort.txt, etc would cover the
essentials.
If someone else wanted to also describe the change in a PEP for ease
of future reference, using Yury's ceval.txt as input, I do think that
would be a good thing, but I wouldn't want to make the enhancement
conditional
and to
> Brett Cannon and Benjamin Peterson for their reviews.
This is great to hear!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
and to
> Brett Cannon and Benjamin Peterson for their reviews.
Heh, cdecimal utterly demolishing the old pure Python decimal module
on the telco benchmark means normalising against CPython 3.5 rather
than 2.7 really isn't very readable :)
Cheers,
Nick.
--
Nick Co
is your best
bet.
Cheers,
Nick.
P.S. While I guess you *could* try to figure out a suitable home in
the docs, I don't think you'd gain anything particularly useful from
the additional effort
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
to a builtin module is a pretty good working
model, though. (It isn't *entirely* accurate, but the discrepancies
are sufficiently arcane that they aren't going to matter in any case
that doesn't involve specifically poking around at the import related
attributes).
Cheers,
Nick.
-
On 6 February 2016 at 04:07, Brett Cannon wrote:
> On Thu, 4 Feb 2016 at 05:46 Nick Coghlan wrote:
>> Heh, cdecimal utterly demolishing the old pure Python decimal module
>> on the telco benchmark means normalising against CPython 3.5 rather
>> than 2.7 really isn't v
essing
that problem, it would just need to be empty and used only for
explicit registration without any structural typing support.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
reasonable to permit "_" in place of "," in the format specifier.
However, I'm not sure when you'd use it aside from code generation,
and you can already insert the thousands separator and then replace
"," with "_".
Cheers,
Nick.
--
Nick Coghlan |
ing Py_CLEAR
* using Py_SETREF (but being free to avoid it if you want to use
Py_DECREF instead or are hand-optimising the code in some other way)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
is done processing arguments (that's why we have a longstanding
RFE requesting the availability of sys.raw_argv)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
r Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Robert Kuska ,
Marc-André Lemburg
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-May-2015
Python-Version: 2.7.12
Post-History: 06-Jul-2015, 11-Nov-2015, 24-N
On 24 February 2016 at 21:28, Cory Benfield wrote:
>
> > On 24 Feb 2016, at 10:32, Nick Coghlan wrote:
> >
> > Security Considerations
> > ---
> >
> > Relative to the behaviour in Python 3.4.3+ and Python 2.7.9->2.7.11, this
> >
d then tweaked the
tweak to replace "the main" with "a key").
I didn't mention the prospect of reading sensitive data from the
environment, as the specific problem we're introducing is with write
access, and I believe certainly flavours of vulner
eration, and re-working the PEP to resolve
>> them. Thanks also to everyone who contributed to the discussion.
>
> Yeah, congrats! And thanks for taking on something that (in my mind)
> isn't the most exciting thing to work on. :)
I got to spend work time on it, which gre
to everyone who contributed to the discussion.
Thank you!
I'll commit the reference implementation after I've added
documentation and given folks a chance to take a look at that.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
file.pre.in" instead of the generated Makefile
should keep it from getting confused in the cross-compilation
scenario, and also restore the behaviour of using the checked in copy
rather than rebuilding it just because you ran "./configure".
Cheers,
Nick.
--
Nick Coghla
in instead. I'm confident that will work just fine for
the importlib bootstrapping, and I suspect it will work for the other
pregenerated-and-checked-in files as well.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
_importlib, argument clinic, etc).
Would it help to have a "make bootstrap" target that touched all the
checked in generated files with build dependencies on non-checked-in
files, but only after first touching the expected locations of the
built binaries they depend on?
Cheers,
Nick.
e.
The idea of Decimal literals is complicated significantly by their
current context dependent behaviour (especially when it comes to
rounding), so I'd suggest leaving them alone in the context of this
PEP.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Br
t argument for leaving detecting such cases to
linters rather than the tokeniser.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
On 27 March 2016 at 16:13, Terry Reedy wrote:
> Thoughts?
+1 from me - being able to teach package installation without teaching
the command line first has been an oft-requested capability for a long
time.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austra
Py_SETREF that
> uses Py_DECREF?
With the single-macro design put into effect and concrete problems
arising from that, I'm now more persuaded by the consistency argument
than I was originally, so +1 from me for reverting to your original
dual-macro proposal.
Cheers,
Nick.
--
Nick
o no chance.
Given that, I don't see a compelling reason to change the existing
policy - the "no new features in point releases" restriction only gets
waived in cases that have implications beyond the Python 2.7 process
itself (which pretty much restricts potential waivers to network
se
he longer term fix, but an initial attempt at enabling that
resulted in errors in the bugs.python.org mail logs, so David reverted
to the direct email configuration for the time being.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
st work" with other APIs
that aren't specifically limiting their inputs to str objects
(although using lower level APIs may force a conversion to the lower
level plain text representation as a side-effect).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
aranteed-non-lossy conversion from other types to a
builtin integer, allowing non-builtin integers to accepted for things
like slicing and sequence repetition, without inadvertently also
accepting non-integral types like builtin floats.
Cheers,
Nick.
--
Nick
On 6 April 2016 at 15:03, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote:
>> Option 4: define a rich-object-to-text path serialisation convention,
>
> Unfortunately that sounds like a classic "serious programming"
> solution (objects,
On 6 April 2016 at 15:59, Serhiy Storchaka wrote:
> On 06.04.16 08:52, Greg Ewing wrote:
>>
>> Nick Coghlan wrote:
>>>
>>> The most promising option for that is probably "getattr(path, 'path',
>>> path)",
>>
>>
>>
On 6 April 2016 at 15:57, Serhiy Storchaka wrote:
> On 06.04.16 05:44, Nick Coghlan wrote:
>>
>> The most promising option for that is probably "getattr(path, 'path',
>> path)", since the "path" attribute is being added to pathlib, and the
On 6 April 2016 at 16:25, Ethan Furman wrote:
> On 04/05/2016 10:50 PM, Serhiy Storchaka wrote:
>> On 06.04.16 05:44, Nick Coghlan wrote:
>>> The next challenge would then be to make a list of APIs to be updated
>>> for 3.6 to implicitly accept "rich path"
On 6 April 2016 at 16:53, Nathaniel Smith wrote:
> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan wrote:
>> I'd missed the existing precedent in DirEntry.path, so simply taking
>> that and running with it sounds good to me.
>
> This makes me twitch slightly, because Nu
that step either. :)
It's worth summarising in a PEP at least for communications purposes -
very easy for folks that don't follow python-dev to miss otherwise.
Plus my specific API suggestions are pretty different from Ethan's :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@g
7;, 'functools',
'heapq', 'itertools', 'keyword', 'ntpath', 'operator', 'pathlib',
're', 'reprlib', 'sre_compile', 'sre_constants', 'sre_parse',
'u
hread before commenting
further, though :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
ms is deferred until they're
needed if they're not the same as the canonical form.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
ss through os.fspathname? No, as they're
not names, they're encodings of names
When the name is instead "os.fspath", the appropriate answers to those
three questions are far more debatable.
> I personally still like __ospath__ as well.
That one fails the "Is it ambiguous whe
boxes still aren't particularly
easy to use correctly, but they're a lot more reliable than language
runtime level sandboxes, can be used to defend against many more
attack vectors, and even offer increased flexibility (e.g. "can write
to these directories, but no others"
or that), but we *can* potentially
standardise the terms used when disambiguation is needed: path name
(str), encoded path name (bytes-like object), rich path object (object
implementing the new protocol)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
str object, not
The only specific mention of binary support in the pathlib docs is to
state that "bytes(p)" uses os.fsencode() to convert to the binary
representation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
;."))
Traceback (most recent call last):
...
TypeError: cannot render 'PureWindowsPath' as filesystem path on
'posix' system
(I'm also suggesting replacing "your" with the value of os.name)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.
On 10 April 2016 at 17:12, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> Similar to my proposal for dealing with DirEntry.path being a
>> bytes-like object, I'd like to suggest raising TypeError in __fspath__
>> if the request is nonsensical for the currently runn
On 11 April 2016 at 01:50, Donald Stufft wrote:
>
>> On Apr 10, 2016, at 2:43 AM, Nick Coghlan wrote:
>>
>> This does raise a concrete API design question: how should
>> PurePath.__fspath__ behave when called on a mismatched OS?
>
> I think that PurePath.
On 11 April 2016 at 02:16, Ethan Furman wrote:
> On 04/09/2016 10:31 PM, Nick Coghlan wrote:
>>
>> On 10 April 2016 at 02:41, Ethan Furman wrote:
>
>
>> When somebody hands you bytes rather than text you need to worry about
>> the encoding, and you need to worry
s)
- the names would be fspath and __fspath__, since the result may be
either a path name as text, or an encoded path name as bytes
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing li
On 12 April 2016 at 13:45, Nick Coghlan wrote:
> Consider os.path.join: with a permissive os.fspath, the necessary
> update should just be to introduce "map(os.fspath, args)" (or its C
> equivalent), and then continue with the existing bytes vs str handling
> logic.
That
e those that wanted to accept either could use the
lower level os.fspath.
The ambiguity in question here is inherent in the differences between
the way POSIX and Windows work, so there are limits to how far we can
go in hiding it without making things worse rather than better.
Cheers,
Nick.
--
ely to other operating system
APIs, but can indeed be a problem if they escape to other parts of
your program (hence ideas like
http://bugs.python.org/issue18814#msg251694 and the preceding
discussion in that issue)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
y, you're doing something relatively specialised (like working
on CPython's own os module).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
On 14 April 2016 at 00:11, Paul Moore wrote:
> On 13 April 2016 at 14:51, Nick Coghlan wrote:
>> The potentially SE-strings only come back when you pass str, and the
>> operating system data isn't properly encoded according to the nominal
>> filesystem encoding. They
dy
idempotent - their current signatures are "str-or-bytes -> bytes" and
"str-or-bytes -> str". With a str-or-bytes return type on os.fspath,
adapting them to handle rich path objects should just be a matter of
adding an os.fspath call as the first step.
Cheers,
Nick.
--
rather about letting CPython take care of the bookkeeping details for
things like lnotab and sorting out jump targets).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 14 April 2016 at 12:49, Nick Coghlan wrote:
> The API could be something like:
>
> - os.fspath -> str-or-bytes
> - os.fsencode -> bytes (with coercion from str)
> - os.fsdecode -> str (with coercion from bytes)
> - os.strpath -> str (no coercion)
There seems to
ts, but that argument doesn't apply for
typechecked protocols where the result is required to be an instance
of a particular builtin type (but subclasses are considered
acceptable).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 14 April 2016 at 13:54, Random832 wrote:
> On Wed, Apr 13, 2016, at 23:17, Nick Coghlan wrote:
>
>> - os.fspath -> str (no coercion)
>> - os.fsdecode -> str (with coercion from bytes)
>> - os.fsencode -> bytes (with coercion from str)
>> - os._
On 14 April 2016 at 14:05, Random832 wrote:
> On Wed, Apr 13, 2016, at 23:27, Nick Coghlan wrote:
>> In this kind of case, inheritance tends to trump protocol. For
>> example, int subclasses can't override operator.index:
> ...
>> The reasons for that beha
with structured application level
objects (which means traversing the bytes->str boundary before the
str->Path one).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http
uot;)))
b'str/bytes'
Assuming os.fsdecode and os.fsencode are updated to call os.fspath on
their argument before continuing with the current logic, the latter
two forms would both start automatically handling both DirEntry and
pathlib objects, while the first form would continue to thr
In relation to Victor's comment about this being complex code to show
to a novice:
os.path.join(*map(os.fsdecode, ("str", b"bytes")))
I agree, but also think that's a good reason for people to switch to
teaching novices pathlib rather than os.path, and letti
On 15 April 2016 at 00:52, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > The use case for returning bytes from __fspath__ is DirEntry, so you
> > can write things like this in low level code:
> >
> > def myscandir(dirpath):
> >
uid module
already does the right thing, and it would be a bug if it didn't).
The new secrets module fills the gap for cases where random is
otherwise an attractive nuisance by making it easy to say "use this
instead".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
may as well make it easy to extract the secrets module for use in
earlier versions - 2.7 also gained hmac.compare_digest as part of PEP
466).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
On 16 April 2016 at 21:21, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > On 15 April 2016 at 00:52, Stephen J. Turnbull wrote:
> > > Nick Coghlan writes:
> > >
> > > > The use case for returning bytes from __fspath__ is DirEntry, so you
&
On 17 April 2016 at 04:47, Chris Barker - NOAA Federal
wrote:
>> On Apr 13, 2016, at 8:31 PM, Nick Coghlan wrote:
>>
>>>> class Special(bytes):
>>>> def __fspath__(self):
>>>> return 'str-val'
>>>> obj =
On 17 April 2016 at 18:03, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> > and instead throw exceptions in those cases.
>
> Then I don't understand the current design of fsdecode and fsencode.
> Shouldn't they raise on str and bytes respectively, rather than
cenarios (binary-input-is-a-bug, text-input-is-a-bug, and
either-binary-or-text-input-is-fine).
That way the structure of the additional parameters on _raw_fspath can be
tailored specifically to the needs of the standard library, without
worrying as much about 3rd party use cases.
Cheers,
Nick.
--
opulation, so participation from additional experienced Windows developers
is always appreciated :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
o a
documented-but-underscore-prefixed API: folks writing pure Python 3
application code *really* shouldn't need to worry about the bytes support
in the protocol, but for operating system level use cases, not having it
readily available to 2/3 compatible Python code would be a pain.
Cheers
t down in the low
level weeds of operating system interfaces.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
* to stay
entirely in the binary domain is actually a desirable characteristic,
rather than merely a tool for migrating from Python 2.
Cheers,
Nick.
[1] http://utf8everywhere.org/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
> existing issues that, would have they been fixed, would have allowed a
> successfull cross-build and the same test suite results as described in my
> previous post.
>
Thanks for this, Xavier!
Once you have that, in addition to posting the link back here, you may also
want to ping th
ve no trouble with Gmail with several other Python lists that do not
> include an unsubscribe link.
Indeed, Mailman inserts the appropriate List-Unsubscribe headers, so
there's no need for a link in the body of the emails (and including it
can cause problems when link scrapers hit the a
yList_SetItem and PyTuple_SetItem cases: PyModule_SetAttrString
The first two match the signature of PySequence_SetItem, but steal the
reference instead of making a new one, and the same relationship would
exist between PyObject_SetAttrString and the new
PyModule_SetAttrString.
Cheers,
Nick.
--
Nick Co
On 27 April 2016 at 23:08, Nick Coghlan wrote:
> On 27 April 2016 at 17:14, Serhiy Storchaka wrote:
>> I think that we can resolve this issue by following steps:
>>
>> 1. Add a new function PyModule_AddObject2(), that steals a reference even on
>> failure.
>
> I
or the commercially supported versions, most RHEL subscriptions
include access to the relevant channels:
https://access.redhat.com/solutions/472793
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing lis
se kinds of
concerns for folks that don't have the time or inclination to get
directly involved in improving the situation themselves)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Py
Python 3.3 What's New doc:
https://docs.python.org/3/whatsnew/3.3.html#new-decimal
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
esign
philosophy of "prefer composition to inheritance" has emerged -
subclassing is a powerful tool, but it does mean you often end up
needing to care about more interactions between the subclass and the
base class than you really wanted to.
--
Nick Coghlan | ncogh...@gmail.
g that
Nick-of-several-hours-earlier probably shouldn't be commenting on
tracker issues when he's in dire need of sleep ;)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-De
gt; (or use enum34 or aenum instead ;) .
Needing to use a PyPI alternative to a stdlib module for increased
cross-version consistency is a pretty common experience these days, so
I think that's OK - end users can choose for themselves between the
stability of the stdlib version and the reduced
On 9 May 2016 at 08:50, Guido van Rossum wrote:
> On Sun, May 8, 2016 at 4:49 AM, Nick Coghlan wrote:
>> P.S. The potential complexity of that is one of the reasons the design
>> philosophy of "prefer composition to inheritance" has emerged -
>> subclassing is a
On 9 May 2016 at 12:39, Ethan Furman wrote:
> On 05/08/2016 07:15 PM, Nick Coghlan wrote:
>> Needing to use a PyPI alternative to a stdlib module for increased
>> cross-version consistency is a pretty common experience these days, so
>> I think that's OK - end users
On 10 May 2016 at 02:30, Guido van Rossum wrote:
> On Sun, May 8, 2016 at 7:52 PM, Nick Coghlan wrote:
>> P.S. It occurs to me that a sufficiently sophisticated typechecker
>> might be able to look at all of the calls to "cls(*args, **kwds)" in
>> class methods and
I'd still like to see this exposed to Python code as os._raw_fspath()
(with the leading underscore just meaning "this probably isn't the API
you want" rather than indicating a private or unstable API), and then
fspath() defined as a wrapper around it which disallows bytes as
ou
On 12 May 2016 at 22:40, Koos Zevenhoven wrote:
> On Thu, May 12, 2016 at 3:04 PM, Nick Coghlan wrote:
>>
>> I'd still like to see this exposed to Python code as os._raw_fspath()
>> (with the leading underscore just meaning "this probably isn't the API
&
901 - 1000 of 6587 matches
Mail list logo
