Senthil Kumaran added the comment:
Georg: Thanks for spotting. I feel bad for the mistake. I shall correct it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18553
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19044
___
___
Python-bugs-list mailing
New submission from Borut Podlipnik:
# make
CC -c -g -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o
Modules/python.o ./Modules/python.c
CC -c -g -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o
Parser/acceler.o Parser/acceler.c
CC -c -g -DNDEBUG -O -I. -IInclude
Roundup Robot added the comment:
New changeset 2b7f11ba871c by Senthil Kumaran in branch '3.3':
Correcting the mistake in 14ba90816930
http://hg.python.org/cpython/rev/2b7f11ba871c
New changeset e839e524a7d5 by Senthil Kumaran in branch 'default':
Correcting the mistake in 678e3c0d2d99
Senthil Kumaran added the comment:
Fixed now. Ascertained myself by doing hg diff -r tip^ -U 10 on local commits
before pushing. :-)
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18553
New submission from Michael Herrmann:
I'm on 32 bit Python 2.7.3 and 64 bit Windows 7. I am working on a complex,
multithreaded application which uses COM to communicate with other processes.
My application uses regular expressions in a few (but not very many) places. An
example re I am
Changes by Balazs czv...@gmail.com:
--
nosy: +balazs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19044
___
___
Python-bugs-list mailing list
New submission from Nick Coghlan:
I was just looking at weakref.finalize objects trying to figure out if they
solve a problem I'm thinking about (they do), and I couldn't figure out from
the class documentation ([1]) whether or not I needed to take care of keeping
the object returned from
Nick Coghlan added the comment:
Changing the title, since I spotted a few other problems as well.
The weakref docs still refer to module globals being set to None during
shutdown. That is no longer the case. There are also some assumptions about
cycles with __del__ methods not being garbage
New submission from Antoine Pitrou:
An itertools.tee object can cache an arbitrary number of objects (pointers),
but its sys.getsizeof() value will always remain the same.
--
components: Library (Lib)
messages: 198048
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
New submission from Antoine Pitrou:
itertools.tee uses ints rather than Py_ssize_t for indices. Using Py_ssize_t
would not make the object bigger, since other fields will already be
pointer-aligned.
--
messages: 198049
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
Antoine Pitrou added the comment:
I find the implementation of itertools.tee a bit weird: why does teedataobject
have to be a PyObject? It seems to complicate things and make them less optimal.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Anywhere, here is a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file31813/tee_sizeof.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
Serhiy Storchaka added the comment:
This is a duplicate of issue15475.
--
superseder: - Correct __sizeof__ support for itertools
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
___
Serhiy Storchaka added the comment:
Hmm, no, I'm wrong, it's not a duplication.
--
superseder: Correct __sizeof__ support for itertools -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
___
___
Serhiy Storchaka added the comment:
I'm not sure that sys.getsizeof() should recursively count all Python
subobjects. That is why I had omitted tee() in my patch.
sys.getsizeof([[]])
36
sys.getsizeof([list(range(1))])
36
--
___
Python tracker
Antoine Pitrou added the comment:
I'm not sure that sys.getsizeof() should recursively count all Python
subobjects.
Those are private subobjects. They are not visible to the programmer
(except perhaps by calling __reduce__ or __setstate__).
--
___
Antoine Pitrou added the comment:
Is there any reason why you don't switch to 2.7.5 and let your application run
longer?
(FWIW, this may be issue #16602)
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19046
Antoine Pitrou added the comment:
Doc patches certainly welcome :-)
--
nosy: +pitrou, sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19047
___
Antoine Pitrou added the comment:
Looks good to me. Python 1.5.2 (which I've never used) is the best Python
anyway!
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19043
___
Antoine Pitrou added the comment:
Simple patch attached.
--
keywords: +patch
Added file: http://bugs.python.org/file31814/tee_64b.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19049
Antoine Pitrou added the comment:
Ideally, test specification should be separate from test execution. That is, it
should be possible to keep the TestCase around (or whatever instantiates it,
e.g. a factory) but get rid of its per-test-execution attributes.
Perhaps restoring the original
Serhiy Storchaka added the comment:
Thy are visible by calling gc.get_referents(). High-level function can use this
to count recursive size of objects.
import sys, gc, itertools
def gettotalsizeof(*args, seen=None):
... if seen is None:
... seen = {}
... sum = 0
... for
Michael Foord added the comment:
That would only be a shallow copy, so I'm not sure it's worth the effort. The
test has the opportunity in the setUp to ensure that initial state is correct -
so I would leave that per test. Obviously sharing state between tests is prima
facie bad, but any
Changes by Florent Rougon frou...@users.sourceforge.net:
--
nosy: +frougon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12944
___
___
New submission from Daniel Rohlfing:
This snippet let my interpreter crash immediately:
import sys, io
io.open(sys.stdout.fileno(), 'wb')
fd.close()
sys.stdout.write(now writing on stdout will cause a crash)
That's happened on
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32
Daniel Rohlfing added the comment:
the correct snippet is:
fd = io.open(sys.stdout.fileno(), 'wb')
fd.close()
sys.stdout.write(now writing on stdout will cause a crash)
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Thy are visible by calling gc.get_referents().
That's totally besides the point. The point is that those
objects are invisible in normal conditions, not that they can't
be read using advanced implementation-dependent tricks.
--
Antoine Pitrou added the comment:
That would only be a shallow copy, so I'm not sure it's worth the
effort. The test has the opportunity in the setUp to ensure that
initial state is correct - so I would leave that per test.
I don't understand your objection. The concern is to get rid of old
Nick Coghlan added the comment:
I was initially thinking to myself I have a source checkout right
here, I should just fix it, even though I'm at work and want to go
home... and then I realised the potential scope of the fixes needed,
given the longstanding misbehaviours these docs assume still
Michael Foord added the comment:
On 19 Sep 2013, at 14:06, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
That would only be a shallow copy, so I'm not sure it's worth the
effort. The test has the opportunity in the setUp to ensure that
initial state is
Antoine Pitrou added the comment:
If the object state includes mutable objects then restoring the
previous dictionary will just restore the same mutable (and likely
mutated) object.
I don't understand what you're talking about. Which mutable objects
exactly? I'm talking about copying the
Serhiy Storchaka added the comment:
The point is that your patch breaks functions like gettotalsizeof(). It makes
impossible to get a total size of general object.
It will be better to add gettotalsizeof() to the stdlib (or add an optional
parameter to sys.getsizeof() for recursive counting).
Michael Foord added the comment:
Ah right, my mistake. Before setUp there shouldn't be test state. (Although
tests are free to do whatever they want in __init__ too and I've seen plenty of
TestCase subclasses using __init__ when they should be using setUp.)
Essentially though _cleanup is a
Antoine Pitrou added the comment:
That said, I agree that the __dict__ proposal is a hack, but as is the current
_removetestAtIndex mechanism.
The only clean solution I can think of would be to have two separate classes:
- a TestSpec which contains execution-independent data about a test case,
Antoine Pitrou added the comment:
The point is that your patch breaks functions like gettotalsizeof().
It makes impossible to get a total size of general object.
The thing is, Total size is generally meaningless. It can include
things such as the object's type, or anything transitively
Drekin added the comment:
Hello, I have run into this when I wanted to use OrderedEnum and the example in
enum docs seemed too repetitive to me. It's nice to know that it's being worked
on.
--
nosy: +Drekin
___
Python tracker rep...@bugs.python.org
New submission from Serhiy Storchaka:
There are some classes in gzip, bz2, lzma, and zipfile modules which implement
buffered reader interface. They read chunks of data from underlied file object,
decompress it, save in internal buffer, and provide common methods to read from
this buffer.
Michael Foord added the comment:
Having TestLoader.loadTestsFromTestCase() return a lazy suite that defers
testcase instantiation until iteration is a nice idea.
Unfortunately the TestSuite.addTests api iterates over a suite to add new
tests. i.e. the code that builds a TestSuite for module
Serhiy Storchaka added the comment:
Here are benchmark script and its results.
--
Added file: http://bugs.python.org/file31816/read_bench.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19051
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file31817/read_bench_cmp
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19051
___
Antoine Pitrou added the comment:
See issue12053 for a more flexible primitive.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19051
___
___
Dmi Baranov added the comment:
I found a little difference in isatty implementaions:
Windows
Determines whether a file descriptor is associated with a character device [1]
Unix
Test whether a file descriptor refers to a terminal [2]
So, we having a same behavior for pipes, but different for
New submission from Serhiy Storchaka:
Bzip2 is block-based compression with large (up to 800 Kb) size of block. It
means that while decompressor not read enough data it can't produce any output
(actually this issue exists for other compression algorithms too, but less
frequent). And the
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +orsenthil
type: performance - enhancement
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.5
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Unfortunately the TestSuite.addTests api iterates over a suite to add
new tests. i.e. the code that builds a TestSuite for module probably
already iterates over the suites returned by
TestLoader.loadTestsFromTestCase - so the change would need to be
more
Serhiy Storchaka added the comment:
This primitive doesn't not well fit a case of compressed streams. A chunk of
compressed data read from underlied file object can be uncompressed to
unpredictable large data. We can't limit the size of buffer.
Another point is that buffer interface is not
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12053
___
___
New submission from Joseph Warren:
I will add as a disclaimer to this bug report that I am relatively new to both
the http spec, and Python programming, so I may have completely misunderstood
something.
When I make a post request with some data (using libCurl), It sends the headers
first,
Senthil Kumaran added the comment:
Hello Dmi,
I having a snippet to fix that, should I open a new issue for patch?
Please open a new issue.
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18553
R. David Murray added the comment:
See also issue 1346874. It seems that we do not currently handle 'continue'
correctly in general.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19052
Serhiy Storchaka added the comment:
This primitive doesn't not well fit a case of compressed streams. A chunk of
compressed data read from underlied file object can be uncompressed to
unpredictable large data. We can't limit the size of buffer.
Another point is that buffer interface is not
Changes by Serhiy Storchaka storch...@gmail.com:
--
Removed message: http://bugs.python.org/msg198083
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19051
___
Amaury Forgeot d'Arc added the comment:
I like the definition of __sizeof__ that was discussed some time ago:
http://bugs.python.org/issue14520#msg157798
With that definition (do we have it somewhere in the docs, by the way?)
The current code works gives the correct answer.
--
nosy:
Serhiy Storchaka added the comment:
Isn't sys.getsizeof() a low-level debugging tool?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
___
Joseph Warren added the comment:
Cheers, would you suggest I submit a patch then?
Also what version of python should I do this against? I've been working with
2.7, but the issue still exists in 3.* and I can conveniently work against
3.2.3-7, and less conveniently work against other versions.
R. David Murray added the comment:
I think we can fix this in maintenance releases without breaking anyone's code,
so a patch against both 2.7 and 3.3 would be ideal. A patch against 3.2 will
probably apply cleanly to 3.3, so that should be fine as well.
Thanks for working on this, and could
Serhiy Storchaka added the comment:
I don't think we need Py_ssize_t for integers from 0 to 57.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19049
___
New submission from Marco Buttu:
I think in the descriptor howto, at this point:
class MyClass(object):
x = RevealAccess(10, 'var x')
y = 5
or the prompt should not have been, or there is a wrong indentation.
Furthermore, in Python 3:
http://docs.python.org/3/howto/descriptor.html
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19053
___
___
Serhiy Storchaka added the comment:
Here is a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file31819/zipfile_read1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19053
Antoine Pitrou added the comment:
Isn't sys.getsizeof() a low-level debugging tool?
What would it help debug exactly? :-)
I would hope it gives remotely useful information about the passed
object.
--
___
Python tracker rep...@bugs.python.org
Changes by Marco Buttu marco.bu...@gmail.com:
Added file: http://bugs.python.org/file31821/py2howto.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19054
___
Amaury Forgeot d'Arc added the comment:
getsizeof() is interesting only if it gives sensible results when used
correctly, especially if you want to sum these values and get a global memory
usage.
One usage is to traverse objects through gc.get_referents(); in this case the
definition above
Changes by Marco Buttu marco.bu...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file31820/py3howto.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19054
___
Antoine Pitrou added the comment:
Ah, my bad, it seems I misunderstood the tee() implementation. So apparenly
even index cannot get past 57. It's more of a consistency patch then, and I
agree it isn't very important.
--
priority: normal - low
stage: needs patch - patch review
title:
Serhiy Storchaka added the comment:
Well. itertools._tee is one Python object and itertools._tee_dataobject is
another Python object. sys.getsizeof() gives you the memory usage of this
objects separately.
--
___
Python tracker
Serhiy Storchaka added the comment:
How do you stop walking your graph if it spans the whole graph of Python
objects?
We can stop at specific types of objects (for example types and modules).
If sys.getsizeof() is only useful for people who know *already* how an
object is implemented
Antoine Pitrou added the comment:
Here is why using get_referents() is stupid in the general case:
class C: pass
...
c = C()
gc.get_referents(c)
[class '__main__.C']
With your method, measuring c's memory consumption also includes the memory
consumption of its type object.
(and of course
Antoine Pitrou added the comment:
(By the way, OrderedDict.__sizeof__ already breaks the rule you are trying to
impose)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19048
___
Antoine Pitrou added the comment:
Well. itertools._tee is one Python object and
itertools._tee_dataobject is another Python object. sys.getsizeof()
gives you the memory usage of this objects separately.
This is great... And how do I know that I need to use gc.get_referents()
to get those
Antoine Pitrou added the comment:
I don't think we need Py_ssize_t for integers from 0 to 57.
IMO it's better to use Py_ssize_t there, since it can get combined with
other Py_ssize_t values. Avoiding spurious conversions eliminates a
common source of errors. We don't gain anything by keeping
Antoine Pitrou added the comment:
It's why sys.getsizeof() is a low-level tool. We need high-level tool
in the stdlib. Even imperfect recursive counting will be better than
confusing for novices sys.getsizeof().
Ok, but I need to see a satisfying version of gettotalsizeof before
I'm
Augie Fackler added the comment:
I'd like to put a nudge towards supporting the __mod__ interface on bytes - for
Mercurial this is the single biggest impediment to even getting our testrunner
working, much less starting the porting process.
--
nosy: +durin42
Serhiy Storchaka added the comment:
Optionally we can also not count objects which are referenced from outside of a
graph of objects (this isn't so easy implement in Python). I.e.
gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True) will count only bare list
and a square of 22, because 1 and
Martin v. Löwis added the comment:
The problem is that that definition isn't helpful.
If we ever change itertools.tee to use non-PyObjects internally, s
suddenly its sys.getsizeof() would have to return much larger numbers
despite visible behaviour not having changed at all (and despite the
Antoine Pitrou added the comment:
I see no problem with that. If the internal representation changes,
nobody should be surprised if sizeof changes.
Who is nobody? Users aren't aware of internal representation changes.
It sounds like you want sys.getsizeof() to be a tool for language
Antoine Pitrou added the comment:
Optionally we can also not count objects which are referenced from
outside of a graph of objects (this isn't so easy implement in
Python). I.e. gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True)
will count only bare list and a square of 22, because 1 and
Antoine Pitrou added the comment:
getsizeof() is interesting only if it gives sensible results when used
correctly, especially if you want to sum these values and get a global
memory usage.
Getting a global memory usage isn't a correct use of getsizeof(),
though, because it totally ignores
Antoine Pitrou added the comment:
I doubt we should change this.
Currently itertools.tee() will break if more than 2**31 elements are
saved in the inner structures. I certainly think it should be fixed,
rather than bite someone by surprise one day.
However in any case you forgot about
Serhiy Storchaka added the comment:
We gain stability.
I doubt we should change this. However in any case you forgot about
tee_reduce().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19049
Joseph Warren added the comment:
Issue1346874 seems similar, but is talking about a failure to handle 100
Continue responses sent by a server to the client, this issue is in server
code, and is a failure of BaseHttpServer to send 100 Continue responses to a
client which expects them.
Please
R. David Murray added the comment:
You are making perfect sense. My point in referencing that issue was that you
are not crazy, we do indeed not handle continue correctly ;)
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
I like the definition of __sizeof__ that was discussed some time ago:
http://bugs.python.org/issue14520#msg157798
The problem is that that definition isn't helpful.
If we ever change itertools.tee to use non-PyObjects internally, suddenly
its sys.getsizeof()
Antoine Pitrou added the comment:
I wanted to set issue10915 as duplicate but there is actually a tentative patch
there. Unfortunately the discussions are now split apart...
--
___
Python tracker rep...@bugs.python.org
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15751
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10915
___
___
Python-bugs-list
New submission from Jason Stumpf:
re.match('(a|ab)*',('aba')).group(0)
'a'
According to the documentation, the * should match as many repetitions as
possible. 2 are possible, it matches 1.
Reversing the order of the operands of | changes the behaviour.
re.match('(ab|a)*',('aba')).group(0)
Changes by Jason Stumpf jstu...@google.com:
--
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19055
___
Changes by David Benbennick dbenb...@gmail.com:
--
nosy: +dbenbenn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19055
___
___
Python-bugs-list
Joseph Warren added the comment:
Have downloaded an up to date version of Python to develop with, and found that
this issue had been fixed in it. This seems to have been done in changeset:
65028:7add45bcc9c6
changeset: 65028:7add45bcc9c6
user:Senthil Kumaran orsent...@gmail.com
Joseph Warren added the comment:
Sorry, this change does appear in 2.7.* I was looking at the wrong mercurial Tag
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19052
___
Changes by Joseph Warren hungryjoe.war...@gmail.com:
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19052
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19055
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19055
___
___
janzert added the comment:
The documentation on the | operator in the re module pretty explicitly covers
this. http://docs.python.org/2/library/re.html
A|B, where A and B can be arbitrary REs, creates a regular expression that
will match either A or B. An arbitrary number of REs can be
Jason Stumpf added the comment:
Even with the documentation to |, the documentation to * is wrong.
re.match('(a|ab)*c',('abac')).group(0)
'abac'
From the doc: In general, if a string p matches A and another string q matches
B, the string pq will match AB.
Since '(a|ab)*c' matches 'abac',
Jason Stumpf added the comment:
Sorry, that implication was backwards. I don't think I can prove from just the
documentation that '(a|ab)*' can match 'aba' in certain contexts.
If the docs said: * attempts to match again after each match of the preceding
regular expression. I think it would
Matthew Barnett added the comment:
The behaviour is correct.
Here's a summary of what's happening:-
First iteration of the repeated group:
Try the first branch. Can match a.
Second iteration of the repeated group:
Try the first branch. Can't match a.
Try the second branch.
1 - 100 of 109 matches
Mail list logo
