Changes by Alexander Belopolsky :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7229>
___
___
Pyth
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue10552>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
nosy: +hynek, ned.deily, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue10552>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue9267>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue15711>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
nosy: +amaury.forgeotdarc, meador.inge
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15884>
___
___
Python-bugs-list mailin
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
Changes by Alexander Belopolsky :
--
dependencies: +Don't use east/west of UTC in date/time documentation
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
This seems to be touching the same areas as #9305.
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue9034>
___
___
Python-bugs-list mailing list
Un
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
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
Changes by Alexander Belopolsky :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15870>
___
___
Pyth
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue9769>
___
___
Py
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
Changes by Alexander Belopolsky :
--
assignee: -> ronaldoussoren
components: +Macintosh
___
Python tracker
<http://bugs.python.org/issue9256>
___
___
Python-
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: +Python 3.5 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue5288>
___
___
Py
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
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
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
Changes by Alexander Belopolsky :
--
status: open -> closed
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue5207>
___
___
Py
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue1170>
___
___
Python-
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
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
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17769/issue9051-utc-pickle-proto.diff
___
Python tracker
<http://bugs.python.org/issue9
Changes by Alexander Belopolsky :
--
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue9051>
___
___
Python-bugs-list mailin
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.
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
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
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
Changes by Alexander Belopolsky :
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue15787>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
Changes by Alexander Belopolsky :
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15849>
___
___
Python-bugs-list mailin
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
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
Changes by Alexander Belopolsky :
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue21966>
___
___
Python-bugs-list mailing list
Unsub
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'
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;
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
Alexander Belopolsky added the comment:
Committed. Thanks, Anton.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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
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.
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
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
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
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
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
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
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
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
Changes by Alexander Belopolsky :
--
nosy: +alexandre.vassalotti, pitrou
___
Python tracker
<http://bugs.python.org/issue22005>
___
___
Python-bugs-list mailin
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]
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
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
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
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
As David explained, utcoffset() method signature is dictated by the base class.
This is not a bug.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python track
Alexander Belopolsky added the comment:
This is a duplicate of #15873.
--
components: +Extension Modules
resolution: -> duplicate
status: open -> closed
superseder: -> datetime: add ability to parse RFC 3339 dates and times
type: behavior -> enhancement
versions:
Alexander Belopolsky added the comment:
I see. I thought you were complaining about "%z" format not supporting "00:00"
as in
>>> from datetime import *
>>> datetime.strptime("00:00","%z")
Traceback (most recent call last):
..
Val
Alexander Belopolsky added the comment:
See also <http://bugs.python.org/issue5094#msg106476>.
It looks like providing 'UTC' as the name of utc singleton was part of my
original proposal. I have no recollection on why it was not implemented that
way.
--
nos
Alexander Belopolsky added the comment:
Akira,
I see that you participated in the original discussion (msg107608). We settled
on str(timezone.utc) == 'UTC+00:00' and this was clearly a deliberate choice.
I don't think we can revisit this now, but we can probably make strptim
Alexander Belopolsky added the comment:
There is no daylight savings time in Moscow and python detects this correctly:
$ TZ=Europe/Moscow python3
>>> import time
>>> time.daylight
0
Note that historically, there was DST, but time module cannot handle historical
TZ
Alexander Belopolsky added the comment:
I don't think there is anything we can do here. Without a TZ database, Python
has to rely on time.tzname which in case of TZ=Europe/Moscow returns
>>> time.tzname
('MSK', 'MSK')
Hardcoding a timezones dictionary as d
Alexander Belopolsky added the comment:
On the second thought, we can probably make the same guesswork as in
PyInit_timezone (see Modules/timemodule.c) in time.strptime, but not for the
current time, but for the time parsed.
--
___
Python tracker
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue22426>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
stage: -> needs patch
type: behavior -> enhancement
versions: -Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/i
New submission from Alexander Belopolsky:
PEP 3141 defines floor division as floor(x/y) and specifies that floor() should
return int type. Builtin float type has been made part of the PEP 3141
numerical tower, but floor division of two floats still results in a float.
See also:
* #1656
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22445>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22385>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
> Is this change compelling enough to break compatibility,
> or is it just a matter of purity?
According to the PEP 3141, Integer is a subtype of Real, so one should be able
to substitute an Integer whenever Real is expected. The reverse is no
Alexander Belopolsky added the comment:
> However, Scheme returns floats
Does Scheme's default integer type support arbitrarily large values?
--
___
Python tracker
<http://bugs.python.org
Alexander Belopolsky added the comment:
> Perhaps it's worth mentioning that several people on Python-ideas
> took the opposite view: math.floor() should return a float.
I sympathize with the idea that math module functions should return floats. I
find it unfortunate that
Alexander Belopolsky added the comment:
> What should Decimal('1e123456')//1 return?
I think Decimal case should be considered separately. Note that unlike float,
they are not part of the numerical tower, so PEP 3141 arguments don't apply:
>>> isinsta
Alexander Belopolsky added the comment:
I find this footnote somewhat confusing:
"""
(8) Similar to %U and %W, %V is only used in calculations when the day of the
week and the ISO year (%G) are specified when used with the strptime method.
"""
The existin
Alexander Belopolsky added the comment:
How was "%Y %V" issue resolved? I don't see any tests for this case.
--
___
Python tracker
<http://bugs.pyt
Alexander Belopolsky added the comment:
[Raymond]
> The current behavior has been around for a long time and is implemented in
> several modules including decimal and fractions.
No, in the fractions module floor division returns an int:
>>> type(Fraction(2) // Fraction(1
Alexander Belopolsky added the comment:
[Raymond]
> The PEP should be revised to say that floor division is defined to
> return a value that is *equal* to an Integral but not place any
> restriction on the return type.
If we take this route, what float('inf') // 1 and float
Alexander Belopolsky added the comment:
Mark,
Raymond suggested that "The PEP 3141 should be revised to say that floor
division is defined to return a value that is *equal* to an Integral".
Since nan or inf are not *equal* to any Integral, the current implementation
does not compl
Alexander Belopolsky added the comment:
skrah> I think both should return inf.
What about this case:
>>> Decimal('1') // Decimal('-inf')
Decimal('-0')
>>> 1. // float('-inf')
-1.0
--
_
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I wonder if it would make sense to rewrite float_divmod using the newer
POSIX/C99 remquo function. I believe it is designed to compute the exact value
of round(x/y), but getting floor instead should not be hard. Its behavior on
special values is fully
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
___
Python tracker
<http://bugs.python.org/issue9104>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
For future reference, here is the example showing %Y %V ambiguity:
>>> date(2013,12,31).strftime('%Y %V %u')
'2013 01 2'
>>> date(2013,1,1).strftime('%Y %V %u')
'2013 01 2'
which is resolved by us
Alexander Belopolsky added the comment:
I think we need more tests showing that new directives don't violate strftime -
strptime round-trip invariants.
--
title: strptime should implement %V or %u directive from libc -> strptime
should implement %G, %V and %u di
Changes by Alexander Belopolsky :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5979>
___
___
Pyth
Alexander Belopolsky added the comment:
Documentation should say "new in 3.5".
--
___
Python tracker
<http://bugs.python.org/issue12006>
___
___
Python-b
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22194>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I don't think fficonfig.py.in is from upstream.
--
___
Python tracker
<http://bugs.python.org/issue17873>
___
___
Alexander Belopolsky added the comment:
The issue was not fixed. With multiple invisible space characters I can get
Python 3.5.0a0 (default:5313b4c0bb6c, Sep 30 2014, 18:55:45)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.51)] on darwin
>>> invalid = None
File "",
Alexander Belopolsky added the comment:
The original problem is still present
Python 3.5.0a0 (default:5313b4c0bb6c, Sep 30 2014, 18:55:45)
>>> A_I_U_E_O$ = None
File "", line 1
A_I_U_E_O$ = None
^
SyntaxError: invalid syntax
Replace A_I_U_E_O above with the
Alexander Belopolsky added the comment:
Leon,
Are you trying to run compiled python binary before it was installed? If so,
this is expected and not specific to clang or libffi.
If your issue is something else - please explain how to reproduce it and post
the error messages that you see
Alexander Belopolsky added the comment:
Josh,
Would issue7830.diff solve your use-case as is? See msg108980 for the
limitations. If so, I don't mind reopening this issue.
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
I would say that getting "maximum recursion depth exceeded" error from
evaluating a deeply nested partial is a bug, but I am not sure we should fix it
by flattening partial objects in the constructor or by being smarter at
evalu
Alexander Belopolsky added the comment:
I've updated the patch.
--
keywords: +patch
Added file: http://bugs.python.org/file36837/issue7830-2.diff
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
I am going to reject this. Assert failures should never be seen by users and
for a developer "assert 1 <= month <= 12" is as clear as "month must be in
1..12."
--
nosy: +belopolsky
resolution: -> wont fix
stage:
Alexander Belopolsky added the comment:
@terry - datetime.py was originally written as a prototype for the C code and
many seemingly unpythonic constructs therein are motivated by the desire to
ease the translation to C.
I would not mind simplifying _DI4Y calculation as you suggest, but
2101 - 2200 of 3596 matches
Mail list logo
