[issue19213] platform.linux_distribution detects Oracle Linux as Red Hat Enterprise Linux

Alexander Boyd added the comment: Yep, that fixes it. -- ___ Python tracker <http://bugs.python.org/issue19213> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19265] Increased test coverage for datetime pickling

Alexander Belopolsky added the comment: I guess the extra coverage is in "if getstate" branch of class tzinfo: ... def __reduce__(self): getinitargs = getattr(self, "__getinitargs__", None) if getinitargs: args = getinitargs() el

[issue19376] document that strptime() does not support the Feb 29 if the format does not contain the year

Alexander Belopolsky added the comment: > what's the reason for accepting the time.strptime() > version as a bug, but not datetime.datetime.strptime()? In case of time.strptime(), we have an option of returning (1900, 2, 29, ..) which while not being a valid date, is a valid

[issue19435] Directory traversal attack for CGIHTTPRequestHandler

New submission from Alexander Kruppa: An error in separating the path and filename of the CGI script to run in http.server.CGIHTTPRequestHandler allows running arbitrary executables in the directory under which the server was started. The problem is that in CGIHTTPRequestHandler we have

[issue19502] Wrong time zone offset, when using time.strftime() with a given struct_time

Alexander Belopolsky added the comment: I cannot reproduce this and I suspect that the problem shows up only in certain times. I believe this is related to the long-standing issue that was fixed in 3.3. See issue 1667546. In Python prior to 3.3, time_struct did not store timezone

[issue19502] Wrong time zone offset, when using time.strftime() with a given struct_time

Alexander Belopolsky added the comment: > The documentation for time.strftime(format[, t]) reads: > "If t is not provided, the current time as returned by localtime() is used" > but apparently there must be something extra going on under the hood. Yes, the C implementati

[issue19475] Add microsecond flag to datetime isoformat()

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

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: +1 on adding an option to isoformat(). We already have an optional argument, so the symmetry with __str__ is not complete. To make this option more useful, rather than implementing always_emit_microseconds=False flag, I would add a keyword argument

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: +1 on all Victor's points. I like 'resolution' because this is the term that datetime module uses already: >>> from datetime import * >>> datetime.resolution datetime.timedelta(0, 0, 1) There is a slight chance of conf

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: MAL: Have you thought about the rounding/truncation issues associated with not showing microseconds ? I believe it has to be the truncation. Rounding is better left to the user code where it can be done either using timedelta arithmetics or at the time

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: I am afraid that the rounding issues may kill this proposal. Can we start with something simple? For example, we can start with show=None keyword argument and allow a single value 'microseconds' (or 'us'). This will solve the i

[issue18144] FD leak in urllib2

Changes by Alexander Boyd : -- nosy: +javawizard ___ Python tracker <http://bugs.python.org/issue18144> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12955] urllib.request example should use "with ... as:"

Changes by Alexander Boyd : -- nosy: +javawizard ___ Python tracker <http://bugs.python.org/issue12955> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: I would like to hear from others on this feature. One concern that I have is whether it is wise to truncate the fractional seconds part in '%s'. Also, if we support '%s' in strftime we should probably support it in strptime as we

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: > It is not clear what the returned value for %s strptime should be: I would start conservatively and require %z to be used with %s. In this case, we can easily produce aware datetime objects. I suspect that in the absence of %z, the most useful opt

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: On the second thought, I don't think accepting this should be contingent on any decision with respect to strptime. -- assignee: -> belopolsky stage: needs patch -> commit review ___ Python tra

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: > rounding problem fixed with math.floor Can you explain why math.floor rather than builtin round is the correct function to use? -- ___ Python tracker <http://bugs.python.org/issu

[issue13277] tzinfo subclasses information

Alexander Belopolsky added the comment: I would say this is a doc issue. There are some tzinfo algorithms that depend on utcoffset(dt)-dst(dt) being invariant, but this is the part of datetime library that I have never fully understood. What I do understand is that conversion from local time

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: Here is the simpler demonstration of the "floor" behavior on Linux: >>> from datetime import datetime >>> datetime.fromtimestamp(-0.1).strftime('%s') '-1' >>> datetime.fromtimestamp(-1.1).strftim

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: Could you, please add tests for non-fixed offset timezones? There are several defined in datetimetester.py already. -- versions: +Python 3.5 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue12

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: The patch should update documentation. See https://docs.python.org/3.5/library/datetime.html#strftime-and-strptime-behavior -- ___ Python tracker <http://bugs.python.org/issue12

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: +t = datetime(1969, 1, 1, 0,0,0, 60, tzinfo=timezone.utc) Please add spaces after commas. -- ___ Python tracker <http://bugs.python.org/issue12

[issue13413] time.daylight incorrect behavior in linux glibc

Alexander Belopolsky added the comment: I think this is out-of-date. On Mac OS X, I get ``` $ python3 -V Python 3.4.1 $ TZ=Europe/Moscow python3 -c "import time; print(time.daylight)" 0 ``` I'll check on Linux now ... -- ___ Python

[issue13413] time.daylight incorrect behavior in linux glibc

Alexander Belopolsky added the comment: Same result on a freshly compiled Python 3.4.1 (default, Jun 29 2014, 15:26:46) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux $ TZ=Europe/Moscow ~/Apps/bin/python3 -c "import time; print(time.daylight)" 0 I suspect that the problem was

[issue13413] time.daylight incorrect behavior in linux glibc

Alexander Belopolsky added the comment: > But python detect daylight flag as differences between January and July > localtime. This is the best we can do because time.daylight is a constant and this does not work in locations like Moscow where daylight rules were adopted ~ 30 years a

[issue13413] time.daylight incorrect behavior in linux glibc

Alexander Belopolsky added the comment: I suspect there will be another period soon when time.daylight logic will break after Europe/Moscow goes back to winter time (hopefully for good). There is no solution of this issue within constraints of the time module. See issue9527 for how it was

[issue9051] Improve pickle format for aware datetime instances

Changes by Alexander Belopolsky : -- nosy: +alexandre.vassalotti, haypo, pitrou ___ Python tracker <http://bugs.python.org/issue9051> ___ ___ Python-bugs-list m

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

Alexander Belopolsky added the comment: Reclassifying this as a doc issue. -- components: +Documentation -Extension Modules stage: test needed -> needs patch versions: +Python 3.5 -Python 3.3 ___ Python tracker <http://bugs.python.org/iss

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

Changes by Alexander Belopolsky : -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue9004> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change

Alexander Belopolsky added the comment: David, Is there anything left to do here that is not covered by issue 11024? -- ___ Python tracker <http://bugs.python.org/issue10

[issue1062277] Pickle breakage with reduction of recursive structures

Alexander Belopolsky added the comment: Problem "B" has been resolved, but problem "A" is still there. Python 3.4.1 (default, Jun 29 2014, 15:26:46) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux Type "help", "copyright", "credits" or "

[issue9860] Building python outside of source directory fails

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.o

[issue10541] regrtest.py -T broken

Changes by Alexander Belopolsky : -- versions: +Python 3.5 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-list mailin

[issue10541] regrtest.py -T broken

Changes by Alexander Belopolsky : -- stage: patch review -> commit review ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-list mai

[issue10541] regrtest.py -T broken

Changes by Alexander Belopolsky : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-

[issue20858] Enhancements/fixes to pure-python datetime module

Alexander Belopolsky added the comment: Brian, I would like to apply your changes for 3.5. Do you have any updates? -- stage: patch review -> commit review versions: +Python 3.5 -Python 3.3, Python 3.4 ___ Python tracker <http://bugs.pyth

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

Alexander Belopolsky added the comment: I would like to bring this issue to some conclusion. Here is the summary: Pro: datetime.time.now() is shorter than datetime.datetime.now().time() Cons: 1. date, time = datetime.date.today(), datetime.time.now() is attractive, but wrong. 2

[issue1812] doctest _load_testfile function -- newline handling seems incorrect

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue1812> ___ ___ Python-bugs-list mailing list Un

[issue3173] external strftime for Python?

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue3173> ___ ___ Python-bugs-list mailing list Un

[issue10446] pydoc3 links to 2.x library reference

Alexander Belopolsky added the comment: MODULE DOCS section is no longer present in pydoc generated pages. -- resolution: accepted -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue7229] Manual entry for time.daylight can be misleading

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

[issue10552] Tools/unicode/gencodec.py error

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue10552> ___ ___ Python-bugs-list mailing list Un

[issue10552] Tools/unicode/gencodec.py error

Changes by Alexander Belopolsky : -- nosy: +hynek, ned.deily, ronaldoussoren ___ Python tracker <http://bugs.python.org/issue10552> ___ ___ Python-bugs-list mailin

[issue9267] Update pickle opcode documentation in pickletools for 3.x

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue9267> ___ ___ Python-bugs-list mailing list Un

[issue15711] PEP 3121, 384 Refactoring applied to time module

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue15711> ___ ___ Python-bugs-list mailing list Un

[issue15884] PEP 3121, 384 Refactoring applied to ctypes module

Changes by Alexander Belopolsky : -- assignee: belopolsky -> nosy: +amaury.forgeotdarc, meador.inge ___ Python tracker <http://bugs.python.org/issu

[issue15884] PEP 3121, 384 Refactoring applied to ctypes module

Changes by Alexander Belopolsky : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue15884> ___ ___ Python-bugs-list mailin

[issue8810] TZ offset description is unclear in docs

Alexander Belopolsky added the comment: Isn't this a duplicate of #9305? -- assignee: belopolsky -> versions: +Python 3.5 -Python 3.2 ___ Python tracker <http://bugs.python.or

[issue9305] Don't use east/west of UTC in date/time documentation

Changes by Alexander Belopolsky : -- dependencies: +Don't use east/west of UTC in date/time documentation ___ Python tracker <http://bugs.python.org/i

[issue9305] Don't use east/west of UTC in date/time documentation

Alexander Belopolsky added the comment: This seems to be touching the same areas as #9305. -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/iss

[issue9034] datetime module should use int32_t for date/time components

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <http://bugs.python.org/issue9034> ___ ___ Python-bugs-list mailing list Un

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

Changes by Alexander Belopolsky : -- assignee: belopolsky -> keywords: -needs review, patch stage: commit review -> needs patch versions: +Python 3.5 -Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/i

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

Alexander Belopolsky added the comment: For future reference, the code discussed above is in the following portion of the patch: -#define Py_UNICODE_ISSPACE(ch) \ -((ch) < 128U ? _Py_ascii_whitespace[(ch)] : _PyUnicode_IsWhitespace(ch)) +#define Py_UNICODE_ISSPACE

[issue15870] PyType_FromSpec should take metaclass as an argument

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

[issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text correctly

Changes by Alexander Belopolsky : -- assignee: belopolsky -> versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue9769> ___ ___ Py

[issue9256] plistlib should create non-naïve datetime objects

Changes by Alexander Belopolsky : -- assignee: belopolsky -> nosy: +hynek, ned.deily, ronaldoussoren versions: +Python 3.5 -Python 3.2 ___ Python tracker <http://bugs.python.org/iss

[issue9256] plistlib should create non-naïve datetime objects

Changes by Alexander Belopolsky : -- assignee: -> ronaldoussoren components: +Macintosh ___ Python tracker <http://bugs.python.org/issue9256> ___ ___ Python-

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- assignee: belopolsky -> versions: +Python 3.5 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue5288> ___ ___ Py

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Alexander Belopolsky added the comment: Eli, Given your last comment, are you still proposing your patch for inclusion or should we take the #8915 approach? -- assignee: belopolsky -> nosy: -Alexander.Belopolsky versions: +Python 3.5 -Python

[issue12006] strptime should implement %V or %u directive from libc

Alexander Belopolsky added the comment: Ashley, I would like to include your patch in 3.5. Can you combine your doc and code changes in one diff and make sure it is up to date with the tip. Thanks. -- stage: patch review -> commit review versions: +Python 3.5 -Python

[issue10342] trace module cannot produce coverage reports for zipped modules

Alexander Belopolsky added the comment: I updated the patch for 3.5. [Brett] > I don't quite see the point of the get_source call as it isn't returned or > used. It *is* used: it is passed to _find_strings_stream: +source = loader.get_source(modulenam

[issue5207] extend strftime/strptime format for RFC3339 and RFC2822

Changes by Alexander Belopolsky : -- status: open -> closed versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue5207> ___ ___ Py

[issue1170] shlex have problems with parsing unicode

Changes by Alexander Belopolsky : -- assignee: belopolsky -> versions: +Python 3.5 ___ Python tracker <http://bugs.python.org/issue1170> ___ ___ Python-

[issue9398] Unify sys.settrace and sys.setprofile tests

Changes by Alexander Belopolsky : -- versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9

[issue9051] Improve pickle format for aware datetime instances

Alexander Belopolsky added the comment: I updated the patch. Please note that it only includes python code, so you need to suppress _datetime acceleration to test: >>> import sys >>> sys.modules['_datetime'] = None >>> from pickle import * >>> fr

[issue9051] Improve pickle format for aware datetime instances

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17769/issue9051-utc-pickle-proto.diff ___ Python tracker <http://bugs.python.org/issue9

[issue9051] Improve pickle format for aware datetime instances

Changes by Alexander Belopolsky : -- versions: +Python 3.5 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue9051> ___ ___ Python-bugs-list mailin

[issue9051] Improve pickle format for aware datetime instances

Alexander Belopolsky added the comment: Hmm. Still no "review" link. Is there something special that I need to do to get it? Use different name, maybe? -- ___ Python tracker <http://bugs.python.

[issue9051] Improve pickle format for aware datetime instances

Alexander Belopolsky added the comment: > I see review links for both of your files Now I do too. I guess they just take time to appear. Note that I unlinked the file that Antoine complained about. -- ___ Python tracker <http://bugs.pyth

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: Here is some "prior art": GNU date utility has an --iso-8601[=timespec] option defined as ‘-I[timespec]’ ‘--iso-8601[=timespec]’ Display the date using the ISO 8601 format, ‘%Y-%m-%d’. The argument timespec specifies the number of additional te

[issue19475] Add microsecond flag to datetime isoformat()

Alexander Belopolsky added the comment: Based on GNU date "prior art", we can introduce timespec='auto' keyword argument with the following values: 'auto' - (default) same as current behavior 'hours' - %H 'minutes

[issue15787] PEP 3121, 384 Refactoring

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

[issue21966] InteractiveConsole does not support -q option

New submission from Alexander Belopolsky: When invoked with -q option, python3 prints no banner: $ python3 -q >>> However, code.InteractiveConsole does not implement this feature: $ python3 -mcode -q Python 3.4.1 (default, May 19 2014, 13:10:29) [GCC 4.2.1 Compatible Apple LLVM 5

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: I added "documentation" to the components list because this in the main purpose of this module - to serve as a template for extension module writers. -- assignee: -> docs@python components: +Documentation nosy:

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Changes by Alexander Belopolsky : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailin

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: > create another pep-384 version +1 - and with a more descriptive name than xxmodule.c Suggestions: * pep384module.c * pep384demo.c * pep384.c * abidemo.c -- ___ Python tracker <http://bugs.pyth

[issue21966] InteractiveConsole does not support -q option

Alexander Belopolsky added the comment: That was quick! (Well - I knew it would not be hard.) I have two questions: 1. How should python3 -q -mcode behave? 2. If we add this patch, should we also attempt to emulate other command line options (-V, -h, etc.)? -- assignee

[issue21966] InteractiveConsole does not support -q option

Changes by Alexander Belopolsky : -- components: +Library (Lib) ___ Python tracker <http://bugs.python.org/issue21966> ___ ___ Python-bugs-list mailing list Unsub

[issue21966] InteractiveConsole does not support -q option

Alexander Belopolsky added the comment: In order to implement reasonable rejection behavior, we probably need to add some support for -h. $ python3 -z Unknown option: -z usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. I don'

[issue21966] InteractiveConsole does not support -q option

Alexander Belopolsky added the comment: > I think we should check for -q both before -m and after, because why not? If we check for sys.flags.quiet, wouldn't it be surprising to have $ python3 -mcode -q >>> import sys;

[issue21966] InteractiveConsole does not support -q option

Alexander Belopolsky added the comment: A nitpick: banner=banner in + interact(banner=banner) is redundant. + interact(banner) would work and is just as clear. -- ___ Python tracker <http://bugs.python.org/issue21

[issue21966] InteractiveConsole does not support -q option

Alexander Belopolsky added the comment: Committed. Thanks, Anton. -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue20858] Enhancements/fixes to pure-python datetime module

Alexander Belopolsky added the comment: Brian, Could you, please update the summary of your changes from your first post? For example, you did not mention caching of the timedelta hashes. This particular chance seems to call for a discussion. Do we cache timedelta hashes in C implementation

[issue20858] Enhancements/fixes to pure-python datetime module

Alexander Belopolsky added the comment: > Updated patch, now it also caches the result of __hash__ like the C > accelerator. I should read your notes! Sorry, Brian. You already answered my questions. Too bad that the latest notes are so far from the entry area. Still, it would be h

[issue20858] Enhancements/fixes to pure-python datetime module

Alexander Belopolsky added the comment: [Josh Rosenberg] > You've just given me an excuse to open my first bug. Did you open an issue for that? (Use "n" code in date/datetime constructors.) -- ___ Python tracker <http://bugs.

[issue20858] Enhancements/fixes to pure-python datetime module

Alexander Belopolsky added the comment: Here is the tuple hash caching thread that I mentioned above: https://mail.python.org/pipermail/python-dev/2003-August/037416.html Since the C code uses caching already, I don't think we need to discuss it any further. And the thread on tuples doe

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: Given that struct timespec defined as struct timespec { time_t tv_sec;/* seconds */ long tv_nsec; /* nanoseconds */ }; is slowly becoming the prevailing standard to represent time

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: numpy's datetime64 and timedelta64 types are so utterly broken that I would only recommend studying them as a negative example of how not to design a date-time library. -- ___ Python tracker

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: > (there's no room for an extra 10 bits in the > carefully arranged 8-byte internal representation) According to a comment on top of Include/datetime.h, the internal representation of datetime is 10, not 8 bytes. /* Fields are packed into

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: > Guessing Guido was actually thinking about the pickle size No, pickle also comes with an overhead >>> from datetime import * >>> import pickle >>> t = datetime.now() >>> len(pickle.dumps(t)) 70 For the present di

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: The following code demonstrates that we can pack year through second fields in 40 bits: #include struct dt { unsigned year :14; /* 1- of 0-16,383 */ unsigned month :4; /* 1-12 of 0-16 */ unsigned day :5; /* 1-31 of 0-31 */ unsigned

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: > I suppose another possibility is to get rid of microseconds > internally, and work with a single 4-byte nanosecond member. Yes, that is what I think we should do. I would also split it from the packed fields to give it a 32-bit alignment which

[issue15443] datetime module has no support for nanoseconds

Alexander Belopolsky added the comment: If alignment is not required (as is the case in pickle), we can pack year through second + nanosecond fields in 9 bytes. For backwards compatibility we should continue accepting 10-byte pickles, but we can write in a new 9-byte format

[issue22005] datetime.__setstate__ fails decoding python2 pickle

Changes by Alexander Belopolsky : -- nosy: +alexandre.vassalotti, pitrou ___ Python tracker <http://bugs.python.org/issue22005> ___ ___ Python-bugs-list mailin

[issue22058] datetime.datetime() should accept a datetime.date as init parameter

Alexander Belopolsky added the comment: +1 There is currently no obvious way to convert either date or datetime instance to date. The best solution I can think of is date(*x.timetuple()[:3]): >>> d = date.today() >>> t = datetime.now() >>> date(*d.timetuple()[:3]

[issue22058] datetime.datetime() should accept a datetime.date as init parameter

Alexander Belopolsky added the comment: > some_datetime_object.date() is the obvious way to extract a > date object from a datetime object. Sorry if I was not clear enough about my use case. I often have to deal with functions that are designed to take either date or datetime object

[issue22058] datetime.datetime() should accept a datetime.date as init parameter

Alexander Belopolsky added the comment: Another "solution" is date(2001, 1, 1).__lt__(x), but this is even uglier than the one with timetuple. -- ___ Python tracker <http://bugs.python.o

[issue22058] datetime.datetime() should accept a datetime.date as init parameter

Alexander Belopolsky added the comment: It is not as mush about avoiding a one-liner as it is about duck-typing. IMO, dates and datetime objects are numbers in disguise. Many functions that are nominally numeric, can work with date/datetime/timedelta objects without modification. The fact

[issue22043] Use a monotonic clock to compute timeouts

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

<    20   21   22   23   24   25   26   27   28   29   >