Alexander Belopolsky added the comment:
On Mon, Sep 12, 2011 at 4:30 PM, Jakob Malm wrote:
..
> I created a patch with the revised wording.
Your patch seems to reflow the entire paragraph which makes it hard to
review and if applied will appear as a bigger change than it is. Can
Alexander Belopolsky added the comment:
On Mon, Sep 12, 2011 at 4:36 PM, anatoly techtonik
wrote:
..
> 5. Mention the fact: By default all objects are "naive", by definition,
> because they don't have any
> TZ information, and there are no classes in stdlib that provi
Alexander Belopolsky added the comment:
-There are two kinds of date and time objects: "naive" and "aware". This
+Date and time objects are either "naive" or "aware". This
Shouldn't we say "datetime and time" instead of "
Alexander Belopolsky added the comment:
On Thu, Sep 15, 2011 at 4:17 PM, anatoly techtonik
wrote:
..
> Does that mean that if aware `datetime` is converted to `date` and
> then back, the tzinfo information is lost and object implicitly
> becomes naive?
Yes, but one cannot convert &q
Alexander Belopolsky added the comment:
Isn't this a duplicate of #10653? In any case, this looks like a windows only
issue, so I cannot move it further. Would be interested in resolution, though.
Thanks for making me nosy.
--
nosy: +ocean
Changes by Alexander Belopolsky :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue10254>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue12729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
This new data does not crash Python 2.7.2, so I assume the issue has been
fixed. Re-closing.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
I am not sure this can be fixed without distributing our own implementation of
strftime. See issue 3173.
--
dependencies: +external strftime for Python?
___
Python tracker
<http://bugs.python.org/issue13
Alexander Belopolsky added the comment:
Is 3.3 message better?
>>> datetime.now(tz=X())
Traceback (most recent call last):
File "", line 1, in
ValueError: offset must be a timedelta strictly between -timedelta(hours=24)
and timedelta(hours=24).
In 2.7, the message i
Alexander Belopolsky added the comment:
I'll try to give this a more thorough review by the end of the week. For now,
just a nit-pick, but _calc_julian_from_V jumped at me as a really odd name.
Either "iso_to_julian" or "julian_from_iso" would be much clearer. Th
Alexander Belopolsky added the comment:
On Wed, May 25, 2011 at 6:28 PM, Ashley Anderson wrote:
>
> .. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a
> similar helper function's
> name ('_calc_julian_from_U_or_W'), but perhaps t
Alexander Belopolsky added the comment:
On Thu, May 26, 2011 at 9:44 AM, R. David Murray wrote:
..
> Documentation is in the Doc subdirectory of a checkout, and is in the form of
> *.rst files. Modify the appropriate .rst file,
More specifically, strftime/strptime directives are liste
Alexander Belopolsky added the comment:
On Thu, May 26, 2011 at 12:07 PM, Ashley Anderson
wrote:
> I think this should be fixed by implementing the %G directive (ISO year,
> which is present in strftime) as well.
Correct.
--
___
Python t
Alexander Belopolsky added the comment:
The patch looks good. A nit-pick:
+if len(parts) > 0:
Since *parts* is a list, the above can be replaced with simply "if parts:".
Also, it seems to me that the new code may produce an AttributeError when given
invalid nam
Alexander Belopolsky added the comment:
On Fri, May 27, 2011 at 12:23 PM, Éric Araujo wrote:
> .. I’ll add tests and see if I can reproduce what you’re hinting at (it would
> be helpful
> if you could give examples of invalid names: full dotted names, method names,
> class nam
Alexander Belopolsky added the comment:
On Fri, Jun 3, 2011 at 3:57 PM, Martin v. Löwis wrote:
..
> I suggest that rather than using composite time stamps, decimal.Decimal is
> used to represent high-precision time in Python.
I support this idea in theory, but as long as deci
Alexander Belopolsky added the comment:
On Fri, Jun 3, 2011 at 6:13 PM, Martin v. Löwis wrote:
..
>> I support this idea in theory, but as long as decimal is implemented
>> in Python, os module should probably expose a low level (tuple-based?)
>> interface and a higher
Alexander Belopolsky added the comment:
On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis wrote:
..
>> One reason is the desire to avoid loading Python module from a
>> C-module.
>
> This desire is indeed no guidance for Python development; the opposite
> is the case.
Can
Alexander Belopolsky added the comment:
This is actually a duplicate of issue7915.
I don't think there is nothing we can do to improve the situation. In fact
discussion at #11949 ends with a +0 from Mark Dickinson to issue a warning
whenever nans participate in order comparison. Discu
Alexander Belopolsky added the comment:
On Sun, Jun 26, 2011 at 8:23 AM, Martin v. Löwis wrote:
..
>> I understand that it is an issue of the datetime module. Can it be
>> solved, or is there a design issue in the module?
>
> It's an inherent flaw of broken-do
Alexander Belopolsky added the comment:
The code review links point to something weird. Victor, can you upload your
patch for review?
My first impression is that your patch does not accomplish much beyond
replacing some literal expressions with macros. What I wanted to achieve with
this
Alexander Belopolsky added the comment:
> Return the local time as a floating point number
> expressed in seconds since the epoch.
No. Seconds since the epoch is neither local nor UTC. It is just an elapsed
number of seconds since an agreed upon time called the "epoch"
Alexander Belopolsky added the comment:
> i.e. it appears that replace() applies the TZ offset to a naive datetime
> object effectively assuming it is local time rather than un-timezoned
> (which is what the docs imply to me)
I don't understand your issue. The replace method d
Alexander Belopolsky added the comment:
> it would appear the problem lies with strftime()
Yes, strftime('%s') ignores tzinfo at the moment. This is not a bug. Support
for '%s' format code is incidental and not documented in Python.
Nevertheless I think this is a good
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue12757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
You can easily get the fractional day value using existing functionality:
>>> from datetime import *
>>> (datetime(2011,8,15,18,30) - datetime(2011,8,13,12,0)) / timedelta(1)
2.27083335
>>> (datetime(2011,8,15,
Alexander Belopolsky added the comment:
On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings wrote:
..
> I think a pair of integers is a poor API. It ties the value of the
> fractional part to nanoseconds. What happens
> when a future filesystem implements picosecond resolution?
I
Alexander Belopolsky added the comment:
On Fri, Sep 9, 2011 at 5:22 PM, Alexander Belopolsky
wrote:
..
> If history repeats, struct stat will grow new st_xtimesuperspec
> fields, st_xtimespec will become a macro expanding to
> st_xtimesuperspec.tv_picosec
On the second thought, t
Alexander Belopolsky added the comment:
On Fri, Sep 9, 2011 at 5:42 PM, Larry Hastings wrote:
..
> How is this superior to using either Decimal or float128?
It is explicit about the units of time used. If we use named tuples
and retain C API field names, stat_result.tv_atimespec.tv_sec w
Alexander Belopolsky added the comment:
On Fri, Sep 9, 2011 at 6:18 PM, Larry Hastings wrote:
..
> I've drawn an ASCII table summarizing the proposals so far.
You did not mention "closely matches C API" as an upside.
--
___
Pyt
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file18472/issue665761-py3k.diff
___
Python tracker
<http://bugs.python.org/issue665761>
___
___
Pytho
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue2443>
___
___
Python-
Alexander Belopolsky added the comment:
I updated the patch for 3.x. I agree that using va_copy where available makes
sense, but let's leave this type of improvements for the future.
--
Added file: http://bugs.python.org/file18477/issue2443-py3k
Alexander Belopolsky added the comment:
Committed in r83949.
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
> How can this be worked around, short of placing the fork()
> in the main module?
Why wouldn't you place the fork() call in a function?
--
nosy: +belopolsky
___
Python tracker
<http://b
Alexander Belopolsky added the comment:
On Wed, Aug 11, 2010 at 10:56 PM, Alex Roitman wrote:
>
> Alex Roitman added the comment:
>
> I can place it in a function. But if I execute that function from anything
> other than main
> module, the fork() will be called while i
Changes by Alexander Belopolsky :
--
nosy: -belopolsky
___
Python tracker
<http://bugs.python.org/issue9573>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
Removed message: http://bugs.python.org/msg113654
___
Python tracker
<http://bugs.python.org/issue9573>
___
___
Python-bug
Alexander Belopolsky added the comment:
Current behavior is also consistent with that of fractions:
>>> Fraction("1/2")
Fraction(1, 2)
>>> Fraction("1 / 2")
Traceback (most recent call last):
..
ValueError: Invalid literal for Fraction: '1 / 2&#
Alexander Belopolsky added the comment:
I did some experimentation and found some inconsistency between int and complex:
>>> int('\xA11')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf8' codec can't decode byte
New submission from Alexander Belopolsky :
>>> int('\xA11')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa1 in position 0: invalid
start byte
This is inconsistent with other number ty
Alexander Belopolsky added the comment:
Can someone post a diff against current py3k? I would like to take a look,
but the files attached to this issue seem to be more than a year old.
--
___
Python tracker
<http://bugs.python.org/issue2
Alexander Belopolsky added the comment:
Note directly related to this issue, but untabify.py fails on files that
contain non-ascii characters. For example:
$ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c
Traceback (most recent call last):
...
(result, consumed) = self
New submission from Alexander Belopolsky :
For example:
$ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c
Traceback (most recent call last):
...
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't deco
Changes by Alexander Belopolsky :
--
dependencies: +untabify.py fails on files that contain non-ascii characters
___
Python tracker
<http://bugs.python.org/issue7
Changes by Alexander Belopolsky :
--
nosy: +eric.araujo
___
Python tracker
<http://bugs.python.org/issue9598>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I opened issue9598 for the untabify bug. For the purposes of source checking,
I believe non-ascii characters should be disallowed in python C source code.
According to my understanding of C89 standard, interpretation of characters
outside of the
Changes by Alexander Belopolsky :
--
resolution: -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
Committed to py3k in r84098. Accepting this change for py3k was an easy
decision to make because zip and map already behave this way in 3.x.
I am inclined to reject this for 2.7, however. While I agree that this is a
bug, fixing it has a potential
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue1581183>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue998998>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Committed in r84106. I left the __init__ docstring issue unresolved because it
is orthogonal to the name.__doc__ vs. help(name) issue here.
With redundant help(type(x)), the meaning of the docstring is not changed. I am
leaving docstrings on magic
Alexander Belopolsky added the comment:
Can someone post a script demonstrating the proposed feature? Is "clones of
clones" issue mentioned by OP resolved in the latest patch?
Given that nobody commented on this issue for 7 years, I am skeptical about the
utility of th
Alexander Belopolsky added the comment:
Is anyone still interested in moving this forward?
--
___
Python tracker
<http://bugs.python.org/issue1100942>
___
___
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18568/unnamed
___
Python tracker
<http://bugs.python.org/issue1524938>
___
___
Python-bug
Alexander Belopolsky added the comment:
This is superseded by issue812369, but as a stop-gap measure, I don't see any
downside of applying gc-import.patch.
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
> Is there any reason not to include the strftime formatting codes
> in the docstrings of time.strftime and time.strptime?
I believe the reason is that time.strftime behavior is platform dependent, so
"man strftime" is likely to produ
Alexander Belopolsky added the comment:
> there are even two websites dedicated to these options:
> http://strftime.org/ ...
Note the source at one of these sites:
"Source: Python’s strftime documentation." :-)
--
___
Pytho
Alexander Belopolsky added the comment:
> If untabify fails because a file has an incorrect encoding, is it really
> a problem in untabify? This is a developer’s tool, so getting a
> traceback here seems okay to me.
I disagree. I think we should use this opportunity to clarify
Alexander Belopolsky added the comment:
> I wouldn’t want to see names of authors/contributors mangled
> in the source.
This is a reason to write names in ASCII. While Latin-1 is a grey area
because most of it's characters look familiar to English-speaking developers, I
don&
Alexander Belopolsky added the comment:
>From IRC:
Me: UTF-8 was not strictly valid in ANSI C comments, so it is a bug in untabify
to assume UTF-8 in C files.
Merwok: Works for me.
I am lowering the priority because it looks like untabify does not fail on the
current code base. I
Alexander Belopolsky added the comment:
On Tue, Sep 7, 2010 at 8:08 PM, Éric Araujo wrote:
..
> Why would it be the job of untabify to report invalid non-ASCII characters in
> C files?
>
Since untabify works by loading C code as text, it has to assume some
encoding. Failing with
Alexander Belopolsky added the comment:
On Tue, Sep 7, 2010 at 8:31 PM, Éric Araujo wrote:
..
> My real question was: Shouldn’t this be a VCS hook instead of untabify’s job?
> (or in addition to untabify if you insist)
>
Yes, VCS hook makes sense (and may almost eliminate the need
Alexander Belopolsky added the comment:
> I think there have been some rumblings about writing our own strftime
Yes, see issue #3173.
Another related issue is #9650 which discusses how to properly document
strftime codes.
--
___
Python trac
Alexander Belopolsky added the comment:
Would issue9527 address your request? Note that datetime.strftime already
supports %z:
>>> from datetime import *
>>> datetime.now(timezone.utc).strftime('%c %z')
'Mon Sep 13 13:43:19 2010 +'
(
Alexander Belopolsky added the comment:
> The full path *could* be easily passed, but I think we should
> address this problem from regrtest.py's side.
I disagree. There may be other scripts that rely on __main__.__file__ being an
absolute path and we cannot require everyone to c
Alexander Belopolsky added the comment:
Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll
check if I can merge in patch 4.
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
Committed with minor changes in r84777.
Eli, please keep lines under 80 characters.
Leaving the issue open pending py3k port.
--
resolution: -> accepted
stage: patch review -> committed/rejected
___
Alexander Belopolsky added the comment:
Thanks, Florent.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9323>
___
___
Python-
Alexander Belopolsky added the comment:
Eli, while porting your tests to py3k, I had to change expected output for list
comprehension testing. This is not really surprising because 3.x
comprehensions differ from 2.x (they don't leak the loop variable anymore).
The difference be
Alexander Belopolsky added the comment:
Committed in:
py3k: r84780
release31-maint: r84783
release27-maint: r84777
Need a separate issue for the problem highlighted in msg116336.
--
status: open -> closed
___
Python tracker
&l
Alexander Belopolsky added the comment:
Since noone have spoken in favor of 2.7 backport, I am closing this issue as
committed to py3k.
--
keywords: -needs review
resolution: -> accepted
stage: patch review -> committed/rejected
status: pending -> closed
versions: -P
Alexander Belopolsky added the comment:
You must be right. I thought I did all the svn adds, but may have missed
something. I'll take care of this tonight, but I am off the grid for the next
3-4 hours.
On Sep 13, 2010, at 3:13 PM, Florent Xicluna wrote:
>
> Florent Xicluna
Alexander Belopolsky added the comment:
> You probably missed Lib/test/tracedmodules/
fixed in r84794.
--
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
On Tue, Sep 14, 2010 at 2:29 AM, Georg Brandl wrote:
..
> Note that if you add new directories under /Lib, you need to make the build
> system aware of them in several
> places (I don't remember all of them right now, one is i
Alexander Belopolsky added the comment:
Updated Makefile in r84803 - r84805.
--
___
Python tracker
<http://bugs.python.org/issue9315>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
> Antoine suggests to relax the test and only check
> if the count is within a range (12, 13).
This feels like implementation driven testing. I would prefer to disable the
offending test pending further investigation into the core cause.
It
Alexander Belopolsky added the comment:
It looks like 3.1 with computed gotos produces the yet another different
tracing of list comprehensions:
2: l = [i for
10: i in
1: range(10)]
--
___
Python tracker
<h
New submission from Alexander Belopolsky :
When testing config options, it is often useful to build python in a directory
different from the root of the source tree. This is supported by autoconf
based builds as follows: you cd to the desired directory run configure with an
explicit path
Alexander Belopolsky added the comment:
I think the problem is with the following explicit rules in Makefile:
Parser/tokenizer_pgen.o:$(srcdir)/Parser/tokenizer.c
Parser/pgenmain.o: $(srcdir)/Include/parsetok.h
It looks like these rules are not VPATH friendly. Per Antoine&#
Alexander Belopolsky added the comment:
It turns out that make only gets confused when target files (Parser/pgenmain.o
etc.) exist in the source directory. Thus an obvious workaround is to build
all versions in alternative directories or delete object files from source tree
before
Alexander Belopolsky added the comment:
> (what is VPATH?)
VPATH is a search path that make uses to find targets and prerequisites.
configure sets it to its own location when invoked from a directory other than
cwd.
--
___
Python tracker
&l
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file1/unnamed
___
Python tracker
<http://bugs.python.org/issue9315>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
> Is it really *interesting* to trace separate parts of list
> comprehensions like this?
It may or may not be useful for tracing code in the wild, but it helps to
isolate the causes of count mismatches.
I am attaching a file, x.py, that shows dif
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file18891/x.py
___
Python tracker
<http://bugs.python.org/issue9315>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
I am attaching another test file, y.py, which shows that the cause of
discrepancy is outside of the trace module. The traced function is the same as
in x.py only with 5 iterations instead of 10 for brevity, but instead of using
trace module, I am
Alexander Belopolsky added the comment:
Raymond asked on IRC why this work is being back-ported. The answer is that it
is being forward-ported rather than back-ported. The trace module had no
unittests in either 2.x or 3.x and was very buggy in 3.x. Presumably, 2.x
version saw more use
New submission from Alexander Belopolsky :
Attached test script, tracetest.py, prints disassembly followed by a trace of
the following function:
1 def f():
2 return [i
3 for i
4 in range(2)]
With default configuration, the output is
2 0
Alexander Belopolsky added the comment:
I wonder if type metaclass can be taught to handle this in general for
subclasses implemented in python.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue9
Alexander Belopolsky added the comment:
> How do you want to "handle this in general"?
Possibly by adding up __sizeof__'s of base and __dict__ in a generated
function? With a special handling of slots ...
May prove to be too complicated to b
Alexander Belopolsky added the comment:
On Wed, Sep 15, 2010 at 5:33 PM, Antoine Pitrou wrote:
..
> As I said in #9315, I think this kind of thing (bytecode traces) is an
> implementation detail; the changes
> in results shouldn't be regarded as breaking compatibility.
In r741
Alexander Belopolsky added the comment:
On Wed, Sep 15, 2010 at 5:45 PM, Roumen Petrov wrote:
..
> Please could you remove object files from source tree then try again.
>
It looks like you missed my penultimate comment.
> This is invalid issue.
At the very least, Building Python [1
Alexander Belopolsky added the comment:
See issue #9866 for follow ups on list comprehensions' tracing.
--
nosy: -Alexander.Belopolsky
status: open -> closed
superseder: -> Inconsistencies in tracing list comprehensions
___
Python tra
Alexander Belopolsky added the comment:
List comprehension test is removed from 3.1 in r84848.
--
___
Python tracker
<http://bugs.python.org/issue9315>
___
___
Alexander Belopolsky added the comment:
> So I'm open to ideas and am willing to submit improved patches for 3.2
I offered some ideas in my last message. In addition, I would like to see
profile and trace documentation to converge to similar structure and use
similar terminol
Changes by Alexander Belopolsky :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9888>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Mon, Sep 20, 2010 at 10:23 AM, Mark Lawrence wrote:
>
> Mark Lawrence added the comment:
>
> Can someone please backport this to 2.7 so we can get this closed, thanks.
>
AFAICT, r73564 preceded 2.7 branch cut, so the fix is
Alexander Belopolsky added the comment:
IIRC, trigonometric functions, such as sin or cos, are not considered
"elementary" in the real domain.
The problem with this proposal is where to stop. Right now the line is drawn
somewhere at __abs__ and __pow__. If you add __sin__ and __
Alexander Belopolsky added the comment:
I've added #9909 as a dependency, but IMO it is less likely to be accepted than
this feature request.
On this issue, I would much rather see email package to start using datetime
objects to represent time rather than named or unnamed t
1 - 100 of 3596 matches
Mail list logo
