Nick Coghlan added the comment:
One important thing to remember is that once a time is in the past, whether or
not DST was in effect for that time *is never going to change*. That means
converting a DST aware timezone to a fixed offset timezone will work just fine
for historical times.
It&#
Nick Coghlan added the comment:
Makes sense to me (your new proposal sounds pretty close to the sketch I posted
on the mailing list).
It's really only the performance of in-function imports that concerned me and
those are almost always going to get hits in sys.mo
Nick Coghlan added the comment:
At least the first couple of those look like obsolete comments left over from
the 2.x branch (we didn't do a mass renaming in the test suite, so many tests
still live in their old locations).
--
___
Python tr
Nick Coghlan added the comment:
PEP section makes sense - I plan to mark PEP 3118 as Final once you commit this
(or you can do that yourself, for that matter).
--
___
Python tracker
<http://bugs.python.org/issue10
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue14032>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue14026>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Ezio: I spotted an extraneous '[' hanging around in the updated doc signature
for split, but otherwise looked fine.
Éric: you're probably right, but I was sending them a note to suggest a simpler
alternative, only to discover that the obvi
Nick Coghlan added the comment:
"with Lock() as lock:" doesn't make any sense - you need to share the lock with
other threads or code for it be useful, which means you can't create it inline
in the with statement header. Instead, you have to store it somewhere else
(
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Aw, I guess I was too optimistic in thinking this was the last gap before we
could declare it Final...
+1 on creating a new feature request for NumPy style multi-dimensional indexing
and slicing support on memoryview (I'm assuming that's what you m
Nick Coghlan added the comment:
For a different take on this concept:
http://julialang.org/manual/running-external-programs/
--
___
Python tracker
<http://bugs.python.org/issue13
Nick Coghlan added the comment:
Yeah, I'm pretty sure the bootstrap mechanism needs to be able to get hold of
os.py directly so it can be injected into the importlib._bootstrap namespace.
However, it may be worth figuring out and documenting the bare minimum that has
to exist o
New submission from Nick Coghlan :
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4458/steps/test/logs/stdio
Appears to be new, but also isn't obviously related to any recent checkins that
I noticed.
(the Win7 buildbot for trunk isn't in a good place, wi
Nick Coghlan added the comment:
Re: test_packaging: my mistake, the problem was actually test_package__file__
in test_imp (and Antoine already fixed it - there were some caches that weren't
getting cleared properly: #14080)
The last Win7 test run was green, so we may have to write thi
Nick Coghlan added the comment:
I don't consider using Ellipsis as a sentinel value a mess. If you don't like
the PEP's solution, take it up with Guido.
--
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
Because you're breaking the semantics of the "raise X from Y" syntax.
That syntax is *just* syntactic sugar for "_exc = X; _exc.__cause__ = Y; raise
_exc".
Under PEP 409, that remains true.
Your patch breaks it.
If you want to change
Nick Coghlan added the comment:
The other problem with the "separate attribute" approach is that it makes the
condition for suppressing the context ugly:
exc.__suppress_context__ or exc.__cause__ is not None
That's hardly cleaner than:
exc.__cause__
Nick Coghlan added the comment:
Regardless, I'm rejecting this for not complying with the PEP specification
(which is quite explicit about the implementation mechanism and the API exposed
to Python). If you want to challenge an approved PEP, the correct way to go
about it is to write
New submission from Nick Coghlan :
I stuffed up the review on one of the new tests in the PEP 409 patch - the one
that checks if the exception context is suppressed correctly from the command
line.
That test should be drastically simplified and moved from test_raise to
test_cmd_line_script
Nick Coghlan added the comment:
The alternatives are a backwards compatibility break (i.e. raise exc from
other_exc would suppress the context, but exc.__cause__ = other_exc would not)
or else that we don't succeed in eliminating the dual use of __cause__ in the
display routines.
Given
Nick Coghlan added the comment:
Also, ensuring class invariants by setting derived attributes correctly is one
of the primary use cases for properties, so objecting to my proposed approach
is objecting to a fairly fundamental programming technique
Nick Coghlan added the comment:
It's about separating out the testing of the command line executable (i.e.
test_cmd_line and test_cmd_line_script) from that of the interpreter's internal
behaviour.
test_raise is about making sure the "raise" statement works correctly -
Nick Coghlan added the comment:
test_cmd_line and test_cmd_line_script are both about testing the behaviour of
the interpreter when run from the command line. Since this test *is* a
behavioural test for the interpreter when invoked as an application, it should
be in one of them.
The former
Nick Coghlan added the comment:
Hah, I've been dealing with Python's regression test suite for 8+ years and
there are still cases where I don't understand the rationale for testing things
a particular way (beyond "it must have seemed like a good idea at the time&q
Nick Coghlan added the comment:
FWIW, I've also come around to the point of view that it's worthwhile to
provide stdlib support for the "**" convention (specifically due to the UI
aspect that Michael mentions).
--
___
P
Nick Coghlan added the comment:
For 3.2, there's no removal to document - we asked MvL to drop the buffer APIs
from PEP 384, so they've never been part of the stable ABI.
>From the PEP: "The buffer interface (type Py_buffer, type slots bf_getbuffer
>and bf_release
Nick Coghlan added the comment:
Consider a Python wrapper around a bytes object, or mmap or similar that
wants to pass PEP 3118 buffer requests through to the underlying object.
Currently, there's no way to write such a delegation - the delegating class
has to be written
Nick Coghlan added the comment:
To answer your other question, no, strview isn't related - that's strictly a
PEP 3118 *consumer*, which is well supported from the Python side now that
memoryview is fixed.
The trick will be to allow a Python implemented object to be a PEP 3118
Nick Coghlan added the comment:
Does "compileall" generate both .pyc and .pyo by default? Or do you have to run
it twice? If the latter, does pysetup handle that for you?
MvL is correct that zipimport should ignore .pyo files when __debug__ is set
and vice-versa, but the precompila
Nick Coghlan added the comment:
Status quo sounds fine then. +1 for closing it again.
--
___
Python tracker
<http://bugs.python.org/issue1346572>
___
___
Pytho
Nick Coghlan added the comment:
It occurs to me that one thing that *could* be backported to early versions are
some of the documentation improvements on how to correctly handle the lifecycle
of fields in Py_buffer. That gets messy though because memoryview doesn't
behave nicely in
Nick Coghlan added the comment:
Yes, the import related C API should be turned into a mere wrapper around the
appropriate importlib code wherever possible.
I don't think that needs to be a gating criteria for the initial commit, t
Nick Coghlan added the comment:
This is closely related to PEP 395, since multiprocessing currently hits the
same issue in trying to figure out the correct setting for sys.argv0.
I quite like the sys.__argv__ idea for preserving the *exact* underlying
command line (Alex Gaynor was recently
Nick Coghlan added the comment:
In framing a question for Raymond regarding his preference for avoiding the
__argv__ name, I realised I agreed with him. My reasoning is that, when a
Python process starts, sys.stdin is sys.__stdin__, sys.stdout is sys.__stdout__
and sys.stderr is sys
Nick Coghlan added the comment:
Added Mark Shannon to the nosy list - he's been tinkering with this area of the
interpreter lately.
This definitely needs to be fixed though (even if that does mean major surgery
on the implementation, up to and including the introduction of an __iter_f
Nick Coghlan added the comment:
Adding Brett, since the plan is to clear out a lot of the redundant code in
pkgutil once importlib is fully bootstrapped as the standard import
implementation.
(although this will still affect the older versions directly)
--
nosy: +brett.cannon
Nick Coghlan added the comment:
FWIW, +1 on using the *name* of the keyword arg to define the format/resolution
of the argument. It's simple and clear right now, and is easily updated to
handle higher resolutions in the future.
--
nosy: +nco
Nick Coghlan added the comment:
What's the proposal here? If delete is True, close() must delete the file. It
is not acceptable for close() and __del__() to behave differently.
OTOH, if the proposal is merely to change the way the file is opened on Windows
so that it can be opened
Nick Coghlan added the comment:
The whole point of close() methods is to offer deterministic resource
management to applications that need it. Pointing out to applications when
they're relying on CPython's refcounting for prompt resource cleanup is why
many of the standard types n
Nick Coghlan added the comment:
Dave, decoupling the lifecycle of the created file from the object that created
it is exactly what delete=False already covers. The complicated dance in
NamedTemporaryFile is only to make *__del__* work a bit more reliably during
process shutdown (due to some
Nick Coghlan added the comment:
Mark's patch looks good on a quick read through (although I still need to
double check where f_lasti gets incremented to be happy the new comment about
YIELD_FROM is accurate).
If someone gets to this soon, great, otherwise I'll deal with it afte
Nick Coghlan added the comment:
Reviewed - actual impl looks good to me, couple of comments regarding the docs
and tests.
--
___
Python tracker
<http://bugs.python.org/issue14
Nick Coghlan added the comment:
With the decision on whether or not to suppress the context moved out to a
separate flag, I think we need to allow it. Requiring that the flag be False
*and* that the context also be None gets us back to asking the question of why
the flag doesn't work
Nick Coghlan added the comment:
13850 (already mentioned above) is my relevant argparse docs proposal - it
turns out the other argparse issues I remembered posting were actual feature
requests rather than docs suggestions (FWIW, those are 14037 and 14039
Nick Coghlan added the comment:
A couple of thoughts on the draft HOWTO:
I like the "verbosity" example, but I'd also like to see it continue on into
introducing the "action='count'" alternative that allows "-vv" to set the
verbosity level to 2
Nick Coghlan added the comment:
Rather than "is recommended by at least one core CPython developer" I'd say
"matches the way the CPython executable handles its own verbosity argument"
(check the output of "python --help")
Also, a better fix for the no
Nick Coghlan added the comment:
The reason I don't particularly like the "delegation only" API is that the
combination of the new memoryview implementation and bytes/mmap/etc to get a
flat region of memory to play with means you could do some quite interesting
things entirel
Nick Coghlan added the comment:
Yup, I plan to get a few things like this incorporated once I have broadband
access at home again. Probably won't be early enough to get things into alpha
2, but they should make it for alpha 3.
--
___
P
Nick Coghlan added the comment:
The proposed fix sounds reasonable to me. Would it be possible to work
something into test_capi to actually test it?
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue14
Nick Coghlan added the comment:
It may not even have to specifically test the crash - any operation that
accessed the tstate on the frame and could be shown to be accessing the wrong
thread state when called from another thread could demonstrate the problem
Nick Coghlan added the comment:
Huh? Demonstration please, as the -m switch absolutely does display tracebacks
when the call fails:
$ python -m timeit -s "raise RuntimeError"
Traceback (most recent call last):
File "/usr/lib64/python2.7/timeit.py", line 298, in main
Nick Coghlan added the comment:
Never mind, I just looked at your patch and better understand what you're
wanting to improve (i.e. diagnosing problems with bootstrapping runpy itself,
not the errors that occur after runpy has already been found).
However, your proposed soluti
Changes by Nick Coghlan :
--
title: RunModule(): display the traceback on failure -> Easier error diagnosis
when bootstrapping the runpy module in main
___
Python tracker
<http://bugs.python.org/issu
Nick Coghlan added the comment:
Taking a closer look at the four affected cases, I've changed my mind - the
patch looks reasonable, go ahead and add it (as the new output actually still
makes sense in the RunMainFromImporter case)
However, additional test cases should be add
Nick Coghlan added the comment:
Attached script is a first cut at a multi-threading stress test for the new
dict behaviour. It should be significantly worse than anything a real world app
is likely to be doing to a dictionary that is shared between threads without
any form of synchronisation
Nick Coghlan added the comment:
Bumping the target version for this issue to 3.4.
There's a lot of active development in the shell convenience function space at
the moment, including my shell_command, Vinay Sajip's sarge, Kenneth Reitz's
envoy and the possibility of doing som
Nick Coghlan added the comment:
For the record, my shell access convenience API proposal is in issue 13238.
I'm not going to push that for 3.3 though - convenient shell access from Python
is currently an area with a lot of active third party development, so I think
it's worthwhile
Nick Coghlan added the comment:
Everyone missed my other argument in favour of alternate constructor
methods: fixing the currently wrong default arguments.
There is no good reason to break working code when beginner confusion can
be better addressed by telling them to avoid calling the Popen
Nick Coghlan added the comment:
A thought prompted by Raymond's comment: did we ever try just protecting
the retry as a recursive call? If we can stop the stack blowing up, it
seems to me we'd get the best of both worlds (that is, crashes become
RuntimeError, but naive multi-thread
Nick Coghlan added the comment:
I'm unlikely to add the contextlib2.ContextStack API as written. I aim to have
an updated variant (called contextlib.CallbackStack) available for alpha 3 in
May:
https://bitbucket.org/ncoghlan/contextlib2/issue/8/rename-contextstack-to-callbackstac
New submission from Nick Coghlan :
A (very) minor irritation discovered today - the PEP 8 style names were added
to the threading.Thread API in 2.6, but the only notice of this is up at the
top of the module docs.
Some embedded notices like:
..versionchanged:: 2.6
Added PEP 8
New submission from Nick Coghlan :
The task management API in the Queue module doesn't let you check to see if
there are any pending tasks still being processed.
A pending() query API (analagous to empty() and full()) would resolve that
problem.
The use case is for a process that termi
Changes by Nick Coghlan :
--
components: +Library (Lib)
stage: -> needs patch
type: -> enhancement
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
I just created #14487 to request a documented API (Queue.pending()) that
provides a formal mechanism for asking whether or not any jobs are still
pending (analagous to the existing empty() and full() query methods).
Specifically, what I have is a client
Changes by Nick Coghlan :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Add timeout parameter to Queue.join()
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
I killed off my new issue in favour of this one, since they're covering the
same ground.
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
The function below is the workaround I plan to use based on the
undocumented-but-public Thread attributes that relate to the task queue (it's
essentially just a combination of Queue.join() with the existing structure of
the Queue.get() implementation):
Nick Coghlan added the comment:
The thread pool impl where I'm using this:
http://git.fedorahosted.org/git/?p=pulpdist.git;a=blob;f=src/pulpdist/cli/thread_pool.py
--
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
I probably will eventually - I'll be playing catchup a bit on other tasks this
month after doing almost no coding for CPython since some time in Feb.
--
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
I agree we need to add something here to better support the idiom where the
"close" and "delete" operations on a NamedTemporaryFile are decoupled without
the delete becoming a completely independent call to os.unlink().
I agree with RDM
Nick Coghlan added the comment:
I converted issue #14243 to a feature request, so this is now a duplicate.
--
nosy: +ncoghlan
resolution: -> duplicate
status: open -> closed
superseder: -> tempfile.NamedTemporaryFile not particularly useful o
Nick Coghlan added the comment:
Although, for the stdlib version, I wouldn't suppress the OS Error (I'd follow
what we currently do for TemporaryDirectory)
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Hmm, we changed a few things with the way the back end server for pydoc works
in 3.2. I didn't realise there was a Windows shortcut though, and I don't know
how it gets generated. It sounds like it is still using the "-g" option, which
is
New submission from Nick Coghlan :
The language spec currently includes the following paragraph [1]:
Names listed in a global statement must not be defined as
formal parameters or in a for loop control target, class
definition, function definition, or import statement.
While the first
Nick Coghlan added the comment:
Thread link:
http://mail.python.org/pipermail/python-ideas/2012-April/014783.html
--
___
Python tracker
<http://bugs.python.org/issue14
Nick Coghlan added the comment:
Specifically, we end up calling os.realpath() (or the C level equivalent) when
initialising __main__.__file__ and sys.path[0].
Agreed this behaviour should be documented (and tested!) explicitly.
--
assignee: -> docs@python
components: +Documentat
Nick Coghlan added the comment:
Change looks fine to me - go ahead and commit it :)
--
___
Python tracker
<http://bugs.python.org/issue14515>
___
___
Python-bug
New submission from Nick Coghlan :
The json "sort_keys" parameter is actually supported as an argument to dump()
and dumps() (and is used that way in the examples), but is only documented as
an argument to the JSONEncoder constructor.
--
assignee: docs@python
components: Doc
Nick Coghlan added the comment:
Some additional thoughts for anyone else that comes across this issue.
Consider the case of a weakref proxy (the only proxy type in the stdlib): for
that, you never want to serialise the proxy, you want to serialise the original
object.
To correctly serialise
Change by Nick Coghlan :
--
pull_requests: +13372
___
Python tracker
<https://bugs.python.org/issue36797>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
While I do have a second PR open with some additional smaller cleanups, the
first PR removed the outdated information that seemed most problematic.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Nick Coghlan added the comment:
This has been merged for 3.8 and 3.7, but not for 2.7, since the docs have
diverged far enough that the automatic backport didn't work:
https://github.com/python/cpython/pull/13087#issuecomment-494402704
Given the proximity to the general end of life o
Nick Coghlan added the comment:
I split https://bugs.python.org/issue37010 out as a separate performance issue
in case anyone is inclined to explore the idea of reversing the relationship
between inspect.signature and inspect.getfullargspec, such that the latter
becomes a fast building
New submission from Nick Coghlan :
(Splitting out a separate performance issue from
https://bugs.python.org/issue36751#msg342683)
There can be two quite different reasons for inspecting a function signature:
* inspecting arbitrary functions to learn as much about them as possible in
order
Nick Coghlan added the comment:
New changeset e788057a9188ff37e232729815dfda2529079420 by Nick Coghlan in
branch 'master':
bpo-36797: Reduce levels of indirection in outdated distutils docs (#13462)
https://github.com/python/cpython/commit/e788057a9188ff37e232729815dfda
Nick Coghlan added the comment:
(Added packaging, Linux distro, and Windows and macOS installer folks to the cc
list)
Chris and I were discussing this behaviour, and it turns out even I had
forgotten how we had specified this feature in PEP 453: `ensurepip --upgrade`
ensures that an older
Nick Coghlan added the comment:
Addressing the other part of Chris's initial post: there's also no
`--upgrade-pip` option on `venv` itself.
Instead, there's only an `--upgrade` option that is intended for *Python*
version upgrades, and restructures the internal layout of the
Nick Coghlan added the comment:
New changeset 99b5c940d3471e0ed6579771d94e7342d7c733e0 by Nick Coghlan (Dimitri
John Ledkov) in branch '2.7':
[2.7] bpo-34836: fix test_default_ecdh_curve, needs no tlsv1.3. (GH-9626)
https://github.com/python/cpyt
New submission from Nick Coghlan :
The Porting section of the What's New guide is for changes where the old
behaviour was at best arguably correct, but it's still possible someone was
relying on it behaving exactly the way it used to.
It isn't for us to say "We broke all
Nick Coghlan added the comment:
The key problem isn't Cython itself, the problem is that Cython generated
libraries can't be rebuilt for 3.8 without regenerating their C files.
I'd be fine with PyCode_NewWithPosArgs (Victor's right that a descriptive
naming convention ha
Nick Coghlan added the comment:
New changeset 3a1d50e7e573efb577714146bed5c03b9c95f466 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-28009: Fix uuid SkipUnless logic to be based on platform programs capable
of introspection (GH-12777)
https://github.com/python/cpyt
Nick Coghlan added the comment:
(Note: this isn't SC feedback yet, it's individual contributor feedback from me)
As others noted, the reason we treat "Incompatible with Cython generated source
code" distinctly from other C API source compatibility issues is because
C
Nick Coghlan added the comment:
Perhaps `os._abspath_for_import`? If importlib finds it, then it can handle
making early paths absolute itself, otherwise it will defer doing that until it
has the full external import system bootstrapped. (importlib does try to make
all paths absolute as it
Nick Coghlan added the comment:
New changeset 08970cb03c61f62f4f69e7769d0075fa66bb86aa by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-36210: update optional extension handling for AIX (GH-12202)
https://github.com/python/cpython/commit/08970cb03c61f62f4f69e7769d0075
Nick Coghlan added the comment:
It isn't the actively maintained projects that publish wheel files that I'm
worried about fixing - it's the sdist only projects that would otherwise only
need recompilation to work on the new Python version.
With this fixed, and the PyCode_Ne
Nick Coghlan added the comment:
I'm happy with the change in https://github.com/python/cpython/pull/13959, but
we need sign-off from Łukasz as release manager on bumping the
Py_VERSION_SERIAL a bit early so Cython can reliably detect that this change
has been reverted without having to
Nick Coghlan added the comment:
There's also the question of complying with our own deprecation policy, as the
approval to ditch tp_print API compatibility in PEP 590 relied on the fact that
it has been deprecated since Python 3.0.
However, it turns out the associated program
Nick Coghlan added the comment:
In reviewing https://github.com/cython/cython/pull/3009, Jeroen pointed out
that my symbol checking idea wouldn't actually work, since the preprocessor can
only see preprocessor definitions, not compiler symbols. If we're going to rely
on a pr
New submission from Nick Coghlan :
Reviewing some code today, I came across a ConfigParser.set() call that only
specified the section and key, with the value argument missing.
If you look at the ConfigParser.set() docs, this seems like incorrect code, as
those docs indicate that the value
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<https://bugs.python
1501 - 1600 of 6301 matches
Mail list logo
