[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: The problem that I have with the round/truncate proposal is that it is not general enough. Days, hours, minutes etc. are just arbitrary intervals that became popular for obscure historical and astronomical reasons. In practice, you are as likely to

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > I think that a "truncate to rrule" function is *way* beyond the scope of the > standard library I agree and I did not propose that. What I said was that in the process of implementing truncate to rrule in dateutil you may encou

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > replacing all elements of a datetime below a certain level is a very common > idiom This can be accomplished rather efficiently by truncating a time tuple: >>> t = datetime.now() >>> datetime(*t.timetuple()[:6]) datetime.dat

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: I am about +0 on adding a keyword argument to datetime.now. Note that as I wrote in issue 19475 (msg202242), "precision" may be a misleading name because python makes no guarantee about the precision of the computer clock. Still, this feat

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > (And, honestly, `dateutil` would provide a version-independent backport > anyway). Why not start with that? Remember: python standard library is where code goes to die. By implementing this feature in dateutil you will not be tied to rela

[issue32267] strptime misparses offsets with microsecond format

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Change by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue32604> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33579] calendar.timegm not always an inverse of time.gmtime

Alexander Belopolsky added the comment: I was able to reproduce this issue on Linux as follows >>> import time, calendar, os >>> os.environ['TZ'] = 'right/UTC' # "right" timezones account for leap seconds >>> time.tzset() >>>

[issue33541] Remove private and apparently unused __pad function

Alexander Belopolsky added the comment: New changeset 89a25ce4fdb9c2a1a59d8cbfc498a2614b98e9ae by Alexander Belopolsky (Mario Corchero) in branch 'master': bpo-33541: Remove unused __pad function (GH-4377) https://github.com/python/cpython/commit/89a25ce4fdb9c2a1a59d8cbfc498a2

[issue33541] Remove private and apparently unused __pad function

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33579] calendar.timegm not always an inverse of time.gmtime

Alexander Belopolsky added the comment: Well, even in non-POSIX mode timegm and gmtime are the inverse of one another in BSD. The problem that you see stems from the fact that time.gmtime is implemented as a call to the namesake C function while calendar.timegm is implemented in pure Python

[issue33649] asyncio docs overhaul

Change by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue33649> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33701] test_datetime crashed (SIGSEGV) on Travis CI

Change by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue33701> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Change by Alexander Belopolsky : -- stage: -> needs patch versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue28602> ___ _

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Alexander Belopolsky added the comment: > it's actually possible to implement full `fold` support in a generic way I am aware of that. In fact, some of the draft versions of PEP 495 implementation did contain such code. The problem is that any such tz.fromutc() implementati

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Alexander Belopolsky added the comment: Paul, In your opening post to this issue you suggested to change one line [1] in Lib/datetime.py from dtdst = dt.dst() to dtdst = dt.replace(fold=1).dst() This looks like a rather innocuous change, but it does not by itself make fromutc() return

[issue33810] Remove unused code in datetime module

New submission from Alexander Belopolsky : Since implementation of issue 25283, the objects returned by time.localtime always have tm_zone and tm_gmtoff attributes, but the datetime module still has code that anticipates these attributes to be missing. [1] [1]: https://github.com/python

[issue33810] Remove unused code in datetime module

Change by Alexander Belopolsky : -- components: -Extension Modules ___ Python tracker <https://bugs.python.org/issue33810> ___ ___ Python-bugs-list mailin

[issue33810] Remove unused code in datetime module

Change by Alexander Belopolsky : -- keywords: +patch pull_requests: +7182 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue25283] Make tm_gmtoff and tm_zone available on all platforms

Change by Alexander Belopolsky : -- pull_requests: +7183 ___ Python tracker <https://bugs.python.org/issue25283> ___ ___ Python-bugs-list mailing list Unsub

[issue33810] Remove unused code in datetime module

Alexander Belopolsky added the comment: New changeset bcb032e4acdebc043a7659a06e6037fe71020860 by Alexander Belopolsky in branch 'master': bpo-33810 Remove unused code from datetime.py. (GH-7549) https://github.com/python/cpython/commit/bcb032e4acdebc043a7659a06e6037

[issue25283] Make tm_gmtoff and tm_zone available on all platforms

Alexander Belopolsky added the comment: New changeset bcb032e4acdebc043a7659a06e6037fe71020860 by Alexander Belopolsky in branch 'master': bpo-33810 Remove unused code from datetime.py. (GH-7549) https://github.com/python/cpython/commit/bcb032e4acdebc043a7659a06e6037

[issue33810] Remove unused code in datetime module

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33812] Different behavior betwee

Change by Alexander Belopolsky : -- nosy: belopolsky priority: normal severity: normal status: open title: Different behavior betwee ___ Python tracker <https://bugs.python.org/issue33

[issue33812] Different behavior between datetime.py and its C accelerator

New submission from Alexander Belopolsky : Consider the following code: $ cat bug.py import sys if len(sys.argv) > 1: sys.modules['_datetime'] = None from datetime import tzinfo, datetime, timezone class TZ(tzinfo): def utcoffset(self, t): pass print(datetime(20

[issue33812] Different behavior between datetime.py and its C accelerator

Alexander Belopolsky added the comment: So you are suggesting that my datetime(2000,1,1,tzinfo=TZ()) should behave as a naive instance, right? Well, this would be a third behavior different from both current C and Python implementations: >>> print(datetime(2000,1,1).astimezone(tim

[issue33812] Different behavior between datetime.py and its C accelerator

Change by Alexander Belopolsky : -- assignee: -> belopolsky components: +Extension Modules, Library (Lib) stage: -> needs patch type: -> behavior versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.or

[issue33812] Different behavior between datetime.py and its C accelerator

Change by Alexander Belopolsky : -- keywords: +patch pull_requests: +7202 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33812] Different behavior between datetime.py and its C accelerator

Alexander Belopolsky added the comment: Tim, given that I've updated the documentation, should we treat this as a bug fix or a feature? Note that the type check is definitely a bug-fix (if not a security issue), but I clearly had a wrong definition of "naive" in mind when I

[issue33812] Different behavior between datetime.py and its C accelerator

Change by Alexander Belopolsky : -- stage: patch review -> commit review versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue33812> ___ _

[issue33812] Different behavior between datetime.py and its C accelerator

Alexander Belopolsky added the comment: New changeset 877b23202b7e7d4f57b58504fd0eb886e8c0b377 by Alexander Belopolsky in branch 'master': bpo-33812: Corrected astimezone for naive datetimes. (GH-7578) https://github.com/python/cpython/commit/877b23202b7e7d4f57b58504fd0eb8

[issue33812] Different behavior between datetime.py and its C accelerator

Alexander Belopolsky added the comment: New changeset 037e9125527d4a55af566f161c96a61b3c3fd998 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-33812: Corrected astimezone for naive datetimes. (GH-7578) (GH-7600) https://github.com/python/cpyt

[issue33812] Different behavior between datetime.py and its C accelerator

Alexander Belopolsky added the comment: New changeset 1d4089b5d208ae6f0bd256304fd77f04c0b4fd41 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.6': bpo-33812: Corrected astimezone for naive datetimes. (GH-7578) (GH-7601) https://github.com/python/cpyt

[issue33812] Different behavior between datetime.py and its C accelerator

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33849] Caught infinite recursion resets the trace function

New submission from Alexander Belopolsky : Consider the following code: import sys def trace(frame, event, arg): pass def f(): f() sys.settrace(trace) print(sys.gettrace()) try: f() except RuntimeError: pass print(sys.gettrace()) When I run it, I get None Apparently, the

[issue33849] Caught infinite recursion resets the trace function

Alexander Belopolsky added the comment: It looks like this has been known for quite some time. See issue10933. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33849] Caught infinite recursion resets the trace function

Change by Alexander Belopolsky : -- stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33849> ___ ___

[issue33849] Caught infinite recursion resets the trace function

Change by Alexander Belopolsky : -- resolution: -> duplicate superseder: -> Tracing disabled when a recursion error is triggered (even if properly handled) ___ Python tracker <https://bugs.python.org/i

[issue30516] Documentation for datetime substract operation incorrect?

Alexander Belopolsky added the comment: New changeset 5b6e49a1393b3e2313471696e3568e26296137b4 by Alexander Belopolsky (Farhaan Bukhsh) in branch 'master': bpo-30516: Fix documentation issue with -timedelta in datetime (GH-7348) https://github.com/python/cpyt

[issue30516] Documentation for datetime substract operation incorrect?

Alexander Belopolsky added the comment: New changeset 55f39bdabc91b387c18451c78ee077e6d05d6cfe by Alexander Belopolsky (Miss Islington (bot)) in branch '3.6': bpo-30516: Fix documentation issue with -timedelta in datetime (GH-7348) (GH-8092) https://github.com/python/cpyt

[issue30516] Documentation for datetime substract operation incorrect?

Alexander Belopolsky added the comment: New changeset a8bb18bbb9c286cfac5a0b8c8679c440e5c49305 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-30516: Fix documentation issue with -timedelta in datetime (GH-7348) (GH-8093) https://github.com/python/cpyt

[issue30516] Documentation for datetime substract operation incorrect?

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34008] Do we support calling Py_Main() after Py_Initialize()?

Change by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue34008> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs

Alexander Belopolsky added the comment: Unfortunately, the PEP authors did very little in terms of implementing the PEP and neither CPython nor numpy has a fully compliant implementation. -- nosy: +aerojockey, teoliphant ___ Python tracker <ht

[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs

Change by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Un

[issue29097] [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

Alexander Belopolsky added the comment: New changeset 96d1e69a12ed8ab80203277e1abdaf573457a964 by Alexander Belopolsky (Ammar Askar) in branch 'master': bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) https://github.com/python/cpyt

[issue29097] [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

Alexander Belopolsky added the comment: New changeset 973649342cee3869409f341ff0f0e3d2b1547c2a by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8466) https://github.com/python/cpyt

[issue29097] [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

Alexander Belopolsky added the comment: New changeset 6ea8a3a0ebf840ca57b6dba9cad26fbb0ddaa5d4 by Alexander Belopolsky (Ammar Askar) in branch '3.6': [3.6] bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8498) https://github.com/python/cpyt

[issue30140] Binary arithmetic does not always call subclasses first

Change by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue30140> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34158] Documentation of datetime '%z' format code is odd

Alexander Belopolsky added the comment: New changeset 92878829c31ab2fc71c60555ce87a5f6cbc876f0 by Alexander Belopolsky (Christophe Nanteuil) in branch 'master': bpo-34158: Documentation UTC offset update (GH-8377) https://github.com/python/cpyt

[issue34672] '%Z' strftime specifier never works with musl

Alexander Belopolsky added the comment: It looks like this issue has been fixed by GH-9288. Can this be closed? Should we backport? -- ___ Python tracker <https://bugs.python.org/issue34

[issue22377] %Z in strptime doesn't match EST and others

Alexander Belopolsky added the comment: I think strptime should only accept %Z when it comes together with %z and not do any validation. This is close to the current behavior. %Z by itself is useless because even when it is accepted, the value is discarded: >>> print(datetime

[issue33940] datetime.strptime have no directive to convert date values with Era and Time Zone name

Alexander Belopolsky added the comment: Since the Python datetime only supports dates within 0001-01-01 through -12-31 range, it is not clear how we can meaningfully support the AD/BC era designation. Looking at man strftime page on my Mac, I see that they use every upper an lower case

[issue33940] datetime.strptime have no directive to convert date values with Era and Time Zone name

Change by Alexander Belopolsky : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33940] datetime.strptime have no directive to convert date values with Era and Time Zone name

Change by Alexander Belopolsky : -- superseder: -> %Z in strptime doesn't match EST and others ___ Python tracker <https://bugs.python.org/issue33940> ___

[issue17005] Add a topological sort algorithm

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 relate

[issue17267] datetime.time support for '+' and 'now'

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

[issue17267] datetime.time support for '+' and 'now'

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 <h

[issue17267] datetime.time support for '+' and 'now'

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,

[issue17267] datetime.time support for '+' and '-'

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 '-' ___

[issue8902] add datetime.time.now() for consistency

Changes by Alexander Belopolsky : -- resolution: wont fix -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue8902> ___ ___ Pyth

[issue8902] add datetime.time.now() for consistency

Changes by Alexander Belopolsky : -- nosy: +ronaldoussoren ___ Python tracker <http://bugs.python.org/issue8902> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17486] datetime.timezone returns the wrong tzname()

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

[issue17342] datetime.strptime does not implement %z

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", "copyr

[issue6632] Include more chars in the decimal codec

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

[issue18176] Builtins documentation refers to old version of UCD.

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

[issue6632] Include more chars in the decimal codec

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 d

[issue18178] Redefinition of malloc(3) family of functions at build time

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: +Pyth

[issue18176] Builtins documentation refers to old version of UCD.

Changes by Alexander Belopolsky : -- hgrepos: +197 ___ Python tracker <http://bugs.python.org/issue18176> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18176] Builtins documentation refers to old version of UCD.

Changes by Alexander Belopolsky : -- keywords: +patch Added file: http://bugs.python.org/file30531/686836ad3042.diff ___ Python tracker <http://bugs.python.org/issue18

[issue18176] Builtins documentation refers to old version of UCD.

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: ->

[issue10382] Command line error marker misplaced on unicode entry

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

[issue2382] [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 cha

[issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line.

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 <http://bugs.python.org/i

[issue6632] Include more chars in the decimal codec

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

[issue10581] 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 + an

[issue10581] Review and document string format accepted in numeric data type constructors

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

[issue18176] Builtins documentation refers to old version of UCD.

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file30608/bd092995907c.diff ___ Python tracker <http://bugs.python.org/issue18176> ___ ___ Python-bug

[issue18176] Builtins documentation refers to old version of UCD.

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 compile

[issue18231] What's new in Python should explain what's new in UCD

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 that

[issue18231] What's new in Python should explain what's new in UCD

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') Tra

[issue18176] Builtins documentation refers to old version of UCD.

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 was

[issue18234] Unicodedata module should provide access to codepoint aliases

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

[issue10581] Review and document string format accepted in numeric data type constructors

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

[issue18236] int() and float() do not accept strings with trailing separators

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: >>>

[issue10581] Review and document string format accepted in numeric data type constructors

Alexander Belopolsky added the comment: i opened issue18236 to address the issue of surrounding whitespace. -- ___ Python tracker <http://bugs.python.org/issue10

[issue10581] Review and document string format accepted in numeric data type constructors

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

[issue18231] What's new in Python should explain what's new in UCD

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.

[issue18234] Unicodedata module should provide access to codepoint aliases

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

[issue18236] int() and float() do not accept strings with trailing separators

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

[issue18236] int() and float() do not accept strings with trailing separators

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

[issue18236] int() and float() do not accept strings with trailing separators

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

[issue18236] int() and float() do not accept strings with trailing separators

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

[issue18236] int() and float() do not accept strings with trailing separators

Changes by Alexander Belopolsky : -- hgrepos: +201 ___ Python tracker <http://bugs.python.org/issue18236> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18236] int() and float() do not accept strings with trailing separators

Changes by Alexander Belopolsky : -- keywords: +patch Added file: http://bugs.python.org/file30677/5c934626d44d.diff ___ Python tracker <http://bugs.python.org/issue18

[issue18236] str.isspace should use the Unicode White_Space property

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 ->

[issue18236] str.isspace should use the Unicode White_Space property

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file30679/3ed5bb7fcee9.diff ___ Python tracker <http://bugs.python.org/issue18236> ___ ___ Python-bug

[issue18236] str.isspace should use the Unicode White_Space property

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file30677/5c934626d44d.diff ___ Python tracker <http://bugs.python.org/issue18236> ___ ___ Pytho

[issue10581] Review and document string format accepted in numeric data type constructors

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

[issue10581] Review and document string format accepted in numeric data type constructors

Changes by Alexander Belopolsky : -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue10581> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    13   14   15   16   17   18   19   20   21   22   >