Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file19559/turtle-sidebar-screenshot.png
___
Python tracker
<http://bugs.python.org/issue7061>
___
___
Alexander Belopolsky added the comment:
As a follow-up to Raymond's suggestion, I am attaching a patch that will add a
sidebar to the introduction section of the turtle documentation section. While
it is not common to include screenshots in python documentation, I think it is
Alexander Belopolsky added the comment:
On Sat, Oct 30, 2010 at 8:27 PM, Terry J. Reedy wrote:
..
> Sections about 2.x changes should not be in 3.x docs.
I agree. Neither "Changes since Python 2.6" nor "Changes since Python 2.6"
belong in this section. The first be
Alexander Belopolsky added the comment:
I would like to add my +1 to Eric's msg120485 above. What I really find
puzzling is why some scripts in Tools/ have hashbangs, but don't have execute
permission.
Tools/scripts/cleanfuture.py
Tools/scripts/combinerefs.py
Tools/scripts/db
Alexander Belopolsky added the comment:
On Tue, Nov 9, 2010 at 11:45 AM, Raymond Hettinger
wrote:
..
> Raymond Hettinger added the comment:
>
> The mini change log is harmless. I would leave it as is.
It is not entirely harmless. First, it occupies valuable easy to
scroll to en
Changes by Alexander Belopolsky :
--
nosy: +brett.cannon, eli.bendersky, terry.reedy
___
Python tracker
<http://bugs.python.org/issue10371>
___
___
Python-bug
Alexander Belopolsky added the comment:
Committed a slightly modified turtle-star-sidebar.diff in revision 86364. Note
that I've included both pdf and postscript files in case someone would want to
run postscript through a better distiller than the OSX preview that I used.
The posts
New submission from Alexander Belopolsky :
I was going to commit this patch, but decided to ask for a second opinion. I
think module names in section titles should be marked up with :mod:.
--
assignee: belopolsky
components: Documentation
files: subprocess-doc.diff
keywords: patch
Alexander Belopolsky added the comment:
I am attaching a patch that seems to fix the issue. Note that I considered
fixing the problem in parsetok.c where offset is originally computed, but this
is part of pgen which has to be compiled without unicode support.
The test case suitable to be
New submission from Alexander Belopolsky :
>>> ¡™£¢∞§¶•ªº
File "", line 1
¡™£¢∞§¶•ªº
^
SyntaxError: invalid character in identifier
It looks like strlen() is used instead of number of characters in the decoded
string.
--
component
Changes by Alexander Belopolsky :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10382>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
dependencies: +Command line error marker misplaced on unicode entry
___
Python tracker
<http://bugs.python.org/issue10
Changes by Alexander Belopolsky :
--
nosy: +ezio.melotti, haypo, lemburg
___
Python tracker
<http://bugs.python.org/issue10382>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
On Sun, Oct 31, 2010 at 8:00 PM, Éric Araujo wrote:
..
> “Python” is lower-cased only when referring to the executable (as a
> file) itself. When talking about the language, the implementation or
> the VM in an abstract way (not a file), It t
New submission from Alexander Belopolsky :
The token module appears to be designed to be used with import *. In fact it
is used this way in the tokenize module. However it does not define __all__
and as a result, from token import * leaks symbol "main":
>>> import tokeniz
New submission from Alexander Belopolsky :
With timezone class added to datetime module, C API should be extended to at
the minimum support efficient creation of timezone instances and access to the
singleton UTC instance.
I am not sure whether PyDateTime_TimeZone details should be exposed in
New submission from Alexander Belopolsky :
Can you see the error in the following?
>>> invalid = 5
File "", line 1
invalid = 5
^
SyntaxError: invalid character in identifier
The problem is that an invisible space character crept into the identifier:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue7434>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Committed revision 86410.
--
___
Python tracker
<http://bugs.python.org/issue10386>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10386>
___
___
Python-bugs-list mailing list
Un
New submission from Alexander Belopolsky :
Following a brief and consensual discussion on d...@python and #python-dev, I
am proposing attached patch for the Python documentation style guide.
--
assignee: belopolsky
components: Documentation
files: style-guide.diff
keywords: patch
Alexander Belopolsky added the comment:
The new patch, issue10389.diff, addresses Éric's comments and adds an entry for
"reST".
--
Added file: http://bugs.python.org/file19571/issue10389.diff
___
Python tracker
<http://bugs.pyt
Alexander Belopolsky added the comment:
Committed in revision 86417.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10389>
___
_
Alexander Belopolsky added the comment:
haypo> See also #2382: I wrote patches two years ago for this issue.
Yes, this is the same issue. I don't want to close this as a duplicate because
#2382 contains a much more ambitious set of patches. What I am trying to
achieve here is si
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file19573/issue10382a.diff
___
Python tracker
<http://bugs.python.org/issue10382>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Fri, Nov 12, 2010 at 12:54 PM, Terry J. Reedy wrote:
..
>>What is the best way to pass around source code?
>> - file-like objects, line iterators, readline-like function?
>
> Line iterator (list of lines) as returned by open().r
Alexander Belopolsky added the comment:
On Fri, Nov 12, 2010 at 2:09 PM, Terry J. Reedy wrote:
..
> 1. Does the markup make any visual difference?
It does on my browser. (I wouldn't have noticed it otherwise.) See
http://docs.python.org/dev/contents.html
> 2. Does the markup
New submission from Alexander Belopolsky :
Attached patch updates some comments in unicode.h mostly reflecting the fact
that the default encoding is now unconditionally UTF-8.
--
assignee: belopolsky
components: Documentation, Interpreter Core
files: unicode-comments.diff
keywords
Alexander Belopolsky added the comment:
+1
Note that in Python, semi-open intervals are favored, but specifying the last
hour of the day is awkward when using datetime (as OP mentioned) and impossible
using just time. Using closed intervals is not a good work-around in many
cases because
Alexander Belopolsky added the comment:
Committed in revision 86478. Should this go in 3.1? This is a comments-only
change, so it is fairly safe and merging may help future maintenance. On the
other hand, it is very unlikely that the header file will need to be changed in
maintenance
New submission from Alexander Belopolsky :
As discussed in "Breaking undocumented API" thread [1] on python-dev, a
definition of "public names" is buried deep in the language reference manual:
"""
The public names defined by a module are determined by ch
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue10433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
assignee: -> d...@python
components: +Documentation, Macintosh
nosy: +d...@python
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
Michael Foord suggested adding the following to developer documentation such as
PEP 8. [1] I am not sure PEP 8 is the right place for it. In my opinion, PEP 8
is mostly about stylistic choices that don't have a major impact on the users.
In
Alexander Belopolsky added the comment:
Committed to 3.1 branch in revision 86481.
--
status: pending -> closed
type: -> behavior
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/i
New submission from Alexander Belopolsky :
The following C-APIs are only documented in comments inside unicode.h:
PyUnicode_GetMax
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_FromOrdinal
PyUnicode_GetDefaultEncoding
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
Alexander Belopolsky added the comment:
There are more undocumented functions in unicode.h. It makes sense to fix all
of them in one patch. Closing this as superseded by #10435.
--
nosy: +belopolsky
resolution: -> duplicate
status: open -> closed
superseder: -> Document
Changes by Alexander Belopolsky :
--
components: +Interpreter Core
stage: -> needs patch
versions: +Python 3.3 -Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
> Alexander Belopolsky wrote:
..
>> I also have a similar question about C API. Here, in absence of
>> __all__, the answer should be clear: all symbols in public header
>> fi
Changes by Alexander Belopolsky :
--
nosy: +haypo, lemburg, loewis
___
Python tracker
<http://bugs.python.org/issue10435>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
PyUnicode_AsDecodedObject() and PyUnicode_AsDecodedUnicode() appear to be
broken as well: both start with a PyUnicode_Check(unicode) and then pass
unicode to PyCodec_Decode() which expects bytes
Alexander Belopolsky added the comment:
On Tue, Nov 16, 2010 at 5:54 PM, Marc-Andre Lemburg
wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Please note that PyCodec_Encode()/PyCodec_Decode() will return whatever the
> codec returns for these operations.
>
> Th
Alexander Belopolsky added the comment:
Attached patch documents all previously undocumented unicode C API functions.
Note that for the PyUnicode_As{En,De}codedObject() and
PyUnicode_As{En,De}DecodedUnicode() functions I attempted to capture what they
are supposed to do rather than what the
New submission from Alexander Belopolsky :
Python Codec Registry and support functions are well documented in codecs.h
header file. It should be easy to convert that to reST.
--
assignee: d...@python
components: Documentation
keywords: easy
messages: 121329
nosy: belopolsky, d
Alexander Belopolsky added the comment:
On Tue, Nov 16, 2010 at 7:19 PM, Marc-Andre Lemburg
wrote:
..
>> * Decoding converts a bytes object encoded using a particular
>> character set encoding to a string object.
>> """
>> http://docs.python.org/d
Alexander Belopolsky added the comment:
> I agree and will handle this in #10435 because codecs.h
s/#10435/#10439/
--
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
It looks like I misunderstood what PyUnicode_As{En,De}codedObject() and
PyUnicode_As{En,De}codedUnicode() functions are designed to do. Attaching a
corrected patch, issue10435a.diff.
--
Added file: http://bugs.python.org/file19622
New submission from Alexander Belopolsky :
$ pydoc3.1 pydoc
Help on module pydoc:
NAME
pydoc - Generate Python documentation in HTML or text for interactive use.
FILE
/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pydoc.py
MODULE DOCS
http
Changes by Alexander Belopolsky :
--
nosy: +d...@python
___
Python tracker
<http://bugs.python.org/issue10446>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue11286>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I am not sure PyUnicode_Decode() should treat NULL as an empty string.
Decoding empty string is wasteful and if the caller knows that the string is
empty, it should skip decoding because the result is empty. Providing *two*
ways to invoke expensive
Alexander Belopolsky added the comment:
Antoine is right, my patch is only of "discussion" quality and if my approach
gets support, I will produce a more polished patch.
While I am fairly certain that this bug should be fixed where it was
introduced, namely in the _pickle module
Alexander Belopolsky added the comment:
On Wed, Feb 23, 2011 at 10:22 AM, Antoine Pitrou wrote:
..
> Well, a theoretical argument could be made that some codec could return
> a non-empty string when asked to decode an empty bytestring, but I'm not
> sure it has much practical w
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue11286>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
I am attaching a new version of issue11286.diff which fixes the issue by
removing special handling of n == 0 case from _Unpickler_Read(). Note that
_Unpickler_Read() (formerly known as unpickler_read()) only started to return
null pointer instead of a
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file20856/issue11286.diff
___
Python tracker
<http://bugs.python.org/issue11286>
___
___
Python-bug
New submission from Alexander Belopolsky :
$ ./python.exe -m timeit "b'x'.decode('latin1')"
10 loops, best of 3: 2.57 usec per loop
$ ./python.exe -m timeit "b'x'.decode('latin-1')"
100 loops, best of 3: 0.336 usec per l
Alexander Belopolsky added the comment:
In issue11303.diff, I add similar optimization for encode('latin1') and for
'utf8' variant of utf-8. I don't think dash-less variants of utf-16 and utf-32
are common enough to justify special-casing.
--
Added fil
Alexander Belopolsky added the comment:
What is the status of this. Status=open and Resolution=rejected contradict
each other.
This discussion is relevant for issue11303. Currently alias lookup incurs huge
performance penalty in some cases.
--
nosy: +belopolsky
Alexander Belopolsky added the comment:
> Accepting all common forms for
> encoding names means that you can usually give Python an encoding name
> from, e.g. a HTML page, or any other file or system that specifies an
> encoding.
I don't buy this argument. Running attache
Alexander Belopolsky added the comment:
Ezio and I discussed on IRC the implementation of alias lookup and neither of
us was able to point out to the function that strips non-alphanumeric
characters from encoding names.
It turns out that there are three "normalize" function
Alexander Belopolsky added the comment:
On Thu, Feb 24, 2011 at 10:30 AM, Ezio Melotti wrote:
..
> See also discussion on #5902.
Mark has closed #5902 and indeed the discussion of how to efficiently
normalize encoding names (without changing what is accepted) is beyond
the scope of that
Alexander Belopolsky added the comment:
On Thu, Feb 24, 2011 at 11:01 AM, Marc-Andre Lemburg
wrote:
..
> On this ticker, we're discussing just one application area: that
> of the builtin short cuts.
>
Fair enough. I was hoping to close this ticket by simply committing
the posted
Alexander Belopolsky added the comment:
On Thu, Feb 24, 2011 at 11:31 AM, Marc-Andre Lemburg
wrote:
..
> I think rather than removing any hyphens, spaces, etc. the
> function should additionally:
>
> * add hyphens whenever (they are missing and) there's switch
> from [a
Alexander Belopolsky added the comment:
On Thu, Feb 24, 2011 at 11:39 AM, Marc-Andre Lemburg
wrote:
>
> Marc-Andre Lemburg added the comment:
..
> That won't work, Victor, since it makes invalid encoding
> names valid, e.g. 'utf(=)-8'.
>
.. but this *is* valid:
Alexander Belopolsky added the comment:
>>> 'abc'.encode('utf(=)-8')
b'abc'
--
___
Python tracker
<http://bugs.python.org/issue11303>
___
___
Alexander Belopolsky added the comment:
Committed in r88546 (3.3) and r88548 (3.2).
Note that a simple work-around before 3.2.1 is to spell encoding as 'latin-1'
or 'iso-8859-1' in pickle.loads().
--
components: +Extension Modules -Library (Lib)
resolution: -&
Alexander Belopolsky added the comment:
On Thu, Feb 24, 2011 at 3:54 PM, Antoine Pitrou wrote:
..
> I've committed the part of the patch which disallows a NULL data pointer
> with PyMemoryView_FromBuffer in r88550 and r88551.
Is it possible to create such buffer in Python (ot
Alexander Belopolsky added the comment:
+char lower[strlen(encoding)*2];
Is this valid in C-89?
--
___
Python tracker
<http://bugs.python.org/issue11
Alexander Belopolsky added the comment:
It seems appropriate to consult python-dev on this. I thought
ValueError was for values that are valid Python objects but out of
acceptable range of the function. Errors that can only be triggered
in C code normally handled with either assert() or raise
New submission from Alexander Belopolsky :
In Python 3.x default encoding is always utf-8, but encode()/decode() still try
to look it up. Attached patch eliminates a call to normalize_encoding and
several strcmp() calls.
--
files: default-encode.diff
keywords: patch
messages: 129318
Alexander Belopolsky added the comment:
Thanks for the review and the tests. I have found one more place that can be
easily optimized. (See patch below.) The decode() methods in bytes and
bytearray are not so easy unfortunately because for some reason they are
written to accept any object
Alexander Belopolsky added the comment:
Committed issue11313.diff in revision 88553.
On the second thought, the getargs optimization is not worth the trouble
because in existing sources 'e' code is used with constant encodings and one is
unlikely to pass NULL as an encoding becau
Alexander Belopolsky added the comment:
I don't think the normalize_encoding() function was the culprit for issue11303
because I measured timings with timeit which averages multiple runs while
normalize_encoding() is called only the one time per encoding spelling due to
ca
Alexander Belopolsky added the comment:
Committed issue11303.diff and doc change in revision 88602.
I think the remaining ideas are best addressed in issue11322.
> Given that we are starting to have a whole set of such aliases
> in the C code, I wonder whether it would be better to ma
Alexander Belopolsky added the comment:
On Fri, Feb 25, 2011 at 8:29 PM, Antoine Pitrou wrote:
..
>> For other spellings like "utf8" or "latin1", I wonder if it would be
>> useful to emit a warning/suggestion to use the standard spelling.
>
> No, it woul
Alexander Belopolsky added the comment:
On Fri, Feb 25, 2011 at 8:39 PM, Ezio Melotti wrote:
..
> It would prefer to see the note added by Alexander in the doc mention *only*
> the preferred spellings
> (i.e. 'utf-8' and 'iso-8859-1') rather than all the
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
resolution: fixed ->
type: -> feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue9769>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
On Wed, Mar 9, 2011 at 2:32 AM, Scott Dial wrote:
..
> By rejecting unittests on the merits of its coding style, you are creating a
> double-standard for people like
> me (outside of the core committers), which eventually wears out my inter
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
See also issue10812 which implements os.futimens().
--
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Alexander Belopolsky added the comment:
Eugene, how does your optimization differ from the one proposed in issue2493?
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue11
Alexander Belopolsky added the comment:
> It appears this is an invalid unicode character.
> Shouldn't this be caught by decode("utf8")
It should and it is in Python 3.x:
>>> b'\xed\xa8\x80'.decode("utf8")
Traceback (most recent call last)
Alexander Belopolsky added the comment:
On Tue, Mar 15, 2011 at 7:05 PM, Antoine Pitrou wrote:
..
> - (bugfix) raise a proper exception when an object too large for handling by
> pickle is given
What would be the "proper exception" here? With _pickle acceleration
d
Alexander Belopolsky added the comment:
On Wed, Mar 16, 2011 at 10:18 AM, Ronald Oussoren
wrote:
..
> This is not a bug in python, but is generic platform behavior (as Ned noted).
Maybe not a bug in tkinter proper, but certainly an unexpected
behavior when running tkinter demo scripts or
New submission from Alexander Belopolsky :
If you have a large enough terminal window and run
$ python -m turtle
on OSX, you will see nothing because turtle screen pops under the terminal.
Ned Deily suggested in msg130421 that this can be fixed by setting "-topmost"
WM attribute o
Changes by Alexander Belopolsky :
--
dependencies: +Tkinter windows pop under the terminal in OSX
___
Python tracker
<http://bugs.python.org/issue11571>
___
___
Changes by Alexander Belopolsky :
--
superseder: -> Turtle window pops under the terminal on OSX
___
Python tracker
<http://bugs.python.org/issue9384>
___
_
Alexander Belopolsky added the comment:
On Wed, Mar 16, 2011 at 10:42 AM, Ronald Oussoren
wrote:
> It is definitely something that will have to be determined for every case
>separately
> and is not something that should be worked around in Tkinter itself.
I agree, but I don'
Alexander Belopolsky added the comment:
On Wed, Mar 16, 2011 at 11:26 AM, Ronald Oussoren
wrote:
..
> The attached patch forces the window to the front by first making the window
> a topmost window and then resetting that flag.
>
> Could you test if this does want you'd like
Alexander Belopolsky added the comment:
> A bug in "coverage" results in its only reporting 99% at the moment
It was concluded during discussion of issue2506 that this is not a bug. At
least not a bug in "coverage" or the trace module. At most this is a peephole
Alexander Belopolsky added the comment:
On Wed, Mar 16, 2011 at 6:59 PM, Antoine Pitrou wrote:
..
>>
>> What would be the "proper exception" here?
>
> OverflowError. This is the exception that gets raised when some
> user-supplied value exceeds some in
Alexander Belopolsky added the comment:
On Thu, Mar 17, 2011 at 8:03 PM, Antoine Pitrou wrote:
..
> +1 for not having pragma statements in the stdlib, especially when they
> target a third-party tool few of us know and use.
"#pragma NO COVER" is recognized by stdlib trace
Alexander Belopolsky added the comment:
On Tue, Mar 22, 2011 at 2:55 PM, Éric Araujo wrote:
..
> Agreed. Which .py files would be appropriate?
Lib/turtledemo/about_turtle.txt - seems to belong to turtle.py
Lib/turtledemo/about_turtledemo.txt -> turtledemo/__init__.py
and Lib/turt
Alexander Belopolsky added the comment:
On Tue, Mar 22, 2011 at 3:14 PM, Alexander Belopolsky
wrote:
..
> Lib/turtledemo/about_turtle.txt - seems to belong to turtle.py
In fact, it looks like turtle docstring is already a copy (or almost a
copy) of Lib/turtledemo/about_turtle.txt. Inst
Changes by Alexander Belopolsky :
--
type: -> feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10291>
___
_
Changes by Alexander Belopolsky :
--
keywords: +patch
Added file: http://bugs.python.org/file21340/issue10291.diff
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
On Tue, Mar 22, 2011 at 5:15 PM, Éric Araujo wrote:
>..
> The patch contains one unrelated code change.
>
Yes, I noticed that, but it may not be that unrelated. Of course the
two changes need to be committed separately, but the pop-un
Alexander Belopolsky added the comment:
On Tue, Mar 22, 2011 at 5:29 PM, Éric Araujo wrote:
..
>> I would rather keep code and documentation changes separate.
> I don’t follow; my comment about bad phrasing was about the text added to the
> docstrings.
The text added to docstring
301 - 400 of 3596 matches
Mail list logo
