New submission from Nick Coghlan :
The current execution model documentation in the Language Reference doesn't
clearly explain the multiple phases of code execution:
1. Compilation time (statement by statement in the main module and at the
interactive prompt, all at once for module impor
Nick Coghlan added the comment:
Revised error messages and tests look reasonable and the code seems fine on a
visual scan.
+1 from me.
--
___
Python tracker
<http://bugs.python.org/issue12
Nick Coghlan added the comment:
Reviewed. General concept looks sound, just suggested a few tweaks around the
edges.
And issue title updated appropriately :)
--
title: make cell var initialization more efficient -> simplify cell var
initialization by storing constant data on
Nick Coghlan added the comment:
Most of my thoughts on this topic can be found at
http://svn.python.org/view/sandbox/trunk/userref/ODF/ (that was written ~2.5,
so some parts of it are a little dated, but the Essential Concepts section is
still fairly accurate).
The most relevant part to the
Nick Coghlan added the comment:
The other directly relevant part is in section 5:
5.1.3 Evaluating Default Arguments
In static languages such as C, function definitions are instructions to the
compiler rather than executable statements. This leads to such languages making
distinctions
Nick Coghlan added the comment:
Feel free to create a new issue about the incorrect size calculation on code
objects, since it is apparently already broken.
--
___
Python tracker
<http://bugs.python.org/issue12
Nick Coghlan added the comment:
Oh, agreed - the quotes above are from the "Python's User Reference" I wrote
several years back, but never got around to converting from ODF and
subsequently updating and publishing in a more accessible way.
It was designed to fill the gap tha
Nick Coghlan added the comment:
Yeah, the broader issue with multiprocessing, Windows and state held in the
main module is covered by PEP 395, so there's no need to double up by keeping
this open.
--
resolution: -> fixed
stage: -> committed/rejected
status: ope
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
OK, this isn't going to be as simple as I thought it was. The big problem is
that the test suite from [1] needs to be refactored into a format that is
suitable for use in regrtest. That means porting them to either unittest or
doctest, as "golden out
Nick Coghlan added the comment:
The idea of PyManagedBuffer is for it to be an almost completely passive object
that *just* acts as a refcounted wrapper around the Py_buffer structure, so it
doesn't care about the actual contents. The only supplemental functionality I
think it should pr
Nick Coghlan added the comment:
I should also note that if memoryview ends up growing enough state to cope
correctly with numpy-style multi-dimensional slicing, I'm actually OK with
that. You could get a long way just using the array module to allocate a large
chunk of memory and t
Nick Coghlan added the comment:
The acceptance of PEP 380 actually muddies the waters on this one - the
expansion I cited as a syntax error now has a defined meaning. Specifically,
list comprehensions containing yield expressions would become generators that
return a list (set and dict
Nick Coghlan added the comment:
I'll try to do a summary of the conversation so far, since it's quite long and
hard to follow.
The basic issue is that memoryview needs to support copying and slicing that
creates a new memoryview object. The major problem with that is that the
Nick Coghlan added the comment:
memoryview.release() will raise an exception if you call it when the underlying
PyManagedBuffer instance has a refcount > 1. So the explicit memory management
still works, and if you mess it up by leaving dangling references around you'll
run the
Nick Coghlan added the comment:
Raymond, do we care whether or not the pure Python version of functools.partial
supports inheritance and instance testing?
The constructor is technically documented as returning a "partial object"
rather than a simple staticmethod instance with
New submission from Nick Coghlan :
The Boston Python Workshop folks have some detailed step-by-step instructions
on getting Python up and running ([1]).
Given that this can be a pain point for new users (primarily on Windows), it
may be good to reference these instructions from the official
Nick Coghlan added the comment:
Marking the PEP 380 implementation as a dependency, as I expect it to be easier
to update this patch to cope with those changes than it would be the other way
around.
--
dependencies: +PEP 380 reference implementation for 3.3
Nick Coghlan added the comment:
Renaud has updated the patch on bitbucket to incorporate Greg's tests (still in
golden output form, but in a unittest/regrtest compatible way). That's a good
enough starting point for me - they can be refactored into proper assert based
tests later.
Nick Coghlan added the comment:
It might be worth postponing the multi-dimensional support to a second patch,
though. If we can get the buffer lifecycle solid first then that provides a
better foundation for any further development.
--
___
Python
Nick Coghlan added the comment:
As far as the rule of disallowing shape changes while a buffer is exported, I
actually think that's a more sane approach as well. However, I've been burned
enough times by going "nobody would be insane enough to rely on that, would
they?"
Nick Coghlan added the comment:
Nice work with the patch Stefan - I've added a few review comments (including a
suggestion on how to deal with the GetContiguous problem).
One idea that review did prompt is that if we aren't going back to the original
object for fresh buffer request
Nick Coghlan added the comment:
Is there anything stopping us just storing the flags on PyManagedBuffer? It's
OK if the construction API requires the flag information in addition to the
Py_buffer struct.
--
___
Python tracker
Nick Coghlan added the comment:
On Tue, Jul 5, 2011 at 12:36 AM, Pauli Virtanen wrote:
> Slicing memoryviews can invalidate the contiguity flags, and no-strides
> flags, so some checks are still probably needed in `memory_getbuf`.
That makes sense, so just as memoryview has its own sha
Nick Coghlan added the comment:
It took me a bit of thinking, but I figured out why the "contiguous" flags
imply STRIDES. A quick recap of all the flags:
WRITABLE -> error if can't support write access
FORMAT -> request format info in Py_buffer struct. Should nev
Nick Coghlan added the comment:
At least, that's the explanation based on the PEP - not sure where "CONTIG" as
an alias for ND (N-dimensional) comes from. But then, smalltable was an
undocumented novelty, too :)
--
___
Python
Nick Coghlan added the comment:
To address the "should PyManagedBuffer be public?" question: yes, I think so.
Given the amount of grief the raw PEP 3118 API has caused the memoryview
implementation, I expect the easier lifecycle management provided by the
PyObject based API may als
Nick Coghlan added the comment:
Regarding the Reitveld cc field: I tend not to add anyone to that and instead
post comments to the tracker item to say that I've finished a review in
Reitveld. If people want to see details they can go look at the review itself
(or remove themselves fro
Nick Coghlan added the comment:
I don't think that's a bug, it's a missing feature in the integration (there's
a request on the metatracker to add automatic notifications of new reviews on
the bug itself).
I did mention the review above but it would have been easy to mis
Nick Coghlan added the comment:
Moving this discussion out of the review comments:
Antoine is wanting to make release() nondeterministic by having the underlying
buffer only released when all views using it either have release() called or
are no longer referenced.
I contend that release
Nick Coghlan added the comment:
If someone is calling release() on all of their views (including slices) than
they won't have any problems. The only way they can get into trouble is if they
have a slice or copy that they *aren't* explicitly releasing, and in that case
they *alrea
Nick Coghlan added the comment:
Oops, Antoine's right, the release() semantics in the patch are broken, albeit
for the precisely opposite reasons: that example will actually blow up with
BufferError inside some_library_function().
I withdraw my objection - Antoine's right that rele
Nick Coghlan added the comment:
Sorry, I mischaracterised Antoine's suggestion in my last comment. It's more in
the nature of ManagedBuffer exposing two APIs:
1. request_release(): tells ManagedBuffer "if I have the last reference,
release the buffer now".
2. release():
Nick Coghlan added the comment:
Yeah, the reason my originally proposed semantics were wrong is because copying
(or slicing) a memoryview object and then explicitly releasing that object
would always fail through no fault of that code. That would be broken and the
only way to fix it is to
Nick Coghlan added the comment:
Once again got close to committing this, but then realised it is missing all
the necessary documentation updates for a core language change.
I have uploaded a patch that includes all the changes from Bitbucket as well as
the subsequent fixes to avoid modifying
Nick Coghlan added the comment:
This API has changed around a bit in 3.x, so it is actually
inspect.getfullargspec that needs to change (getargspec will inherit the new
behaviour though, since it uses getfullargspec internally)
With appropriate docs and tests updates, I don't see a pr
Nick Coghlan added the comment:
I moved my personal sandbox from hg.python.org to bitbucket, so it should be
easier for folks to build off the work in progress. (And fixed the typo in
Renaud's name - I at least had it right in ACKS. I also reworded the draft
attribution text in What&
Nick Coghlan added the comment:
Nice, I didn't know we have those comprehensive using docs. However, they
should be linked from http://docs.python.org/dev/tutorial/interpreter.html
(definitely inline and perhaps a see also).
--
___
Python tr
Nick Coghlan added the comment:
The ordering is as it is so that the last line in the displayed traceback
corresponds to the exception that was actually caught. That is, the last line
remains the same regardless of whether or not there was an earlier exception in
the chain. Without that, the
Nick Coghlan added the comment:
The redundancy of the "(most recent call last)" when there's only one frame in
the stack is a separate problem (as it happens even for unchained tracebacks),
but feel free to create a new issue if you'd like to see it changed (I expect
Nick Coghlan added the comment:
+1 for a new exception type to indicate "this may technically be legal Python,
but this Python implementation cannot handle it correctly"
Whatever exception type we add, it would be nice to also be able to use it if
someone eventually fixes th
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue10271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
On Sat, Jul 16, 2011 at 8:24 PM, Martin v. Löwis wrote:
>> sys.version_info and sys._mercurial provide all the info needed for someone
>> (like me for mnfy)
>
> Can you please elaborate? How do you know from looking at
> sys._mercurial wh
Nick Coghlan added the comment:
NotImplemented is a speed and maintainability hack - the runtime cost and
additional code complexity involved in doing the same operator signalling via
exceptions would be prohibitive (check Objects/abstract.c in the CPython source
if you want the gory details
Nick Coghlan added the comment:
Also, a note regarding efficiency: as it calls the underlying methods directly
and avoids recursing through the full operand coercion machinery, I would
actually expect this approach to run faster than the current implementation
Nick Coghlan added the comment:
It's important to remember that other implementations treat CPython as
the "gold standard" for compatibility purposes. If we declare
something to be an ordinary SyntaxError, then that carries strong
implications for what other implementations s
Nick Coghlan added the comment:
It also makes it clear to users whether they've just run up against a
limitation of the implementation they're using or whether what they've
written is genuinely illegal code. They are NOT the same thing.
Attempting to conflate them into one ex
Nick Coghlan added the comment:
It matters, because Python "users" are programmers, and most
programmers want to know *why* they're being told something is wrong.
Raising MemoryError is technically incorrect at this point, but at
least gives the right flavour of the user not
Nick Coghlan added the comment:
After further reflection, I (eventually) came to the same conclusion as
Benjamin and Antoine - using SyntaxError for this is fine.
However, the exception *message* should make it clear that this is an
implementation limit rather than a language limit
Nick Coghlan added the comment:
Yeah, at the level of *code* the origin doesn't really matter, so re-using the
exception type is actually OK. However, for *people* seeing the stack trace, it
may be useful to know what's genuinely illegal syntax and what's a limitation
Nick Coghlan added the comment:
Load time parameterisation seems more of a worthwhile addition to me, too. As
David noted, runtime parameterisation is pretty easy to do by looping and
consolidating failures into the one error message via self.fail().
For test naming, trying to get too clever
Changes by Nick Coghlan :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue12598>
___
___
Python-bugs-list mailing list
Unsub
New submission from Nick Coghlan :
Problems noted by PJE on import-sig:
For example, PathFinder's find_module treats an empty path the same as
sys.path, and will also fail if for some reason the bool() of a PEP 302 finder
or loader object is False.
Nick Coghlan added the comment:
Here's a sketch for a possible decorator factory:
def parameters(params, *, builder=_default_param_builder):
def make_parameterized_test(f):
return ParameterizedTest(f, params, builder)
return make_parameterized_test
(default builder wou
New submission from Nick Coghlan :
General untidiness in the anchor names (and lack of same for entries like
Changes by Nick Coghlan :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Nick Coghlan added the comment:
Should also be an outgoing link to http://bugs.python.org/issue1739468
from the
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg140819
___
Python tracker
<http://bugs.python.org/issue7897>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Sorry, misclicked and removed this comment from David:
Oh, I see. Make the name the first element of the argtuple and then strip it
off. Well, that will work, it just seems bass-ackwards to me :)
And why is it 'case'? I thought we were talking a
Nick Coghlan added the comment:
In my example, I needed a word to cover each entry in the collection of
parameter tuples. 'case' fit the bill.
The reason I like the builder approach is that it means the simplest usage is
to just create a list (or other iterable) of parameter tu
Nick Coghlan added the comment:
The best solution is to modify the offending code to use real docstrings.
Failing that, a simple explicit "'\n'.join(line.lstrip('#' for line in
comment.split('\n'))" (i.e. not as part of pydoc) will handle most cases.
A
Nick Coghlan added the comment:
It's rare to receive fixes from Windows users that don't have a dev environment
set up (i.e. they just edited their stdlib code in place, or copied it and
created a modified version). Thanks for persisting in the face of invalid
assumptions o
Nick Coghlan added the comment:
+1 for making this limitation explicit. See the caveat on locals() [1] for an
example of how to note this kind of restriction.
[1] http://docs.python.org/dev/library/functions.html#locals
--
___
Python tracker
Nick Coghlan added the comment:
Compare however the behaviour of bytes() and bytearray() which support direct
zero initialisation of a region of memory by passing an integer to their
constructor.
--
nosy: +ncoghlan
___
Python tracker
<h
Nick Coghlan added the comment:
I agree with Antoine - it's a simple bug introduced by the attempt to allow
temporary directories to be correctly cleaned up during interpreter shutdown.
The race condition due to the usage of LBYL is shared with the full
shutil.rmtree implementation, s
Nick Coghlan added the comment:
See also #1559549, which similarly adds attribute support to ImportError and
covers some of the issues with using positional arguments to do so.
Extending that approach to a path keyword argument as well should work nicely
Nick Coghlan added the comment:
Indeed it is, although we think actually doing that is a bad idea (as discussed
earlier on this tracker item).
See the 3.1 docs for the recommended workaround for the removal (basically grab
a copy of the 3.1 code and drop it into your own utility module
Nick Coghlan added the comment:
It's actually the documentation that's slightly wrong in this case. On Windows,
there is an additional import mechanism based on the Windows registry that is
checked before the ordinary sys.path mechanism. (See
http://docs.python.org/libra
Nick Coghlan added the comment:
Barry convinced me that the test.support docs need to stay in the same repo as
the code they document, so -1 from me as well.
Changed issue title to reflect the real problem that inspired this suggestion
(i.e. test.support.unlink et al appearing in the docs
Nick Coghlan added the comment:
The Windows build actually uses the registry to locate the standard library
rather than sys.path. This is by design, but isn't really documented properly.
It means that code on sys.path (even in the current directory) won't shadow
standard library
Nick Coghlan added the comment:
As far as I know, not as a top-level module in an installed version of Python
(at least, not without mucking about in the registry).
Shadowing standard library modules is generally a bad idea, and this is one of
the reasons
Nick Coghlan added the comment:
I'd assigned this to myself since I was discussing it with Brandon when he was
working on it at the PyCon sprints. Since I certainly don't want to block
anyone else getting to it, I'm unassigning it - feel free to take it forward :)
IIRC, the
Nick Coghlan added the comment:
I'd say the main reason the dev guide is in a separate repo is the historical
one (i.e. Brett was working on it as a separate repo prior to the hg migration
and we never merged it).
However, the version independent nature of the material is the main arg
Nick Coghlan added the comment:
I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my
netbook and updating to the latest Py3k code, I got a lot of test errors, even
after a make distclean and ./configure.
The errors went away after manually tweaking LDFLAGS as Chri
Nick Coghlan added the comment:
Added Ned to the nosy list.
For Python core, we should also keep in mind that we do have the option of
adding a -X coverage option to avoid the need for the encodings module hack.
--
nosy: +nedbat
___
Python tracker
Nick Coghlan added the comment:
As Georg noted, only individual expressions get parentheses based continuations
automatically. For statement level use of comma separation, it's decided on a
case-by-cases basis as to whether we think it is a legitimate usage based on
our style guide
Nick Coghlan added the comment:
Tennessee, there were a few issues in the original patch - see the attached
update (mostly the use of assert statements instead of methods and the
overbroad scope of the context manager when checking for an expected exception).
However, in getting ready to
Nick Coghlan added the comment:
For 3.3, it may be relevant that send/recvmsg are now available via the socket
API (see #6560)
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11
New submission from Nick Coghlan :
Had a weird bug in test_array.test_tofromstring failing on Gentoo by generating
too few warning messages:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/568/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all
Nick Coghlan added the comment:
Someone here at the sprints pointed out a redundant unsigned comparison to 0
that I missed, so a second set of eyes to double-check things like that would
be good.
--
___
Python tracker
<http://bugs.python.
Changes by Nick Coghlan :
--
nosy: -python-dev
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
This is a dupe of #10042
--
resolution: -> duplicate
status: open -> closed
superseder: -> total_ordering
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Changed stage and resolution to reflect the fact that none of the existing
patches adequately address the problem.
--
resolution: fixed ->
stage: committed/rejected -> needs patch
___
Python tracker
Changes by Nick Coghlan :
--
assignee: rhettinger -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
Reopening to track buildbot failures (at least on Windows) - at a glance, it
looks like the SSL socket wrapper is still adding (and trying to test) the
send/receivemsg methods even when they're missing from the socket object on the
current pla
Nick Coghlan added the comment:
Attached patch (ssl_fixes_v1) makes the presence of the sendmsg/recvmsg methods
in the ssl module conditional on their being present in the underlying socket
module.
However, in doing this, I noticed that these methods will, at best, work during
the time
Nick Coghlan added the comment:
That's the part I'm questioning though. I'm not clear why you'd ever do that
instead of doing everything on the original socket before invoking
ssl.wrap_socket.
What I missed on the original patch before committing it (mea culpa) is t
Nick Coghlan added the comment:
The buildbots are reporting a test failure on Windows:
==
FAIL: test_listmailcapfiles (test.test_mailcap.HelperFunctionTest
Nick Coghlan added the comment:
As you can see, I just pushed a change that removed the new methods from
SSLSocket objects. If anyone wants to step up with a valid use case (not
already covered by wrap_socket), preferably with a patch to add them back that
includes proper tests and
Nick Coghlan added the comment:
Regarding the 'missing methods' aspect, the SSL docs are already pretty clear
that SSLSocket objects don't expose the full socket API:
http://docs.python.org/dev/library/ssl#ssl-sockets
Those docs are actually what really got me started d
Nick Coghlan added the comment:
And the Windows buildbots are now happy (at least with respect to this change,
anyway - they're still griping about a few other issues).
I don't know if it's feasible to support these new APIs at the socket module
level on Windows, but any patc
Nick Coghlan added the comment:
Ah, cheers - closing this one again.
/me wanders off to meta-tracker to ask for a list of "dependency of" and
"superseder of" issues in the issue header...
--
status: open -> closed
__
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9923>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
stage: test needed -> patch review
versions: +Python 3.2, Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23018/7cead6bf5832.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list m
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file23018/7cead6bf5832.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bug
Nick Coghlan added the comment:
The diff generator didn't work - I've uploaded the current patch manually to
make it easier to review than it is in my bitbucket repo.
I just noticed there's a missing element in the docs patch at the moment - to
make testing easier, Rya
Nick Coghlan added the comment:
Casting to a flat 1-D array of bytes is reasonable (it's essentially saying
'look, just give me the raw data, it's on my own head if I stuff up the
formatting').
However, requiring an explicit two-step process for any other casting (i.e.
t
Nick Coghlan added the comment:
As Antoine said, good catch. I'll be able to incorporate this in the next
couple of days.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
301 - 400 of 6501 matches
Mail list logo
