Alexander Belopolsky added the comment:
Closing. See #22798 for the reasons why synchronizing C variables with the time
module constants is not a solution.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
New submission from Alexander Belopolsky:
The time module defines timezone, altzone, tzname and daylight constants that
store information about system timezone. This information is derived from the
timezone rules that are in effect at the module loading time, but may be
incorrect for the
Changes by Alexander Belopolsky :
--
superseder: -> Document time module constants (timezone, tzname, etc.) as
deprecated.
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
> Maybe we can just pick a prototype that's as Pythonesque as possible that
> also fixes these shortcomings. Any thoughts?
Yes, and just call it _PyTime_localtime without the ugly suffix.
--
___
Alexander Belopolsky added the comment:
Very nice. I'll give it a week or two for the others to chime in and commit if
I don't hear any objections.
--
keywords: +patch
stage: patch review -> commit review
versions: +Python 3.7
___
P
Alexander Belopolsky added the comment:
I see that you picked localtime_s-like order of arguments. While I have no
personal preference, I wonder why you prefer output to follow input. The usual
UNIX/C convention is the opposite. Interfaces like sprintf, strcat, strftime
and many other have
Alexander Belopolsky added the comment:
> I thought `[...]localtime_r()`'s way of ordering the arguments made most
> sense here.
Right. I keep forgetting which one is localtime_r and which is localtime_s. I
don't think there is any preference in the Python codebase. (PEP 8 is
New submission from Alexander Belopolsky:
With the implementation of PEP 495, email.utils.localtime() does not need the
isdst argument to disambiguate naive time. In fact the utility method itself
is redundant given that astimezone() now works for naive instances.
--
components
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
priority: high ->
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
title: Document that time.tzset updates time module constants -> Document that
time.tzset updates time module globals
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
I am not sure this is possible to fix without refactoring the datetime module
according to PEP 3121. See #15390.
--
___
Python tracker
<http://bugs.python.org/issue27
Alexander Belopolsky added the comment:
Yes, I think something like the attached patch may do the trick.
--
assignee: -> belopolsky
keywords: +patch
versions: +Python 3.6, Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file44678/issue27400.pa
Alexander Belopolsky added the comment:
Closing in favor of #28157.
--
status: open -> closed
superseder: -> Document time module constants (timezone, tzname, etc.) as
deprecated.
___
Python tracker
<http://bugs.python.org/i
Changes by Alexander Belopolsky :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19502>
___
___
Pyth
Changes by Alexander Belopolsky :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10213>
___
___
Pyth
Alexander Belopolsky added the comment:
> didn't find any existing place to put it into. Any suggestions?
I would put it in Include/pymacconfig.h.
--
___
Python tracker
<http://bugs.python.org
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
The problem of computing tm_gmtoff on platforms without it was solved by tzcode
some time ago. [1,2] Consider stealing some of their logic.
[1]: http://mm.icann.org/pipermail/tz/2014-September/021601.html
[2]: https://github.com/eggert/tz/commit
Alexander Belopolsky added the comment:
Another advantage of a single nanoseconds field is that currently microseconds
are packed in 3 bytes and nanoseconds would fit in 4 - a 1 byte increase, but
to add a 0-999 field, one would need at least 2 bytes.
--
versions: +Python 3.7 -Python
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/issue15873>
___
___
Python-bugs-list mailin
New submission from Alexander Sosedkin:
I've managed to obtain several objects, which __getattribute__ cannot be
applied to them.
Minimal non-working example (a more detailed one is attached):
b = abs.__class__
b.__getattribute__(b, 'x')
Proxying such objects turned out to be e
Alexander Sosedkin added the comment:
Oh, I see. The invocation b.__getattribute__(b, attrname) worked on so many
objects that I didn't even think it could be incorrect.
Sorry for wasting your time.
--
resolution: -> not a bug
status: pending -
Alexander Bayandin added the comment:
Yury, in 3.6 is added support for multiple hosts for create_server but not for
multiple ports which I suggest to add.
--
resolution: out of date ->
status: closed -> open
versions: -Python 3.5
___
Alexander Belopolsky added the comment:
I would leave itermonthdates() alone and just fix itermonthdays2() (and
itermonthdays() for consistency) as Xiang suggested. The fix can be
implemented by breaking on date.month != month and adding something like
for wd in range(date.weekday(), 7
Alexander Belopolsky added the comment:
On the second thought, I don't see why itermonthdays2() and itermonthdays()
need to use itermonthdates() at all. It looks like it is easy to implement
those using monthrange() and some simple integer arithm
Alexander Belopolsky added the comment:
Note that the stop on date.max behavior was introduced in #15421.
--
___
Python tracker
<http://bugs.python.org/issue28
Alexander Belopolsky added the comment:
> itermonthdates() is documented public method
The current documentation is an impossibility:
"The iterator will yield datetime.date values and will always iterate through
complete weeks, so it will yield dates outside the specified
month."
Alexander Belopolsky added the comment:
I am attaching the proposed reimplementation of itermonthdays2() and
itermonthdays(). It does not use itermonthdates() and is not that complicated.
It passes test_calendar, but I did not test it further than that.
I would rather not mess up with
New submission from Alexander Belopolsky:
The calendar module currently relies on datetime for some calculations and is
therefore restricted to years 1 through . With exception to some public
methods that are documented to return datetime.date instances, this dependence
on the datetime
Alexander Belopolsky added the comment:
> unless we remove all date limits that is much harder issue
I don't think this is too hard. I think the original implementation did not
have date limits. I've opened a separate issue for this
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue8957>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
issue28253-2.diff is a small performance improvement over issue28253.diff
--
Added file: http://bugs.python.org/file44835/issue28253-2.diff
___
Python tracker
<http://bugs.python.org/issue28
Alexander Belopolsky added the comment:
issue28253-3.diff uses itertools.repeat().
--
Added file: http://bugs.python.org/file44836/issue28253-3.diff
___
Python tracker
<http://bugs.python.org/issue28
Alexander Belopolsky added the comment:
issue28253-4.diff is issue28253-3.diff with tests.
--
Added file: http://bugs.python.org/file44837/issue28253-4.diff
___
Python tracker
<http://bugs.python.org/issue28
Alexander Belopolsky added the comment:
My patch for issue 28253 fixes this problem for itermonthdays2() and
itermonthdays() methods. As discussed there, fixing itermonthdates() would
require changing a documented public interface.
--
assignee: -> belopolsky
nosy: +belopol
Alexander Belopolsky added the comment:
> The patch LGTM except tests.
What are your issues with the tests? Did you see the -4 patch?
> But we should at least document the behavior of itermonthdates(),
> monthdatescalendar() and yeardatescalendar() at corner cases.
I would rathe
Alexander Belopolsky added the comment:
> What's the use case for this?
Why did George Mallory climb Mount Everest? "Because it's there."
We have two open issues complaining about calendar behavior for years 1 and
: #28253 and #26650. There is also a closed issue #
Alexander Belopolsky added the comment:
Something went wrong with issue28253-4.diff. I'll investigate and replace.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file44845/issue28253-4.diff
___
Python tracker
<http://bugs.python.org/issue28253>
___
___
Python-bug
Alexander Belopolsky added the comment:
issue28253-4.diff should be good now.
--
___
Python tracker
<http://bugs.python.org/issue28253>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file44837/issue28253-4.diff
___
Python tracker
<http://bugs.python.org/issue28253>
___
___
Pytho
Alexander Belopolsky added the comment:
Under my proposal year=-1 is 2 B.C. and year 0 is a leap year
$ ./python.exe -mcalendar 0 2
February 0
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29
This is the simplest extension and
New submission from Alexander Belopolsky:
The Calendar.itermonthdates() method is defined as follows:
"Return an iterator for one month. The iterator will yield datetime.date values
and will always iterate through complete weeks, so it will yield dates outside
the specified month."
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
superseder: -> Make Calendar.itermonthdates() behave consistently in edge cases
___
Python tracker
<http://bugs.python
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> Make Calendar.itermonthdates() behave consistently in edge cases
___
Python tracker
<http://
Changes by Alexander Belopolsky :
--
dependencies: +calendar.prcal() output has a problem, calendar:
OverflowErrors for year == 1 and firstweekday > 0
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
The proposed interpretation of nonpositive years is not arbitrary, it is a
natural extension of the same formulas that we use for positive years. On the
other hand 1- limits are arbitrary. If we wanted to restrict calendars to
4-digit years we
Alexander Belopolsky added the comment:
I would like to take the #1 approach, and also implement an itermonthdays3()
generator that would be like itermonthdates(), but return 3-tuples (year,
month, day) instead of datetime.date objects.
The name "itermonthdays3" is subject to discu
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue28255>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Alexander Mohr:
I have a unittest which spawns several processes repeatedly. One of these
subprocesses uses botocore, which itself uses the above two methods through the
calls proxy_bypass and getproxies. It seems after re-spawning the methods a
few times the titled
Alexander Mohr added the comment:
interestingly I haven't been able to get this to crash in a separate test app.
There must be either timing related to some interaction with another module.
let me know how you guys would like to proceed. I can definitely reproduce it
consistently i
Changes by Alexander Belopolsky :
--
stage: needs patch -> patch review
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
priority: low -> normal
versions: +Python 3.7 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue5907>
___
___
Py
Changes by Alexander Belopolsky :
--
stage: -> patch review
versions: +Python 3.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue11698>
___
___
Py
Alexander Belopolsky added the comment:
I would like to revisit this for 3.7.
--
keywords: -needs review, patch
priority: low -> normal
resolution: rejected ->
stage: commit review -> needs patch
status: closed -> open
versions: +Python 3.7
Alexander Mohr added the comment:
ya I did a monkey patch which resolved it.
if sys.platform == 'darwin':
import botocore.vendored.requests.utils, urllib.request
botocore.vendored.requests.utils.proxy_bypass =
urllib.request.proxy_bypass_e
Changes by Alexander Belopolsky :
--
nosy: +skip.montanaro
versions: +Python 3.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue2897>
___
___
Pytho
Alexander Belopolsky added the comment:
I am attaching a patch that implements steps 1 and 2 of Martin's plan. There
are over 50 files that include structmember.h. I am not sure it is worth the
trouble to update all those files before structmember.h is actually removed.
If we agree
Alexander Belopolsky added the comment:
I would also like this opportunity to rename T_PYSSIZET to something more
readable: maybe PY_T_PY_SSIZE_T or PY_T_SSIZE_T.
--
___
Python tracker
<http://bugs.python.org/issue2
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> include structmember.h in Python.h
___
Python tracker
<http://bugs.python
Alexander Belopolsky added the comment:
Serhiy, while I see that you've raised some additional issues here, let's keep
the discussion related to Include/structmember.h in one place. I would not
mind adding additional affected versions there.
--
nosy: +
Alexander Belopolsky added the comment:
As explained in #24065, READ_RESTRICTED, PY_WRITE_RESTRICTED and RESTRICTED
flags were used for "restricted mode" in Python 2. I don't think we would want
to preserve these as we move the r
Alexander Belopolsky added the comment:
There is also #24065 ("Outdated *_RESTRICTED flags in structmember.h") which I
think should be folded into #2897.
--
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
See #2897 for a plan to deperecate Include/structmember.h.
--
nosy: +belopolsky
resolution: -> duplicate
status: open -> closed
superseder: -> include structmember.h in Python.h
___
Python track
Changes by Alexander Belopolsky :
--
dependencies: +Issues with PyMemberDef flags, Outdated *_RESTRICTED flags in
structmember.h
___
Python tracker
<http://bugs.python.org/issue2
Alexander Belopolsky added the comment:
Changed the title to reflect the way forward and added affected versions to
remember to update the documentation. See #28349 and #24065 for details.
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
title: incl
Alexander Mohr added the comment:
I'm sure it would work, I just wanted a solution that didn't changes to our
build infrastructure. btw if we're marking this as a duplicate of the other
bug, can we update the other bug to say it affects python3.x as well? Thanks!
--
Alexander Belopolsky added the comment:
I am attaching a proposed doc patch for Python 3.5+. For 2.7 we should
probably just add a versionchanged note explaining "restricted mode" has been
deprecated in Python 2.3.
--
Added file: http://bugs.python.org/file44976/issu
Alexander Belopolsky added the comment:
This makes sense. Note that this is the way hashes are implemented for the
datetime objects:
<https://hg.python.org/cpython/file/v3.6.0b1/Lib/datetime.py#l635>.
--
nosy: +belopolsky
___
Python tracker
Alexander Belopolsky added the comment:
None is passed to tzinfo.dst() when it is called from time.dst() method. This
is documented in the relevant section:
<https://docs.python.org/3.5/library/datetime.html#datetime.time.dst>.
I am not sure whether if it is worth repeating in the ab
Changes by Alexander Belopolsky :
--
assignee: docs@python -> belopolsky
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/
New submission from Alexander Belchenko:
Running shutil.make_archive('a', 'zip', 'subdir') is created wrong and not
really needed entry "./" which is visible in zipfile.ZipFile.namelist():
['./', 'foo/', 'hello.txt', '
Alexander Belopolsky added the comment:
The patch should include an update to documentation.
1. We should probably explain that python -mcalendar does not reproduce the
output of UNIX cal. For example, on Mac OS (and various Linux variants):
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr
Alexander Belopolsky added the comment:
Shouldn't "time part" underlined in my previous note be "date part" instead?
Also, does non-zero mean non-empty?
--
___
Python tracker
<http://
Alexander Belopolsky added the comment:
Never mind the second question.
--
___
Python tracker
<http://bugs.python.org/issue1100942>
___
___
Python-bugs-list mailin
New submission from Alexander P:
For example, Jython 2.7. When we try to execute `jython-standalone -m pip`,
distutils.sysconfig tries to parse sys.executable as a path and obviously fails:
Traceback (most recent call last):
File "/home/ale/dev/3toj/jython-standalone-2.7.0.ja
Alexander P added the comment:
Well, project_base (which is what sys.executable is used for) is used only
during build (i. e. python_build is True), if I understand it correctly.
Normally, sys.prefix and sys.exec_prefix are used for all the paths.
Also, project_base can be explicitly set
Alexander Belopolsky added the comment:
See Datetime-SIG thread
<https://mail.python.org/pipermail/datetime-sig/2016-November/001010.html>.
--
assignee: -> belopolsky
nosy: +tim.peters
stage: -> needs patch
___
Python tr
Alexander Belopolsky added the comment:
I don't think timezones that satisfy the invariant expected by the default
fromutc() is common enough that we need to provide special support for them.
Note that in most cases it is the UTC to local conversion that is
straightforward while Loc
Alexander Belopolsky added the comment:
Paul G at Github:
"""
To be clear, I'm just saying that fromutc() goes from returning something
meaningful (the correct date and time, with no indication of what side of the
fold it's on) to something useless (an incorrect d
Alexander Belopolsky added the comment:
> I can't think of a single actual downside to this change - all it does is
> preserve the original behavior of `fromutc()`.
You've got me on the fence here. If what you are saying is correct, it would
make sense to make this change
New submission from Alexander Belopolsky:
See also #27595.
--
assignee: belopolsky
components: Documentation
messages: 280320
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Describe PEP 495 features in "What
Alexander Belopolsky added the comment:
Paul (p-ganssle), based on your recent experience implementing PEP 495, what
are the main points that we should cover in What's New? Also, any
comments/criticism on the recent changes to the datetime module documentation
are we
Alexander Belopolsky added the comment:
I spotted a small typo in the "PEP 495: Local Time Disambiguation" section:
"The values of the fold attribute have the value 0 all instances ..." should be
"The values of the fold attribute have the value 0 *for* all instan
Alexander Belopolsky added the comment:
> On Nov 18, 2016, at 7:04 AM, Serhiy Storchaka wrote:
>
> Yet one doubtful detail is that the fold bit is added to the hour bit in
> datetime.time, but to the month field in datetime.datetime.
The reason behind this choice is documente
Alexander Belopolsky added the comment:
> On Nov 18, 2016, at 8:49 AM, Serhiy Storchaka wrote:
>
> But there are two drawbacks.
It is not too late to make improvements. If you have specific proposals -
please bring them up on the mai
Alexander Belopolsky added the comment:
Keeping localtime as a convenience function in email.util is fine, but isdst
argument should be eliminated at some point. There is a fundamental problem
with disambiguating fold times with isdst: some folds do not involve the change
in dst or happen in
Alexander Belopolsky added the comment:
> On Nov 20, 2016, at 11:10 AM, Serhiy Storchaka wrote:
>
> Other way is to define __reduce_ex__ instead of __reduce__ in datetime.date.
I would prefer this solution.
--
___
Python track
Alexander Belopolsky added the comment:
> On Nov 20, 2016, at 12:34 PM, Serhiy Storchaka wrote:
>
> The only way is to define both __reduce_ex__ and __reduce__ for time and
> datewtime.
OK. I'll review your patch and get it
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue28752>
___
__
Alexander Belopolsky added the comment:
The patch LGTM. I'll commit it tonight unless Serhiy beats me to it.
--
nosy: +alexandre.vassalotti, haypo, tim.peters
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
> If you can push this in the next hour or two ...
I'll do it now.
--
___
Python tracker
<http://bugs.python.org
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
It looks like Serhiy has already committed it. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue28752>
___
___
New submission from Alexander Tobias Heinrich:
First of all, I am not sure, if this is a bug in python itself - it could as
well be a bug in the py-dom-xpath module
(http://code.google.com/p/py-dom-xpath) or not a bug at all (but I find the
latter to be highly unlikely).
Consider an XML
Alexander L. Belikoff added the comment:
Same problem for Python 3.2.3. Log file for failed installation attached.
--
nosy: +abelikoff
versions: +Python 3.2 -Python 2.7
Added file: http://bugs.python.org/file27318/python.zip
___
Python tracker
<h
4001 - 4097 of 4097 matches
Mail list logo
