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
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 st
New submission from Alexander Belopolsky:
ASCII information separators, hex codes 1C through 1F are classified as space:
>>> all(c.isspace() for c in '\N{FS}\N{GS}\N{RS}\N{US}')
True
but int()/float() do not accept strings with leading or trailing separators:
>>>
Alexander Belopolsky added the comment:
i opened issue18236 to address the issue of surrounding whitespace.
--
___
Python tracker
<http://bugs.python.org/issue10
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:
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.
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>.
--
___
Pytho
Alexander Belopolsky added the comment:
> You stated facts: what is your proposal?
There is a bug somewhere. We cannot simultaneously have
>>> '\N{RS}'.isspace()
True
and not accept '\N{RS}' as whitespace when parsing numbers.
I believe int(x) should be equ
Alexander Belopolsky added the comment:
It looks like str.isspace() is incorrect. The proper definition of unicode
whitespace seems to include 26 characters:
#
0009..000D; White_Space # Cc [5] ..
0020 ; White_Space # Zs
Alexander Belopolsky added the comment:
I did a little more investigation and it looks like information separators have
been included in whitespace since unicode type was first implemented in Python:
guido 11967 Fri Mar 10 22:52:46 2000 +: /* Returns 1 for Unicode characters
having the
Alexander Belopolsky added the comment:
Martin v. Löwis wrote at #13391 (msg147634):
> I do think that _PyUnicode_IsWhitespace should use the White_Space
> property (from PropList.txt). I'm not quite sure how they computed
> that property (or whether it's manually curat
Changes by Alexander Belopolsky :
--
hgrepos: +201
___
Python tracker
<http://bugs.python.org/issue18236>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
keywords: +patch
Added file: http://bugs.python.org/file30677/5c934626d44d.diff
___
Python tracker
<http://bugs.python.org/issue18
Alexander Belopolsky added the comment:
I have updated the title to focus this issue on the behavior of str.isspace().
I'll pick up remaining int/float issues in #10581.
--
assignee: -> belopolsky
title: int() and float() do not accept strings with trailing separators ->
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file30679/3ed5bb7fcee9.diff
___
Python tracker
<http://bugs.python.org/issue18236>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file30677/5c934626d44d.diff
___
Python tracker
<http://bugs.python.org/issue18236>
___
___
Pytho
Alexander Belopolsky added the comment:
Martin v. Löwis wrote at #18236 (msg191687):
> int conversion ultimately uses Py_ISSPACE, which conceptually could
> deviate from the Unicode properties (as it is byte-based). This is not
> really an issue, since they indeed match.
Py_ISSPAC
Changes by Alexander Belopolsky :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10581>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Rather than adding a new method to unicodedata, what do you think about adding
a type keyword argument to unicodedata.name()? It can default to "canonical"
and have possible values "control", "abbreviatio
Alexander Belopolsky added the comment:
> Can a character or sequence have multiple aliases?
Yes, for example, most control characters have two aliases (and no name).
;NULL;control
;NUL;abbreviation
0001;START OF HEADING;control
0001;SOH;abbreviation
0002;START OF TEXT;control
0002;
Alexander Belopolsky added the comment:
unicodedata.name() was discussed in #12353 (msg144739) where MvL argued that
misspelled names are better than corrected because they are more likely to
appear misspelled in other sources. I am not sure I buy this argument.
Someone googling for
Alexander Belopolsky added the comment:
I mistyped issue reference above it should be #12753, not 12353.
--
___
Python tracker
<http://bugs.python.org/issue18
Alexander Belopolsky added the comment:
> about the problems you mentioned in msg144836, can you report
> it in a new issue or, if there are already issues about them,
> add a message there?
I believe that would be #4610.
--
nosy: +belopolsky
superseder: -> Unicode case
Alexander Belopolsky added the comment:
There has been a relatively recent discussion of case mappings under #12753
(msg144836).
I personally agree with Martin: str.upper/lower should remain the way it is - a
simplistic 1-to-1 mapping using UnicodeData.txt fields. More sophisticated
case
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file30680/42973dfea391.diff
___
Python tracker
<http://bugs.python.org/issue18236>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file30679/3ed5bb7fcee9.diff
___
Python tracker
<http://bugs.python.org/issue18236>
___
___
Pytho
Alexander Belopolsky added the comment:
I would like someone review this change:
https://bitbucket.org/alexander_belopolsky/cpython/commits/92c187025d0a8a989d9f81f2cb4c96f4eecb81cb?at=issue-18236
The patch can go in without this optimization, but I think this is the right
first step towards
Alexander Belopolsky added the comment:
It looks like at least the OP issue has been fixed in #12736:
>>> 'ß'.upper()
'SS'
--
resolution: -> out of date
status: open -> closed
superseder: -> Request for python casemapping functions to use f
Changes by Alexander Belopolsky :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15223>
___
___
Pyth
Alexander Belopolsky added the comment:
MAL> Please leave the function as it is, i.e. a 1-1 mapping to the
MAL> official, non-changing Unicode name reference (including
MAL> spelling errors, etc). Same with code points that have no name.
Since we have code points with no name - it i
Alexander Belopolsky added the comment:
Here is an example of "prior art" that is relevant to this discussion:
"""
charnames::viacode(code)
..
As mentioned above under ALIASES, Unicode 6.1 defines extra names (synonyms or
aliases) for some code points, most of which
Alexander Belopolsky added the comment:
> The .aliases() function would have to return a list, not a single
> name, so a parameter would cause the return type to change, which
> is not a good idea.
You misunderstood my proposal. .name() will still return a single name, but
the type
Alexander Belopolsky added the comment:
It is not easy to figure out the consequences (if any) of UCD change for python
grammar from unicode standard release notes. I went through this exercise for
a few releases and I thought it would be useful to share in release notes.
Since there does
Alexander Belopolsky added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue18453>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
It would be nice if this context manager had an option to redirect the file
descriptor 0 rather than just sys.stdout. (For those familiar with py.test, I
am asking for an equivalent of --capture=fd functionality.)
Unlike patching sys.stdout, which is
Alexander Belopolsky added the comment:
In my post "fd 0" should have been "fd 1", of course. (Proving that it is not
trivial to get it right:-)
--
___
Python tracker
<http://bug
Alexander Belopolsky added the comment:
Yes, I did miss Victor's dup2() comment. (It looks like I did not subscribe to
this issue from the start and missed early discussion - sorry.)
The simple feature is not very useful for me. I have to deal with too many
cases of misguided code like
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue18538>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue18481>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11571>
___
___
Pyth
Alexander Belopolsky added the comment:
I believe this is related to the fact that timedelta * float is not supported
in 2.x:
Python 2.7.5 (default, May 24 2013, 15:56:16)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or
Alexander Belopolsky added the comment:
> Does a result of one and one half seconds make sense as the result of a floor
> division operation?
Yes. Timedeltas behave as integers containing the number of microseconds:
>>> timedelta(microseconds=1) / 2
datet
Alexander Belopolsky added the comment:
Is there a reason why there is no "review" link? Could it be because the file
is uploaded as is rather than as a patch?
In any case, I have a question about this code in sum:
# Convert running total to a float. See comment
Alexander Belopolsky added the comment:
The implementation of median and mode families of functions as classes is
clever, but I am not sure it is a good idea to return something other than an
instance of the class from __new__(). I would prefer to see a more traditional
implementation along
Alexander Belopolsky added the comment:
What is so special about seconds? Why not days? As in
>>> timedelta(3) // 2
timedelta(1)
Note that in 3.x we have timedelta over timedelta division that lets you do
floor division in arbitrary time units.
What is the use case for timedel
Alexander Belopolsky added the comment:
There are two schools of thought here. One school (MAL and Mark) thinks of
durations as real number of seconds. The other school (Tim and I) think of
durations as integer number of resolution intervals. This is why I and Tim
before me resisted adding
Alexander Belopolsky added the comment:
> I just want `timedelta / int` to do the same thing in Python 2.7
> with __future__.division as `timedelta / int` does in Python 3.
It other words you want to backport timedelta / int true division. I am afraid
it is 3-4 years too late for this r
Alexander Belopolsky added the comment:
Here is the use-case that was presented to support adding additional operations
on timedelta objects:
"""
I'm conducting a series of observation experiments where I
measure the duration of an event. I then want to do various
statisti
Alexander Belopolsky added the comment:
This issue is effectively a duplicate #1083 (see msg101281.)
--
___
Python tracker
<http://bugs.python.org/issue18
Alexander Belopolsky added the comment:
I'd say fix the test. Raising ValueError is correct in this case.
UnicodeError was an implementation artifact.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
I cleaned up the patch a little:
1. Removed now unused static round_to_long() function.
2. Removed commented out code.
Mark,
Any reason not to apply this? Do we need a NEWS entry for something like this?
--
priority: low -> normal
stage: t
Alexander Belopolsky added the comment:
With the current patch we still have the following quirks:
>>> timedelta(seconds=0.6112295) == timedelta(seconds=1)*0.6112295
False
>>> timedelta(seconds=0.6112295) == timedelta(seconds=round(0.6112295, 6))
False
This is not a reason
Alexander Belopolsky added the comment:
I would just change "my usual course is to avoid using lambda" to "PEP 8
prescribes using def." Note that PEP 8 itself displays f = lambda x: 2*x as an
example of what not to do. I see no problem with the current examples.
Alexander Belopolsky added the comment:
> Once we start special-casing types, where will it end?
At the point where all stdlib types are special-cased. :-)
> In the meantime, there's a simple way to do this:
py> from datetime import timedelta as td
py> data = [td(2), td(1),
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11033>
___
___
Python-bugs-list mailing list
Un
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: -> rejected
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue1764286>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
On Mon, Aug 5, 2013 at 2:14 PM, Steven D'Aprano wrote:
> > As you say, there's no state to be stored. So why not simply have
> separate functions `median`, `median_low`, `median_high`, `median_grouped`,
> etc.?
>
> Why hav
Alexander Belopolsky added the comment:
According to this comment, ssb.values can be null:
/* A sortslice contains a pointer to an array of keys and a pointer to
* an array of corresponding values. In other words, keys[i]
* corresponds with values[i]. If values == NULL, then the keys are
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121 Refactoring applied to _csv module
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Changes by Alexander Belopolsky :
--
dependencies: +PEP 3121, 384 refactoring applied to curses_panel module
___
Python tracker
<http://bugs.python.org/issue15
Changes by Alexander Belopolsky :
--
dependencies: +PEP 384 Refactoring applied to _csv module
title: PEP 3121 Refactoring -> PEP 3121, 384 Refactoring
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
dependencies: +PEP 384 inconsistent with implementation
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Pytho
Changes by Alexander Belopolsky :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
"""
Regarding the suggestion of separating PEP3121 and PEP384. It might be true
that datetime and other modules do not benefit directly from PEP 384, however
it is still a fact that the stdlib modules should be seen as a set of reference
Alexander Belopolsky added the comment:
With respect to PEP 384 refactoring, I would like to see
Tools/scripts/abitype.py used for most of the conversions. The PEP itself can
probably be amended to advertise this tool more prominently
Alexander Belopolsky added the comment:
Eric,
Could you share details of your use-case? My experience with subclassing from
basic python types including date/time has been mostly negative. The problem
is that when I subclass, I want to inherit the rich set of operations such as
Alexander Belopolsky added the comment:
+1
:-)
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue18718>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
I strongly believe that it is worthwhile to invest in fixing abitype.py. It is
much easier to review a patch to one python script than to review 50+ patches
to C files. There is no excuse for this tool not to work on all stdlib
modules. If there are
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue18800>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alexander Schier:
> Return the total number of seconds contained in the duration. Equivalent to
> (td.microseconds + (td.seconds + td.days * 24 * 3600) * 10**6) / 10**6
> computed with true division enabled.
Should be
> Return the total number of seconds cont
Alexander Schier added the comment:
Err, sorry my fault. Too late in the evening ;).
I saw the division by one million, but not the multiplation by one million
before. Additionally i was confused, because i expected that seconds are added
to each other in the parenthesis.
closing
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue18874>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Kruppa added the comment:
It seems to me that this issue is not fixed correctly yet. I've tried Python
3.3.2:
~/build/Python-3.3.2$ ./python --version
Python 3.3.2
When modifying the test case in Lib/test/test_email/test_email.py like this:
--- Lib/test/test_email/test_ema
New submission from Alexander Kruppa:
This is a follow-up to #16564. In that issue, BytesGenerator was changed to
accept a bytes payload, however processing binary data that way leads to data
corruption.
Repost of the update I posted in #16564
Alexander Kruppa added the comment:
Opened #19003.
--
___
Python tracker
<http://bugs.python.org/issue16564>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I'll review your patch.
On Apr 18, 2012, at 4:53 PM, Joe Peterson wrote:
>
> Joe Peterson added the comment:
>
> Ah. I figured that one of the Python devs would be who would review it. Is
> this the normal path for bugs?
Alexander Belopolsky added the comment:
Joe,
Your changes to the test suit don't apply cleanly anymore. I can probably fix
the conflicts, but if you could post an updated patch it will help.
Thanks.
--
nosy: -Alexander.Belopolsky
___
P
Alexander Belopolsky added the comment:
I still get conflicts:
$ patch -p0 < imaplib_Internaldate2tuple_dst_fix_python32.patch
patching file Lib/imaplib.py
Hunk #2 FAILED at 1312.
Hunk #3 succeeded at 1347 (offset 8 lines).
Hunk #4 FAILED at 1379.
2 out of 4 hunks FAILED -- saving rejects
Alexander Belopolsky added the comment:
My bad. For some reason I assumed that the latest patch would be at the top of
the files list.
David, the patch is good. Should I go ahead and commit?
--
___
Python tracker
<http://bugs.python.
Alexander Belopolsky added the comment:
On Tue, Apr 24, 2012 at 10:42 AM, Joe Peterson wrote:
..
> Is it also possible to get the pyhton2.7 version one in?
I don't see any reason not to. This is a bug fix and should go into a
maintenance release. I will wait to hear from David, wh
Alexander Belopolsky added the comment:
This is a bit of a hack, but seems to get the work done. Does anyone have any
objections to committing?
--
___
Python tracker
<http://bugs.python.org/issue14
Alexander Belopolsky added the comment:
See issue2736.
--
nosy: +Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue14908>
___
___
Python-bug
Alexander O added the comment:
stupid question but why shouldn't this be possible ?
class Element(_Element):
def __init__(self,name,**kwargs):
_Element.__init__(self,name)
attributes = kwargs.get("attributes")
childr
Alexander Belopolsky added the comment:
Barry,
Did you review the long discussion under issue 2736? Specifically, please
note the part about mxDateTime, ticks() and gmticks(). I am -0 on adding
ticks() and gmticks() and as far as I can tell no one has implemented these
methods for
Alexander Belopolsky added the comment:
On Mon, Jun 4, 2012 at 11:57 AM, Barry A. Warsaw wrote:
> I've recently had to convert a bunch of code from using mxDateTime to
> datetime+time,
That's a valuable experience. How big of a deal was the lack of
.ticks() and .gmticks()?
Alexander Belopolsky added the comment:
On Mon, Jun 4, 2012 at 1:33 PM, Alexandre Zani wrote:
> I think the easiest and most intuitive approach is to simply define
> timestamp()
> as being the reverse of fromtimestamp().
I would like to invite everyone to review the discussion l
Alexander Belopolsky added the comment:
On Mon, Jun 4, 2012 at 3:21 PM, Alexandre Zani wrote:
> Let me know if I misunderstood Alexander, but if I didn't this should be
> documented with
> the datetime object. Based upon my understanding, the datetime object is a
> bad cho
Alexander Belopolsky added the comment:
Barry,
I looked at your changeset at
http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/revision/1354 and
at the specification at
http://developers.facebook.com/docs/reference/api/event/.
Am I correct that you are parsing "s
Alexander O added the comment:
On Jun 2, 2012 7:00 AM, "Alexandre Zani" wrote:
>
> Alexandre Zani added the comment:
>
> Here is my patch for it.
>
> --
> keywords: +patch
> Added file: http://bugs.python.org/f
New submission from Alexander Belopolsky :
Guido: Let's make it so. / python-dev
--
components: Extension Modules, Library (Lib)
messages: 162368
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Allow equality comparison between naive and aware datetime ob
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue15006>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: -Alexander.Belopolsky
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/i
Changes by Alexander Belopolsky :
--
keywords: +needs review
nosy: +pitrou
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue15006>
___
_
Changes by Alexander Belopolsky :
--
keywords: +patch
Added file: http://bugs.python.org/file25837/issue15006.diff
___
Python tracker
<http://bugs.python.org/issue15
Alexander Belopolsky added the comment:
On Wed, Jun 6, 2012 at 7:32 PM, STINNER Victor wrote:
> Hum, can you please explain your change? If it is explained on python-dev,
> can you add a link to the email?
Please see http://mail.python.org/pipermail/python-dev/2012-June/119933.html
I
Alexander Belopolsky added the comment:
I think the attached patch implements what was agreed to on python-dev. We
need more tests, particularly around DST change. I tested the patch on OSX,
but I am interested to hear feedback from users of other OSes.
--
keywords: +patch
stage
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue3367>
___
___
Python-bugs-list mailing list
Un
2101 - 2200 of 4096 matches
Mail list logo
