Nick Coghlan added the comment:
I removed the 3.3 patch, since all the previous version did was change symbolic
links to hard links, and the latest round of discussions favoured retaining the
symlinks since they're much easier to introspect.
However, it turns out there is still one c
Nick Coghlan added the comment:
Actually, the Python 3 Makefile.pre.in is currently broken if $(EXE) is ever
non-empty - in a few places it uses "$(PYTHON)$(VERSION)$(EXE)" and
"$(PYTHON)3$(EXE)".
Those are wrong, because the definition of $(PYTHON) at the top of the f
Nick Coghlan added the comment:
New patch that aims to create the appropriate symlinks in "make bininstall". I
don't currently have a sacrificial VM set up to test it in though.
--
Added file: http://bugs.python.org/file24530/pep394_python2
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file22737/version27_links.patch
___
Python tracker
<http://bugs.python.org/issue12627>
___
___
Python-bug
New submission from Nick Coghlan :
I've just started using the argparse subparser feature, and it's very nice.
However, I'd love to be able to group the different subparser commands into
different sections the way I can group ordinary arguments with
add_argument_group().
Init
New submission from Nick Coghlan :
Currently, using add_subparsers() means that the entire list of subcommands is
added to the main usage message. This gets rather unwieldy when there are a lot
of subcommands.
It would be nice if the add_subparsers() method accepted a "metavar" argu
Nick Coghlan added the comment:
I realised that my initial idea doesn't play nicely with my other suggestion of
allowing a "metavar" argument to add_subparsers() (see #14039).
A better model may be to mimic the add_argument_group() directly by offering an
add_parser_group(
Nick Coghlan added the comment:
Keeping module references implicitly in import_fresh_module will leak
references like crazy in the test suite. The onus is on the code referencing
module contents to ensure that the module globals remain valid.
If we get rid of the explicit clearing of module
Nick Coghlan added the comment:
In #14035, Florent pointed out the current behaviour potentially causes
problems for some uses of import_fresh_modules() in the test suite (with
globals sometimes being set to None if there's no indepenent reference to the
module).
GC based module cl
Nick Coghlan added the comment:
In the case of *dependencies* that get refreshed, no they're *not* kept in
sys.modules - they get overwritten by the originals when the sys.modules state
gets restored.
The problem almost certainly arises because something, somewhere is doing "from
Nick Coghlan added the comment:
No automatic link, since I neglected to mention the issue number in the checkin
messages:
2.7: http://hg.python.org/cpython/rev/a65a71aa9436
3.3: http://hg.python.org/cpython/rev/dc721f28f168
I deliberately *didn't* make the change in 3.2. As the choi
Nick Coghlan added the comment:
Could you provide some failing examples?
The suggestion also seems to run slightly at odds with itself - in one part,
silently replacing an invalid port specification with a different value, in
another adding additional validation checks.
Also, rather than
Nick Coghlan added the comment:
For the purposes of this test (i.e. running the same script several different
ways and making sure it always behaves as expected), I wouldn't even worry
about making it configurable.
Just define a list of example args as a module global, append them t
Nick Coghlan added the comment:
Also, since this issue was last updated, Antoine devised a scheme to test some
of the embedding functionality (mainly to test subinterpreters, IIRC). Perhaps
that could be harnessed to check GC-based shutdown is working correctly (it
might even do it already
Nick Coghlan added the comment:
The other thing that came out of the rambling Unicode thread on python-ideas is
that we should clearly articulate the options for processing files in a
task-based fashion and describe the trade-offs for the different alternatives.
I started writing up my notes
Nick Coghlan added the comment:
On Sat, Feb 18, 2012 at 10:10 PM, Francisco Martín Brugué
wrote:
> ./python ./Tools/scripts/patchcheck.py
> Getting the list of files that have been added/changed ... 0 files
> Fixing whitespace ... 0 files
> Fixing C file whitespace ... 0 files
&
Nick Coghlan added the comment:
The second instance is inside the source code string that's written out as the
script to be run in the subprocess. Not a bad idea actually:
- it avoids writing the example args twice (which is what I was thinking of
doing)
- it avoids turning the test_s
Nick Coghlan added the comment:
Purging __file__ of relative references isn't a problem - they're *supposed* to
always be absolute. The import.c version just stuffs it up sometimes (mainly
due to the way it handles the empty string in the path).
IOW, while the importlib beh
Nick Coghlan added the comment:
Just noticed one minor nit with the patch: the pure Python version of
functools.partial should support "func" as a keyword argument that is passed to
the underlying object. The trick is to declare a positional only argument like
this:
def f(*ar
Nick Coghlan added the comment:
Also, the closure based implementation should be decorated with @staticmethod
(see http://bugs.python.org/issue11704) and the tests updated accordingly.
--
___
Python tracker
<http://bugs.python.org/issue12
Nick Coghlan added the comment:
FWIW, I doubt you'd get many objections if you ended up wanting to make time a
builtin module and inject it into the bootstrapping namespace.
While I don't think the delay in noticing filesystem changes is reasonable as
the default behaviour, i
Nick Coghlan added the comment:
Latest version looks good to me - I vote for landing it whenever you're ready :)
--
___
Python tracker
<http://bugs.python.org/is
New submission from Nick Coghlan :
Currently, setting maxsplit for the default "any whitespace" behaviour requires
the following cryptic incantation:
'do re mi fa'.split(None, 1)
That would be significantly more comprehensible as:
'do re mi fa'.split(max
New submission from Nick Coghlan :
Currently, datetime.timezone requires that the offset be specified explicitly.
It would be more convenient if the local offset was used by default.
Since the time module already exposes the offset details for the local
timezone, this would just make
Nick Coghlan added the comment:
Marking as a duplicate of #9527.
If that API is added, the local fixed offset timezone will be accessible as
datetime.datetime.localtime().tzinfo which would be simple enough.
--
resolution: -> duplicate
superseder: -> Add aware local time supp
Changes by Nick Coghlan :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14083>
___
___
Python-bugs-list mailing list
Unsubscri
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
1601 - 1700 of 6501 matches
Mail list logo
