Alexander Belopolsky added the comment:
UCD provides more than just a list of aliases: formal name aliases have type
- control, abbreviation, etc. See
http://www.unicode.org/Public/UNIDATA/NameAliases.txt.
--
___
Python tracker rep
Alexander Belopolsky added the comment:
MvL Are you sure that the permission to use KHMER VOWEL INHERENT AQ
MvL in an identifier is worth mentioning?
No, but it is worth mentioning that there are no more substantial changes. I
don't think the change from 6.1.0 to 6.2.0 has any effect
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
Added file: http://bugs.python.org/file30608/bd092995907c.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18176
Alexander Belopolsky added the comment:
Here is what grep revealed:
$ find Doc -name \*.rst | xargs grep -n '6\.2\.0'
Doc/library/stdtypes.rst:357: See
http://www.unicode.org/Public/6.2.0/ucd/extracted/DerivedNumericType.txt
Doc/library/unicodedata.rst:18:this database is compiled from
New submission from Alexander Belopolsky:
At the minimum, we should refer to unicode.org:
http://www.unicode.org/versions/Unicode6.1.0/#Database_Changes (for Python 3.3),
http://www.unicode.org/versions/Unicode6.2.0/#Database_Changes (for Python 3.4).
We may also want to highlight changes
Alexander Belopolsky added the comment:
Here is another change that I think deserves an explicit mention in What's
New:
Python 3.3.2
exec('a\u17B4 = 5')
eval('a\u17B4')
5
Python 3.2.5
exec('a\u17B4 = 5')
Traceback (most recent call last):
File stdin, line 1, in module
File string, line
Alexander Belopolsky added the comment:
I have found another place where explicit UCD version is used in the docs:
Doc/reference/lexical_analysis.rst:729:.. [#]
http://www.unicode.org/Public/6.1.0/ucd/NameAliases.txt
I am not sure how this case should be handled. The language reference
New submission from Alexander Belopolsky:
Python is aware of unicode codepoint aliases, but unicodedata does not provide
a way to find aliases of a given codepoint:
ucd.lookup('ESCAPE') == '\N{ESCAPE}'
True
ucd.lookup('RS') == '\N{RS}'
True
but
ucd.name('\N{ESCAPE}')
Traceback (most
Alexander Belopolsky added the comment:
I took another look at the library reference and it looks like when it comes to
non-ascii digits support, the reference contradicts itself. On one hand,
int(x, base=10)
If x is not a number or if base is given, then x must be a string, bytes
Alexander Belopolsky added the comment:
i opened issue18236 to address the issue of surrounding whitespace.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
Alexander Belopolsky added the comment:
I have started a rough prototype for what I plan to eventually reimplement in C
and propose as a patch here.
https://bitbucket.org/alexander_belopolsky/misc/src/c175171cc76e/utoi.py?at=master
Comments welcome
Alexander Belopolsky added the comment:
PEP 393 implementation has already added the fast path to decimal encoding:
http://hg.python.org/cpython/diff/8beaa9a37387/Objects/unicodeobject.c#l1.3735
What we can do, however, is improve performance of converting non-ascii
numerals by looking up
Alexander Belopolsky added the comment:
This is essentially a duplicate of #10581, so I am closing this and will
summarize the situation there.
--
resolution: - duplicate
status: open - closed
superseder: - Review and document string format accepted in numeric data type
constructors
Alexander Belopolsky added the comment:
It looks like we a approaching consensus on some points:
1. Mixed script numerals should be disallowed.
2. '\N{MINUS SIGN}' should be accepted as an alternative to '\N{HYPHEN-MINUS}'
Open question: should we accept fullwidth + and -, sub/superscript
Alexander Belopolsky added the comment:
I don't have a system affected by the change, but the explanation and the patch
look right to me.
FWIW, the patch applies cleanly to 3.4 head and passes 'make test'.
--
stage: - commit review
versions: +Python 3.3, Python 3.4
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
hgrepos: +197
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18176
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file30531/686836ad3042.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18176
Alexander Belopolsky added the comment:
This is a trivial change, but I would like someone to review this in case there
is a better solution to keep this in sync with unicodedata.unidata_version.
--
assignee: - docs@python
keywords: +needs review
nosy: +docs@python
stage: - commit
Alexander Belopolsky added the comment:
The latest patch at #2382 is simpler than mine, so I am closing this as
duplicate.
--
resolution: - duplicate
status: open - closed
superseder: - [Py3k] SyntaxError cursor shifted if multibyte character is in
line
Alexander Belopolsky added the comment:
haypo The purpose of this issue is to handle CJK characters taking 2 haypo
columns instead of 1 in a terminal, or did I misunderstand it?
That's the other half of the problem, but the more common issue is misplaced
caret when non-ascii characters
Alexander Belopolsky added the comment:
Serhiy's patch is lacking tests, but it passes the test I proposed at #10382 at
attaching here.
--
Added file: http://bugs.python.org/file30534/test.py
___
Python tracker rep...@bugs.python.org
http
Alexander Belopolsky added the comment:
I am changing the title slightly to include '\N{MINUS SIGN}' in the scope of
this issues. See [1]:
Unless anyone can point me to a case where \N{MINUS SIGN} should not be
treated as a (duh) minus sign, we should go and try to make life easier for our
New submission from Alexander Belopolsky:
Reference to
http://www.unicode.org/Public/6.0.0/ucd/extracted/DerivedNumericType.txt in
http://docs.python.org/3.4/library/stdtypes.html#numeric-types-int-float-complex
should be changed to
http://www.unicode.org/Public/6.1.0/ucd/extracted
Alexander Belopolsky added the comment:
As a design principle, accept what's unambiguous in any locale is reasonable,
but it is hard to apply consistently. I would agree that the status quo is
hard to defend. After a long discussion, it has been accepted that fullwidth
digits should
Alexander Belopolsky added the comment:
Python 2.x is in maintenance mode and will not receive new features. In 3.x
this is already implemented:
Python 3.3.2 (default, May 24 2013, 22:46:58)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type help, copyright, credits
Alexander Belopolsky added the comment:
This is not a bug in datetime.timezone. The value returned by
timezone.tzname() is documented and the code works correctly. %Z should not be
used to produce machine-readable timestamps and for a human reader
'UTC+03:00+0300' should not be confusing
Alexander Belopolsky added the comment:
I left a few minor comments on rietveld for the last patch. I did not see code
for time.now() and I don't think adding now() should be combined with time +/-
timedelta patch. Let's do one thing at a time.
I think time + timedelta addition is fairly
Alexander Belopolsky added the comment:
This was proposed before and rejected in issue1118748, but I think current
proposal addresses the ambiguity that was sited as a reason for rejection.
--
nosy: +skip.montanaro
___
Python tracker rep
Alexander Belopolsky added the comment:
See also issue 3250. If we add mod 24h arithmetics, I would like to see
something like time.add_with_carry(timedelta) - (int, time) method. With it,
users who need a specific overflow behavior will be able to implement it easily:
def check_add(t, td
Alexander Belopolsky added the comment:
I am changing the title to focus this issue on arithmetics. Lack of time.now()
is adressed in #8902.
--
title: datetime.time support for '+' and 'now' - datetime.time support for '+'
and '-'
___
Python
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: wont fix -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8902
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8902
Alexander Belopolsky added the comment:
+1
I had tsort in my own utilities library for so long that I thought it was in
stdlib already. I found this issue after unsuccessfully searching
docs.python.org. :-)
I think functools will be a fine place for it. It is somewhat related to total
Alexander Belopolsky added the comment:
I am in AP's camp on the tab issue, but I think we can preserve tab inserts
tab behavior at the continuation prompt. I don't like indent at beginning of
line. I have rlcompleter enabled in Python 2.6 and i get the following when I
press tab:
Python
Alexander Belopolsky added the comment:
Shouldn't we link to IANA for timezones information?
http://www.iana.org/time-zones/repository/tz-link.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17571
Alexander Belopolsky added the comment:
Éric do you think there is a need to check python-ideas or python-dev before
working on this?
Yes, I think this is python-ideas material. IMHO, what should be added to
datetime module in 3.4 is ability to construct date/time objects from their
str
Alexander Belopolsky added the comment:
Benjamin,
I am assigning this to you because 2.7.4 release is probably the last chance to
do something about this behavior in 2.7 series.
I am tentatively resolving this as won't fix. In 3.x, we decided that well
defined behavior is more important
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2267
Alexander Belopolsky added the comment:
ctypes/tests is within my area of interests and may prove to be one of the
harder pieces. I'll try to move it and report the results. I have not worked
with the rest, so unless it is truly trivial this will have to wait for another
volunteer
Alexander Belopolsky added the comment:
Attached patch fixes the issue and passes regression tests, so most likely the
ability to instantiate Number is not an intentional feature.
pass should probably be replaced with a meaningful docstring, but I would
like to hear from others on whether
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16818
New submission from Alexander Belopolsky:
According to the reference manual, None of the types defined in [numbers]
module can be instantiated. However,
from numbers import *
Number()
numbers.Number object at 0x1005e5080
This can probably be fixed by making Number.__hash__ an abstract
Alexander Belopolsky added the comment:
I recall a discussion in which it was argued that look before you leap-style
argument checking that we implemented in py3k was a feature and backporting it
to 2.x could potentially break code running on platforms with promiscuous (and
possibly buggy
Alexander Belopolsky added the comment:
issue6478_v2.patch looks good to me. There is a long line in _strptime.py
which I will fix before committing.
--
stage: test needed - commit review
versions: -Python 3.2
___
Python tracker rep
Alexander Belopolsky added the comment:
I don't think a comment explaining that default encoding is utf-8 in python 3.x
will improve readability of this code.
if (encoding == NULL)
return PyUnicode_DecodeUTF8(s, size, errors);
seems quite self-explanatory
Alexander Belopolsky added the comment:
Is it practical to implement GPS time as datetime given that we don't have
support for leap seconds?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
Alexander Belopolsky added the comment:
Juarez,
Are you planning to implement format validation as you described in msg165882?
Without that, date.strptime() is not very useful because it is almost
equivalent to datetime.strptime().date
Alexander Belopolsky added the comment:
The patch looks good, but I have a few comments on the test:
1. Does it work on Windows? It seems to rely on Olson's TZ names.
2. Please use @run_with_tz decorator.
--
___
Python tracker rep
New submission from Alexander Belopolsky:
In Python 3.3.0 and 3.2.3:
from inspect import *
def f(a,b):pass
...
formatargspec(getargspec(f))
Traceback (most recent call last):
File stdin, line 1, in module
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py
Alexander Belopolsky added the comment:
My bad, but I think documentation can be improved by adding an example.
--
assignee: - docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
type: behavior - enhancement
versions: -Python 3.2, Python 3.3
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Alexander Belopolsky added the comment:
Christian's or rather Skip's idea is covered by Issue 3173. This was discussed
several times on python-dev.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9650
Alexander Belopolsky added the comment:
Alexander, did you send a contributor agreement?
At least twice. :-)
--
keywords: +patch
priority: normal - high
stage: needs patch - commit review
Added file: http://bugs.python.org/file27234/issue15973.diff
Alexander Belopolsky added the comment:
Leeaving the issue open in case it will go to 3.3.0. Reassigning to the RM.
--
assignee: belopolsky - georg.brandl
resolution: - fixed
stage: commit review - committed/rejected
___
Python tracker rep
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
assignee: ronaldoussoren - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15973
Alexander Belopolsky added the comment:
I cannot reproduce on a Mac with py3k tip.
Python 3.3.0rc2+ (default:19c74cadea95, Sep 19 2012, 14:39:07)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin
Type help, copyright, credits or license for more information.
import
Alexander Belopolsky added the comment:
This is similar to issue 14262. If we decide that timedelta should play nice
with Decimal, I would like to consider all related features.
--
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky added the comment:
In fact, this is a near-duplicate of #14262 becaus instead of
decimal.Decimal('0.1')*datetime.timedelta(seconds=3)
one can always write
datetime.timedelta(seconds=decimal.Decimal('0.1')*3)
--
___
Python
Alexander Belopolsky added the comment:
Mark wrote in his comment on issue 15975:
we're looking at significant extra code to implement
Decimal * timedelta
Not necessarily. I will only support adding this feature if it can be done
without making datetime know about Decimal. If we can agree
Alexander Belopolsky added the comment:
On Wed, Sep 19, 2012 at 3:09 PM, Ram Rachum rep...@bugs.python.org wrote:
One example is decimal fields on Django, used for dollar amounts.
.. and since time is money and money is time we should support easy
conversion between the two
Alexander Belopolsky added the comment:
On Wed, Sep 19, 2012 at 3:24 PM, Ram Rachum rep...@bugs.python.org wrote:
I hope this was intended as a joke. If this was an actual criticism, let me
know so
I could explain why it makes sense.
It was both. Yes, any use cases will be helpful
Alexander Belopolsky added the comment:
On Wed, Sep 19, 2012 at 4:32 PM, Ram Rachum rep...@bugs.python.org wrote:
But that number, 1.15, is stored in a Django decimal field.
My criticism was towards the idea that one may need to multiply
timedelta by a dollar amount or convert a dollar amount
Alexander Belopolsky added the comment:
On Sep 19, 2012, at 5:36 PM, Ram Rachum rep...@bugs.python.org wrote:
Why would we use float to represent the ratio of the bonus to the client?
Because float is the builtin type that Python provides to represent such
quantities.
Why would we risk
Alexander Belopolsky added the comment:
I think the following simple patch should do the trick. I'll add some tests
and commit. Should this get in 3.3.0?
diff -r 19c74cadea95 Modules/_datetimemodule.c
--- a/Modules/_datetimemodule.c Wed Sep 19 08:25:01 2012 +0300
+++ b/Modules
Alexander Belopolsky added the comment:
What about datetime subclasses?
Do you mean timezone subclasses? Timezone type is not subclassable, but we
should probably support comparison with any tzinfo subclass. I'll add this
logic, but arguably that would be a new feature
Alexander Belopolsky added the comment:
Isn't this a duplicate of issue 8810?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15941
Alexander Belopolsky added the comment:
I've read this more carefully and I now understand the issue. Indeed, setting
time.timezone or time.altzone has no effect on say time.strftime('%z'). I
think this should be documented and the doc should refer to time.tzset() for a
proper way to change
Alexander Belopolsky added the comment:
Setting this attribute has no effect.
Strictly speaking, setting this attribute has the effect of changing the value
of this attribute. I cannot come up with a better wording at this hour, but I
would say something about it being informational only
Alexander Belopolsky added the comment:
I would like to split this issue to separate PEP 3121 changes from PEP 384.
PEP 3121 state cleanup implementation is clearly an improvement from a
resource management point of view. On the other hand, I don't see much
benefit for the datetime module
Alexander Belopolsky added the comment:
On Sep 9, 2012, at 8:15 AM, Roy Smith rep...@bugs.python.org wrote:
We need to define the scope of what input strings will be accepted.
Since it is easier to widen the domain of acceptable arguments than to narrow
it in the future, I would say let's
Alexander Belopolsky added the comment:
I realize that while that is certainly an absolute lower bound,
it's almost certainly not sufficient. The most common use case
I see on a daily basis is parsing strings that look like
2012-09-07T23:59:59+00:00.
This is exactly what isoformat
Alexander Belopolsky added the comment:
For what parts of ISO 8601 to accept, there's a standard: RFC3339
This is almost indistinguishable from the idea of accepting .isoformat() and
str() results. From what I see the only difference is that 't' is accepted for
date/time separator and 'z
Alexander Belopolsky added the comment:
Applied to 3.2 and 3.3. Thanks for the patch!
Leaving it open pending 2.7 commit.
--
resolution: - fixed
stage: commit review - committed/rejected
___
Python tracker rep...@bugs.python.org
http
Alexander Belopolsky added the comment:
For some reason there are no review links, so I'll review in this message.
Include/datetime.h
+typedef struct {
..
+} _datetimemodulestate;
Names exposed in public headers (datetime.h is a public header) should start
with Py or _Py. Other offenders
Alexander Belopolsky added the comment:
What is the point of providing a __sizeof__ method to a purely internal type?
I don't think it is possible to expose StgDict at the python level. It is
always hidden behind a mapping proxy. Furthemore, StgDict is only used inside
type objects
Alexander Belopolsky added the comment:
Why is this a problem? ISTM all that is happening is that null tp_base is set
to null if Py_tp_base slot is specified as null. If this is somehow a problem
- the user should not specify Py_tp_base slot.
--
nosy: +belopolsky
Alexander Belopolsky added the comment:
Can you give an example of the situation that you described? Perhaps you
encountered it while refactoring some particular extension module. Which?
In your patch new code is commented out.
PySpec_New() is not a good name. It should be something like
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
assignee: - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15873
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
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
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
dependencies: +PEP 3121, 384 Refactoring applied to ctypes module
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15787
Alexander Belopolsky added the comment:
It looks like your patch will result in reference leaks if type creation fails.
I think you should add Py_DECREF(m) before error returns.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
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
___
Python tracker rep
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
rep...@bugs.python.org 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
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +Robin.Schreiber
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15870
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 rep...@bugs.python.org 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
Alexander Belopolsky added the comment:
On Sep 6, 2012, at 6:25 PM, Martin v. Löwis rep...@bugs.python.org 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
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
Alexander Belopolsky added the comment:
On Thu, Sep 6, 2012 at 9:51 PM, John Nagle rep...@bugs.python.org 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 implemented in 3.2
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 alexander.belopol...@gmail.com:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Alexander Belopolsky added the comment:
Added in 7ca6b3a16e15
--
nosy: +belopolsky
resolution: - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15520
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5023
Alexander Belopolsky added the comment:
On Mon, Sep 3, 2012 at 8:38 AM, Stefan Krah rep...@bugs.python.org 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
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() - None
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 alexander.belopol...@gmail.com:
Removed file: http://bugs.python.org/file27109/memoryobject-docstrings.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15855
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)]
...
point = BEPoint(100, 200)
a = memoryview(point)
I am trying
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 review
901 - 1000 of 3523 matches
Mail list logo
