Changes by Alexander Belopolsky :
--
keywords: -needs review, patch
nosy: -Alexander.Belopolsky
resolution: -> fixed
stage: commit review -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13825>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
IANA is now distributing Olson's timezone database software which includes an
implementation of strftime():
http://www.iana.org/time-zones/repository/releases/tzcode2012b.tar.gz
The code was designated as public domain by Arthur David Olson, b
Alexander Belopolsky added the comment:
I have reviewed RFC 3339 and it looks like the following produces a fully
compliant timestamp:
>>> print(datetime(2000,1,1, tzinfo=timezone.utc).isoformat('T'))
2000-01-01T00:00:00+00:00
I see the following remaining issues:
1. It
Alexander Belopolsky added the comment:
On Mon, Jun 11, 2012 at 11:18 PM, James Henstridge
wrote:
> One problem I can see with using a fixed offset
> tzinfo for localtime is that it might confuse people
> when doing date arithmetic.
Yes, this is the issue that I discussed in my fir
Alexander Belopolsky added the comment:
> ... is a well-defined problem which does not have an adequate solution.
I meant to say "does not have an adequate solution *in the current datetime
module*". I think the enhanced datetime.astimezone() method will solve
Alexander Belopolsky added the comment:
> That said, this might be a worthwhile as a bug fix.
I think this is a reasonable bug fix. Note that apart from OS-dependent date
range, some mktime implementations reportedly don't support tm_isdst values
other than -1.
--
Alexander Belopolsky added the comment:
Attached patch implements astimezone() default in both Python and C.
--
stage: -> patch review
Added file: http://bugs.python.org/file26062/issue9527.diff
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue7584>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue9527>
___
___
Python-bugs-list mai
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
Fixed in changeset a7237f157625.
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
Since no one is able to reproduce this crash, I am going to close this issue.
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue10941>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Working on this. It turns out tm_gmtoff uses the opposite sign to
that of timezone in time.h. For more confusion, consider this:
$ TZ=EST+5 date +%z
-0500
I am rechecking all UTC offset signs.
On Fri, Jun 22, 2012 at 3:36 PM, Jesús Cea Avión wrote
Alexander Belopolsky added the comment:
Most of the localtime() logic is now implemented (correctly) in
datetime.astimezone(). Attached patch fixes email.utils.localtime()
implementation.
--
status: closed -> open
Added file: http://bugs.python.org/file26094/issue665194.d
Alexander Belopolsky added the comment:
I updated the fix to take advantage of resolved issue 9527. I also noticed and
fixed another bug: Internaldate2tuple was using locale-dependent %b directive
for strftime.
--
Added file: http://bugs.python.org/file26100/issue10941.diff
Alexander Belopolsky added the comment:
The latest patch belongs to issue 11024.
--
___
Python tracker
<http://bugs.python.org/issue10941>
___
___
Python-bug
Alexander Belopolsky added the comment:
David,
issue665194.diff patch is a bug fix for localtime(). If you decide to keep
localtime(), there is not much of a rush because bug fixes can go in after beta.
--
___
Python tracker
<h
Alexander Belopolsky added the comment:
*file* is correct because shutil.which() is more general than shell which
command. (It can be used to find source files on PYTHONPATH, for example.)
I think the confusing part is "return the path ... on the path." This can be
fixed in reST
Alexander Belopolsky added the comment:
> Alexander, can you explain the part about finding a file on PYTHONPATH?
I thought about something like this:
>>> shutil.which('shutil.py', os.F_OK, ':'.join(sys.path))
'/Users/sasha/Work/python-hg/py3k/Lib/shutil.
Alexander Belopolsky added the comment:
Brian,
Did you intend to commit Tools/msi/msi.py in changeset 973b4806f760?
--
___
Python tracker
<http://bugs.python.org/issue15
Alexander Belopolsky added the comment:
I don't think the Windows example in the reST documentation is correct:
>>> print(shutil.which("python"))
'c:\\python33\\python.exe'
It should be either
>>> shutil.which("python")
Alexander Belopolsky added the comment:
I don't have a Win 64 setup, but I think replacing 1970 with say 1990 in the
tests should fix the problem.
--
nosy: +Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
I am surprised that we don't see the same failure on 32-bit windows buildbot.
Windows mktime does not support negative time_t in either 32 or 64 bit version:
http://msdn.microsoft.com/en-us/library/d1y53h2a(v=vs.110).aspx
We are probably just
Alexander Belopolsky added the comment:
Is this something that has to be fixed during the freeze? The fix is trivial:
s/1970/1990/g, but I planned to revisit TZ-dependent tests during the beta
period. I think we don't use run_with_tz() enough. It would also be great to
make it wo
Alexander Belopolsky added the comment:
On Wed, Jul 25, 2012 at 4:17 AM, Marc-Andre Lemburg
wrote:
> ... full C double precision for the time part of a timestamp,
> which covers nanoseconds just fine.
No, it does not:
>>> import time
>>> t = time.time()
>>&g
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue15577>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue12834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue14130>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
I'll take a look tomorrow morning. (EDT:-)
--
___
Python tracker
<http://bugs.python.org/issue665194>
___
___
Pytho
Alexander Belopolsky added the comment:
I noticed this part:
+# We have an aware datetime. Use aware datetime arithmetic to find the
+# seconds since the epoch.
+delta = dt - datetime.datetime(*time.gmtime(0)[:6],
+ tzinfo
Alexander Belopolsky added the comment:
> So you are saying that if the current timezone is UTC, FreeBSD's mktime
> just arbitrarily returns -1 for any time passed to it with the 'guess
> the DST flag' value set for is_dst?
I don't know about FreeBSD, but I re
Alexander Belopolsky added the comment:
> So since the other tests were passing before, presumably there
> is some test that could be added to exercise the bug you were
> fixing. Do you remember what that was?
Yes, the issue was the one that was mentioned in an XXX comment: in many pl
Alexander Belopolsky added the comment:
Please commit. I'll add the test.
On Wed, Aug 22, 2012 at 9:11 PM, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> I think restricting the test is fine. If we find a platform-specific bug on
> another platfo
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue665194>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue665194>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1578643>
___
___
Pyth
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue3760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue15390>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue15711>
___
___
Python-bugs-lis
New submission from Alexander Belopolsky:
This is a meta-issue to keep track of a global PEP 3121 refactoring effort.
Per-module issues will be added as dependencies. Let's move the discussion that
is not specific to any particular module here.
--
components: Extension Mo
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 refactoring applied to curses module, PEP 3121,
384 refactoring applied to datetime module, PEP 3121, 384 refactoring applied
to dbm module
___
Python tracker
<h
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 refactoring applied to elementtree module, PEP
3121, 384 refactoring applied to gdbm module, PEP 3121, 384 refactoring applied
to hashopenssl module, PEP 3121, 384 refactoring applied to lzma module
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121 refactoring applied to audioop module, PEP 3121
refactoring applied to binascii module, PEP 3121 refactoring applied to fpectl
module, PEP 3121, 384 Refactoring applied to array module, PEP 3121, 384
Refactoring applied to
Changes by Alexander Belopolsky :
--
dependencies: +Add VS CRT redist to the MSI installer, PEP 3121 Refactoring
applied to nis module, PEP 3121 refactoring applied to fpetest module, PEP 3121
refactoring applied to pwd module, PEP 3121, 384 Refactoring applied to
itertools module
Changes by Alexander Belopolsky :
--
dependencies: -Add VS CRT redist to the MSI installer
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Pytho
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 Refactoring applied to decimal module, PEP 3121,
384 Refactoring applied to grp module, PEP 3121, 384 Refactoring applied to
ossaudio module, PEP 3121, 384 Refactoring applied to resource module, PEP
3121, 384
Alexander Belopolsky added the comment:
Robin,
Perhaps we should start with the "xx" modules: Modules/xxmodule.c and
Modules/xxsubtype.c. These modules server as a demonstration of best practices
and it is natural to use them to iron out any refactoring issues without any
risk t
Changes by Alexander Belopolsky :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I would like to add my +1 to this issue. I suggest adding something like this:
"""
Commonly used format codes:
%Y Year with century as a decimal number.
%m Month as a decimal number [01,12].
%d Day of the month as a decima
New submission from Alexander Belopolsky:
Currently "help user-defined" lists commands defined in Misc/gdbinit without
explanations
(gdb) help user-defined
User-defined commands.
The commands in this class are those defined by the user.
Use the "define" command to define
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue15814>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue15805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Having been bitten by an indirect buffer bug in 2.7, I decided to write some
tests for 3.3. I added an objview() function to _testbuffer module that
creates an indirect view for nested tuples. I have not written unit tests yet,
so I'll attach a
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file27060/test_indirect.py
___
Python tracker
<http://bugs.python.org/issue15821>
___
___
Python-bug
Alexander Belopolsky added the comment:
> Your test case seems to pass here. :) Was it supposed to crash?
No, I worked real hard to make it pass. :-) I think it would crash 2.7 and
3.2, but I have not tried. I also suspect it leaks memory.
Do you think this is something that we sho
Alexander Belopolsky added the comment:
> PyMemoryViewObject already is a PyVarObject with its own shape,
> strides and suboffsets.
You are right. I was mistakenly looking at 3.2.3 sources. It looks like there
are a lot of undocumented change
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file27061/_testbuffer.diff
___
Python tracker
<http://bugs.python.org/issue15821>
___
___
Python-bug
Alexander Belopolsky added the comment:
I've updated test_indirect.py to print all memoryview fields and cleaned up the
_testbuffer patch a little. Note this code that is needed to prevent a memory
leak:
+/* PyMemoryView_FromBuffer ignores info.obj. Add it explicitely. */
+if
Alexander Belopolsky added the comment:
On Thu, Aug 30, 2012 at 1:22 PM, Stefan Krah wrote:
> So the topic is reduced to:
>
> 1) Previous: If non-NULL, steal the view.obj reference with automatic
>decrement in PyBuffer_Release().
> New: If non-NULL, tr
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file27059/_testbuffer.diff
___
Python tracker
<http://bugs.python.org/issue15821>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file27060/test_indirect.py
___
Python tracker
<http://bugs.python.org/issue15821>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Fri, Aug 31, 2012 at 2:34 PM, Stefan Krah wrote:
> With the ManagedBuffer, we could now write a new function that returns
> a memoryview with much nicer cleanup facilities. But that doesn't help
> here since we're stuck with this
Alexander Belopolsky added the comment:
On Fri, Aug 31, 2012 at 3:12 PM, Stefan Krah wrote:
> Now I'm puzzled: I thought your goal was to preserve the implicit cleanup
> from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is
> deallocated.
>
The issue that I ra
Alexander Belopolsky added the comment:
Here is what I think the test case should look like (untested):
static PyObject *
memoryview_from_buffer_cleanup(PyObject *self, PyObject *noargs)
{
PyObject *b, *view = NULL;
Py_buffer info;
Py_ssize_t shape[3] = {2, 2, 3};
Py_ssize_t
Alexander Belopolsky added the comment:
On Sep 1, 2012, at 10:24 AM, Stefan Krah wrote:
>
> The definition hash(m) == hash(m.tobytes()) is pretty straightforward.
I probably missed something from the early discussion, but doesn't this
definition only work for 1d (or 0d) views
Alexander Belopolsky added the comment:
On Sep 1, 2012, at 11:06 AM, Stefan Krah wrote:
> tobytes() is the same as the flattened multi-dimensional list representation
> with all elements converted to bytes.
This is correct, but why is it desirable to have deliberate hash collisions
b
Alexander Belopolsky added the comment:
On Sep 2, 2012, at 8:44 AM, Stefan Krah wrote:
> The totals are +11.5 :) for hashing, +1 for allowing non-contiguous and
> -2 for multi-dimensional
I have refrained from voting because in my line of work buffers or memoryviews
deal with large o
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 Refactoring applied to xx module, PEP 3121, 384
Refactoring applied to xxsubtype module
___
Python tracker
<http://bugs.python.org/issue15
Alexander Belopolsky added the comment:
xxmodule.c is used as an example in PEP 3121 itself. To the extent the recipe
in the PEP is complete, the changes to actual xxmodule.c should follow the
text. For example, the text in PEP recommends to leave m_free member of
PyModuleDef 0:
static
Alexander Belopolsky added the comment:
+#define xx_state_global
+ ((xxstate *)PyModule_GetState(PyState_FindModule(&xxmodule)))
This is unsafe: PyState_FindModule(&xxmodule) can return NULL. I think code
should account for this possibility and not use this macro. For
Alexander Belopolsky added the comment:
On Mon, Sep 3, 2012 at 8:38 AM, Stefan Krah wrote:
> I don't see what could possibly be ill-defined about using the
> tobytes() definition for ND-arrays. In all places memoryview now
> uses the logical array, which is displayed by tolist().
New submission from Alexander Belopolsky:
With attached patch python -mpydoc memoryview display looks as follows:
...
| cast(...)
| M.cast(format[, shape]) -> memoryview
|
| Cast a memoryview to a new format or shape.
|
| release(...)
| M.release() ->
Alexander Belopolsky added the comment:
In the new patch, I added docstrings for the data members and now the list of
memoryview data descriptors looks as follows in pydoc:
| --
| Data descriptors defined here
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file27109/memoryobject-docstrings.diff
___
Python tracker
<http://bugs.python.org/issue15
New submission from Alexander Belopolsky:
Starting with the example in memoryview documentation:
>>> from ctypes import BigEndianStructure, c_long
>>> class BEPoint(BigEndianStructure):
... _fields_ = [("x", c_long), ("y", c_long)]
...
>>> poi
Alexander Belopolsky added the comment:
I am going to commit this tonight. Stefan, please let me know if you have any
comments. I copied most of the descriptions from ReST manual with a few minor
changes. See shape/strides/suboffsets.
--
stage: -> commit rev
Alexander Belopolsky added the comment:
What about
>>> struct.unpack_from('>ll',a)
(0, 100)
shouldn't that return (100, 200)?
--
___
Python tracker
<htt
Alexander Belopolsky added the comment:
On Sep 3, 2012, at 1:22 PM, Stefan Krah wrote:
> Personally I'd also prefer if all
> docstrings go into a separate section. I always perceive docstrings
> as noise that takes up precious vertical space, so for _decimal I even
>
Alexander Belopolsky added the comment:
On Mon, Sep 3, 2012 at 3:59 PM, Martin v. Löwis wrote:
> if hashing was restricted
> to contiguous bytes, then the implementation would certainly be
> simplified quite a bit: currently, if it's not contiguous, it needs
> to make a separ
Alexander Belopolsky added the comment:
A few remaining comments:
1) shape being None for 0-d views in 3.2 is probably a bug. I did not mention
that behavior in docstring.
2) "a N-dimensional array" typo was copied from ReST. Fixing it does not
deserve a separate tracker entry, b
New submission from Alexander Belopolsky:
PyType_FromSpec() is a convenient function to create types dynamically in C
extension modules, but its usefulness is limited by the fact that it creates
new types using the default metaclass.
I suggest adding a new C API function
PyObject
Alexander Belopolsky added the comment:
On Thu, Sep 6, 2012 at 12:44 PM, Amaury Forgeot d'Arc
wrote:
> The patch is a bit light: see how type_new also computes the metaclass from
> the base classes.
This was intentional. I was looking for a lightweight facility to
create heap typ
Changes by Alexander Belopolsky :
--
nosy: +Robin.Schreiber
___
Python tracker
<http://bugs.python.org/issue15870>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
> see how type_new also computes the metaclass from the base classes.
As you can see from my first message, I originally considered
PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec) without bases. (In fact I
was unaware of the recent addition
Alexander Belopolsky added the comment:
On Sep 6, 2012, at 5:10 PM, Martin v. Löwis wrote:
>
> What is your use case for this API?
>
I can describe my use case, but it is somewhat similar to ctypes. I searched
the tracker for a PEP 3121 refactoring applied to ctypes and could
Alexander Belopolsky added the comment:
On Sep 6, 2012, at 6:25 PM, Martin v. Löwis wrote:
> I'm -1 on calling it PyType_FromSpecEx.
I find it encouraging that you commented on the choice of name. :-) I can live
with PyType_FromMetatypeAndSpec and leave out bases. PyType_FromTypeAn
Alexander Belopolsky added the comment:
%z format is supported, but it cannot accept colon in TZ offset. It can parse
offsets like -0600 just fine. What OP is looking for is the GNU date %:z
format which datetime does not support.
For ISO 8601 compliance, however I think we need a way to
Alexander Belopolsky added the comment:
On Thu, Sep 6, 2012 at 9:51 PM, John Nagle wrote:
> It's not in Python 2.7 / Win32.
Python 2.x series is closed and cannot accept new features. Both %z
and fixed offset tzinfo subclass are implemente
Alexander Belopolsky added the comment:
I am attaching a quick python only prototype for the proposed feature. My goal
is to make date/time objects behave like numeric types for which constructors
accept strings produced by str(). Since str() format is ISO 8601, it is
natural to accept ISO
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Added in 7ca6b3a16e15
--
nosy: +belopolsky
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue5023>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
The patch makes sense. I'll take another look over the weekend, but it seems
to be ready to be applied.
--
assignee: -> belopolsky
nosy: +belopolsky
stage: patch review -> commit review
___
Pyt
Changes by Alexander Belopolsky :
--
assignee: belopolsky
nosy: belopolsky
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to ctypes module
type: resource usage
versions: Python 3.4
___
Python tracker
<h
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 Refactoring applied to ctypes module
___
Python tracker
<http://bugs.python.org/issue15
1901 - 2000 of 3596 matches
Mail list logo
