New submission from Alexander Belopolsky:
This problem happens when I unpack a file from a 200+ MB zip archive as follows:
with zipfile.ZipFile(archive) as z:
data = b''
with z.open(filename, 'rU') as f:
for line in f:
data += line
I cannot redu
Changes by Alexander Belopolsky :
--
dependencies: +Add support for bzip2 compression to the zipfile module
keywords: +gsoc
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue20
Changes by Alexander Belopolsky :
--
keywords: +3.2regression -gsoc
nosy: +alanmcintyre
___
Python tracker
<http://bugs.python.org/issue20048>
___
___
Python-bug
Changes by Alexander Belopolsky :
--
keywords: -3.2regression
___
Python tracker
<http://bugs.python.org/issue20048>
___
___
Python-bugs-list mailing list
Unsub
Changes by Alexander Belopolsky :
--
components: +Library (Lib)
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue20048>
___
___
Python-
Alexander Belopolsky added the comment:
It does!
--
___
Python tracker
<http://bugs.python.org/issue20048>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
If "equivalent to" code is not considered to be part of documentation, then the
meaning of negative times should be documented.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
> Please reopen.
Please bring your case to python-ideas. All developers who commented on this
issue agree that it is invalid.
--
___
Python tracker
<http://bugs.python.org/issu
New submission from Alexander Belopolsky:
The rationale for making this change is that the current behaviour converts a
stylistic problem in checking values against a sentinel via "bool(value)"
instead of "value is not None" into a subtle data driven behavioural bug that
Changes by Alexander Belopolsky :
--
nosy: -belopolsky
___
Python tracker
<http://bugs.python.org/issue20855>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: -belopolsky
___
Python tracker
<http://bugs.python.org/issue13936>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I thought literal copying was enough of a hint to humor without a smiley in the
title.
--
___
Python tracker
<http://bugs.python.org/issue20
Alexander Belopolsky added the comment:
#20855 was meant as a joke, so I'll keep serious responses here.
Nick wrote:
"""
Alexander, my goal is to flip the default assumption in the time discussion. It
is clear from the documentation that the current behaviour is intention
Alexander Belopolsky added the comment:
Nick wrote:
> any deprecation warning should explain how to convert
> a time object to "seconds since midnight".
I would like to see such an explanation regardless of the outcome here.
The best I can think of is
timedelta(hours=t.hour,
Alexander Belopolsky added the comment:
> You're trying to count midnight as the previous day instead of the actual day?
yes
> That seems extremely contrived
Why? Midnight can be considered to be the last moment of the day or the first
moment of the day. In ISO standard there a
Alexander Belopolsky added the comment:
> If Midnight is considered the last moment of the day then it
> evaluating to false makes even less sense since the rationale
> given is "time is seconds since midnight".
You are erecting a straw-man. Python clearly considers time
Alexander Belopolsky added the comment:
> So in that case your example using midnight as false is even more
> confusing and even more wrong than not using ``is None`` on the
> conditional check.
I should have added that dt is a datetime instance and therefore dt.time() is
None is alw
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue20858>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
I would like to hear from PyPy developers before we decide what to do with this
effort. Pure Python implementation is not used by CPython,
but I am afraid that people who actually use it will not appreciate the code
churn.
--
nosy
Alexander Belopolsky added the comment:
Oh - I did not realize that this originated in PyPy.
--
___
Python tracker
<http://bugs.python.org/issue20858>
___
___
Changes by Alexander Belopolsky :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue20861>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
>I'd appreciate any pointers on how to get started
You probably know that the relevant code is in
http://hg.python.org/cpython/file/47f37a688c4c/Modules/_datetimemodule.c#l4059
The devguide should get you started:
http://docs.python.org/
Alexander Belopolsky added the comment:
> On Mar 7, 2014, at 10:12 AM, "R. David Murray" wrote:
>
> I asked about it on IRC and someone said it was because arithmetic on times
> was ambiguous because of timezones, and I just accepted that rather than
> wonder why i
Alexander Belopolsky added the comment:
> On Mar 7, 2014, at 10:15 AM, Antoine Pitrou wrote:
>
> Adding times of the day sounds as well-defined to me as adding
> centigrade temperatures.
What is wrong with adding temperatures? Climate people do it all the time when
computing
Alexander Belopolsky added the comment:
I think the timezone related problems are a red herring. Aware datetime +/-
timedelta arithmetics is naive - tzinfo is ignored in calculations and copied
to the result:
http://hg.python.org/cpython/file/c83ce2a1841c/Lib/datetime.py#l1711
The utcoffset
Alexander Belopolsky added the comment:
Does this patch fix issue1545463 by any chance? I am away from a
development box ATM and cannot test the patch myself.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue812
Alexander Belopolsky added the comment:
Just to give credit where credit is due: see #4 here
http://mail.python.org/pipermail/python-dev/2003-December/040579.html
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue7
New submission from Alexander Belopolsky :
Attached patch implements python-ideas proposal to return added or
existing element from set.add(). See
http://mail.python.org/pipermail/python-ideas/2009-October/006491.html .
In addition this patch contains a reimplementation of issue1507011 using
Alexander Belopolsky added the comment:
Any reason you don't want to call set_next from set_get?
I would say
static PyObject *
set_get(PySetObject *so)
{
register Py_ssize_t pos = 0;
register setentry *entry;
if (set_next(so, &pos, &entry)) {
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I agree, _PySet_Add name can be improved upon, but I don't want to paint
this particular bikeshed until it is clearer what if anything will be done
with this idea. If we add PySet_Intern API, then it would be natural to
expose it as set.intern r
Alexander Belopolsky added the comment:
On Wed, Nov 4, 2009 at 9:46 AM, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> If the idea is to create the "one obvious way" for interning, calling
> the method and corresponding C function "intern"
New submission from Alexander Belopolsky :
"""
intersection(...)
Return the intersection of two sets as a new set.
(i.e. all elements that are in both sets.)
"""
Is incorrect because set.intersection takes two or more sets.
Attached patch cha
Alexander Belopolsky added the comment:
I don't want to pollute python-dev with more hopeless ideas, but I wonder
if itertools could grow an efficient C-implemented
def first(collection):
return next(iter(collection))
On the other hand, it probably belongs to recipes more than s
Alexander Belopolsky added the comment:
On Thu, Nov 5, 2009 at 2:16 PM, Raymond Hettinger
wrote:
>
> Raymond Hettinger added the comment:
>
> The basic problem here is that the "one obvious way" to some people
> (including me and Martin v. Löwis) is to use a diction
Alexander Belopolsky added the comment:
On Thu, Nov 5, 2009 at 3:23 PM, Raymond Hettinger
wrote:
..
> Martin has already rejected a similar proposal for similar reasons.
> Please drop this one.
Sure. In fact I've never proposed to apply this patch. As I said in
my original subm
New submission from Alexander Belopolsky :
Attached zip archive can be run directly to reproduce the bug:
$ ./python.exe bug.zip
Traceback (most recent call last):
File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 162, in
_run_module_as_main
"__main__&
Alexander Belopolsky added the comment:
I am attaching a simple fix. The test for data format could be taken out
of the loop, but it is probably not worth complicating the logic. In any
case the real issue is whether profile and cProfile should produce
compatible output or not
Changes by Alexander Belopolsky :
--
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7372>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
Apparently this was introduced with r51625 :
r51625 | guido.van.rossum | 2006-08-26 16:37:44 -0400 (Sat, 26 Aug 2006)
| 4 lines
Inspired by SF patch #860326, make the exception formatting by
traceback.py be closer to the built-in formatting.
A few
Alexander Belopolsky added the comment:
It would be fairly easy to change format before dumping stats to disk,
but unfortunately Profile does not encapsulate it's run-time data and
changing its format would be a mess.
Of course, one can hack around that by turning Profile.stats into a
com
Alexander Belopolsky added the comment:
On Tue, Mar 10, 2009 at 5:15 PM, Tennessee Leeuwenburg
wrote:
..
> 2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g.
> td1 % td2). I think there is some debate here about whether the return
> value be an integer
Alexander Belopolsky added the comment:
I don't have a Solaris box to test at the moment, but I believe the
following commit fixed this issue:
r66283 | gregory.p.smith | 2008-09-07 01:15:18 -0400 (Sun, 07 Sep
2008
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17310/factorial.py
___
Python tracker
<http://bugs.python.org/issue8692>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17312/factorial3.py
___
Python tracker
<http://bugs.python.org/issue8692>
___
___
Python-bug
Alexander Belopolsky added the comment:
I agree, recursive version of partial_product is much simpler to follow. While
allocation of all numbers can be avoided in iterative version, doing so would
further complicate code with little benefit.
I still believe, however that an iterative
Alexander Belopolsky added the comment:
> I still believe, however that an iterative version can benefit ..
s/iterative/recursive/
--
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Mark, It is always a pleasure to read your algorithm descriptions!
Just a few comments:
- It would be nice if a pure python implementation would make it
somewhere in the code base. Maybe it can be placed in comments in C
file or added to the test
Alexander Belopolsky added the comment:
Some more ...
- Mark's notes talk about "odd-part-of-factorial". It would be
clearer if r variable in math_factorial() was called odd_part.
- I would also rename nminusnumbits to ntwos or something else that
explains what it is rather
Alexander Belopolsky added the comment:
On Sat, May 15, 2010 at 6:32 AM, Mark Dickinson wrote:
> New patch (factorial3.patch) addressing all of Alexander's points except the
> one about including Python source somewhere.
Thanks for making the changes. I think we converged to a
Alexander Belopolsky added the comment:
There is one place in the notes still referring to
factorial_part_product.
--
nosy: +Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue8
Alexander Belopolsky added the comment:
Sorry for terseness. Sending it from my phone.
The line was in factorial4.patch:
+ * The factorial_partial_product function computes the product of all
odd j in
>>
>
> Hmm. I can't find it. Can you be more specific?
>
>
Alexander Belopolsky added the comment:
s/partial_product/odd_part/
It looks like you made this change in some places but not all.
On May 15, 2010, at 11:16 AM, Mark Dickinson
wrote:
>
> Mark Dickinson added the comment:
>
> Okay, thanks. I'm still not seeing what&
Alexander Belopolsky added the comment:
Sorry I didn't realize that ...
--
___
Python tracker
<http://bugs.python.org/issue8692>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
stage: -> unit test needed
versions: +Python 3.2, Python 3.3 -Python 2.5
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Attached patch fixes the issue, but feels a little bit like a band-aid. I think
making array arguments "decay" into pointers is the right solution, but I am
not sure this should be done when prototype is created or when it is called.
If py
Changes by Alexander Belopolsky :
--
keywords: +needs review
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue1800>
___
_
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
dt.diff does not apply to current SVN version anymore. I am attaching a quick
update that does not change the actual calculation performed. See
issue1289118-py3k.diff.
I am still -1 for the reason I stated before, but I would like to review a
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue1436346>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
I think this should be rejected. The OP's premise was that t.timetuple()[7]
was unreadable, but in the modern python, the same can be written as
t.timetuple().tm_yday. The later is only slightly less readable than the
proposed t.yday().
Fo
Alexander Belopolsky added the comment:
On Fri, May 21, 2010 at 7:26 AM, STINNER Victor wrote:
..
>> ... If the tzinfo of the datetime object does not match the
>> system TZ used by mktime, the result will be quite misleading.
>
> Can you suggest a possible fix to take ca
Alexander Belopolsky added the comment:
On Fri, May 21, 2010 at 7:37 AM, Antoine Pitrou wrote:
..
> I agree with Victor that the APIs need improving, even if it involves
> providing obvious replacements of obscure one-liners.
While I agree that the datetime API can be improved, I don
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: -Alexander.Belopolsky
stage: -> unit test needed
versions: +Python 3.2 -Python 2.6, Python 3.0
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
On Fri, May 21, 2010 at 11:20 AM, Alexander Belopolsky
wrote:
..
> I believe it should be something like this:
>
> from claendar import timegm
s/claendar/calendar/, of course.
--
nosy: +Alexander.B
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
stage: -> unit test needed
type: -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
On Fri, May 21, 2010 at 12:20 PM, Antoine Pitrou wrote:
..
> Well, for example, the datetime module encourages you to use "aware" datetime
> objects (rather than so-called "naive" objects),
> but there isn't a single fa
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Thu, May 20, 2010 at 7:27 PM, Antoine Pitrou wrote:
>
>> .. The OP's premise was that
>> t.timetuple()[7] was unreadable, but in the modern python, the same
>> can be written as t.timetuple().tm_yday.
>
> Could I sugg
Changes by Alexander Belopolsky :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue1436346>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
Attaching a documentation patch.
--
Added file: http://bugs.python.org/file17446/issue1436346-doc.diff
___
Python tracker
<http://bugs.python.org/issue1436
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
components: +Documentation
keywords: +needs review
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue1
New submission from Alexander Belopolsky :
>From
><http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset>:
"""
tzinfo.utcoffset(self, dt)
Return offset of local time from UTC, in minutes east of UTC.
"""
This su
Alexander Belopolsky added the comment:
As far as I can tell, the TZ offset code can be simplified by eliminating
conversion from timedelta to int and back in utcoffset() and dst() methods of
time and datetime objects.
The only reason for the restriction that I can think of is that some text
Alexander Belopolsky added the comment:
I am attaching a patch that implements Mark's timedelta_arith.py algorithms in
C.
With rounding well defined, I am close to withdrawing my opposition to
supporting mixed timedelta with float operations. There is still one issue
that I belie
Alexander Belopolsky added the comment:
It looks like we have a consensus on the rounding mode. Note, however
that timedelta constructor rounds away from zero at least on
Intel/MacOS X:
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Should this be considered a bug
Alexander Belopolsky added the comment:
Indeed. Here is what I intended:
"""
>>> from datetime import timedelta as d
>>> [d(microseconds=i + .5)//d.resolution for i in range(-10,10)]
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Alexander Belopolsky added the comment:
I have two questions about the proposed implementation:
1. Why not follow pytz lead and expose an instance of UTC rather than the UTC
class itself?
2. Is there a real need to add a boolean argument to utcnow()? I think
timedelta.now(UTC()) or with
Alexander Belopolsky added the comment:
On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote:
..
> On 2, we had discussions about how to pass parameters in to utcnow that we
> DID record. When I
> suggested it, Brett said:
>
> "...using a boolean flag over an argumen
Alexander Belopolsky added the comment:
> We didn't do a singleton because I don't like singletons. =) Plus they
> muck with isinstance/issubclass if you don't expose the class.
I am not sure what you mean by "muck with." Why would anyone want to subclass
UTC
Alexander Belopolsky added the comment:
> By the way, does your patch do the right thing for
> timedelta(microseconds=1) / -4.0
No.
>>> timedelta(microseconds=1) / -4.0
datetime.timedelta(-1, 86399, 99)
(I just copied your python algorithm ...)
I will merge with issue
Alexander Belopolsky added the comment:
Attaching a combined issue1289118 + issue8817 patch. Datetime code now uses
issue8817's _PyLong_Divmod_Near.
--
Added file: http://bugs.python.org/file17460/issue1289118+issue8817-nodoc.diff
___
P
Alexander Belopolsky added the comment:
Just a few nitpicks on the patch (in increasing pickiness):
1. Any reason to prefer PyTuple_SetItem to PyTuple_SET_ITEM at the end of
_PyLong_Divmod_Near? You are filling a brand new tuple, so PyTuple_SET_ITEM
seems to be more appropriate.
2. temp
Alexander Belopolsky added the comment:
On Tue, May 25, 2010 at 5:45 AM, Antoine Pitrou wrote:
..
> I also agree with Brett that a singleton looks rather unnecessary (it
> also look quite C++/Java-esque to me).
>
I still don't understand your aversion to singletons and you did n
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue665194>
___
___
Python-bugs-lis
Alexander Belopolsky added the comment:
If concrete tzinfo subclass is added to datetime module (see issue5094), it
will become feasible to meaningfully parse timezone information.
--
assignee: -> belopolsky
___
Python tracker
&l
Alexander Belopolsky added the comment:
On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote:
..
> I had originally thought of doing the class, and then having constants
> associated with it:
>
> UTC.UTC0
>
> Eventually if we support multiple timezones:
>
> UTC.UTC1
Alexander Belopolsky added the comment:
..
Thanks for the explanation. I realize that I should not have used the
s-word. :-) In fact I only wanted a module level constant utc = UTC()
and did not care much about other UTC class instances and whether any
are permitted or easy to create.
Well
Alexander Belopolsky added the comment:
Roundup bug bites again. Reposting via web:
-
On Tue, May 25, 2010 at 5:35 PM, Brett Cannon wrote:
>
> The singleton dislike from Antoine and me is that they are generally just not
> liked in the stdlib.
..
Thanks for the explanation.
Alexander Belopolsky added the comment:
Note that Brett has already mentioned backward compatibility issues, but
suggested that "[adding tz_aware argument may provide] a transition plan to
make utcnow() always return a timezone-aware datetime object." [msg106413]
I would say,
Alexander Belopolsky added the comment:
Looking at
Py_DECREF(one);
result = PyTuple_New(2);
if (result == NULL)
goto error;
..
error:
Py_XDECREF(one);
If PyTuple_New fails, wouldn't it result in one being DECREF
Alexander Belopolsky added the comment:
Attaching a new patch with documentation changes, additional tests, updated
issue8817 patch and a reference leak fix.
--
Added file: http://bugs.python.org/file17464/issue1289118+issue8817-withdoc.diff
Alexander Belopolsky added the comment:
Brett: "[utcnow] should at least get deprecated with a message saying that
people should be using ``now(utc)``"
Yes, I believe all utcxxx methods of datetime are a kludge due to the lack of
concrete UTC tzinfo:
utcfromtimestamp() -> from
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5023>
___
___
Python-bugs-lis
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue7584>
___
___
Python-bugs-lis
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
MonthDelta has been published on PyPI and there was no activity on this issue
since then. I conclude that there is little support for including this in
stdlib. I am marking this as "rejected" and setting the status to pending. I
will close
Alexander Belopolsky added the comment:
I have no opinion on the first question. I would be fine with a simple "soft"
deprecation where we simply add a note in documentation warning that these
methods create naive datetime instances and it is preferable to use aware
variants p
Alexander Belopolsky added the comment:
I am leaning towards "won't fix". Any objections?
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
versions: -Python 2.5, Python 2.6
___
Python tracker
<http://bugs
2201 - 2300 of 3596 matches
Mail list logo