Antoine Pitrou added the comment:
Small bikeshed on the name: I think 'unpack_iter' would be more
consistent with what is already there, e.g. 'unpack' and 'unpack_from'.
In fact, when experimenting with this patch I found myself typing
'unpack_iter' several times.
I thought so, but
Roundup Robot added the comment:
New changeset 2ddfa8dbed1d by Ezio Melotti in branch '2.7':
#17729: remove the outdated Advocacy HOWTO, as suggested by the author.
http://hg.python.org/cpython/rev/2ddfa8dbed1d
New changeset a4804e0d4479 by Ezio Melotti in branch '3.3':
#17729: remove the
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
assignee: docs@python - ezio.melotti
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - enhancement
___
Python tracker rep...@bugs.python.org
Tshepang Lekhonkhobe added the comment:
the index file also needed changing; see attached
--
Added file: http://bugs.python.org/file29987/diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17729
Roundup Robot added the comment:
New changeset 990c1bd26ef1 by Ezio Melotti in branch '2.7':
#17729: remove the Advocacy HOWTO from the index.
http://hg.python.org/cpython/rev/990c1bd26ef1
New changeset a4d294539f2e by Ezio Melotti in branch '3.3':
#17729: remove the Advocacy HOWTO from the
Ezio Melotti added the comment:
Fixed, thanks for noticing that and for the patch!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17729
___
___
Mark Dickinson added the comment:
I don't see how math.isnan or math.isinf would be affected: we're not proposing
to make a float16 Python type, so math.isnan would never encounter a float16
value.
--
___
Python tracker rep...@bugs.python.org
paul j3 added the comment:
This nargs test using the formater applies only when the container has a help
formatter. That is true for a ArgumentParser, but not for an argument_group.
group = parser.add_argument_group('g')
group.add_argument('bar', nargs='test')
does not raise an error.
Ezio Melotti added the comment:
If things are fixed/added/improved on 3.x, there should be tests for them, and
if they are backported on 2.7, tests should be backported as well.
If mock makes testing easier, I think it would be acceptable to use it and then
have IDLE devs install a 2.7 mock
Changes by Serhiy Storchaka storch...@gmail.com:
--
dependencies: +IDLE console uses incorrect encoding.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14326
___
Serhiy Storchaka added the comment:
Here's a tangentially related issue: #14326
Yes, this issue looks as a prerequisite for it.
IDLE doesn't handle pasting multi-line code properly (issue3559), IDLE2 will
silently ignore code after the first executable statement. IDLE3 may give an
error.
Glenn Linderman added the comment:
Very nice, Paul.
I tested that with some of my applications, and some of my test cases. All of
them initially failed, because you have parse_intermixed_args returning
parameters like parse_known_args instead of like parse_args. Now I can
understand that
Ned Deily added the comment:
Thanks for the patch, Guilherme. While the patch does restore the Options menu
for Edit windows, a similar change is needed in idlelib/PyShell.py to also
restore the menu for the shell window. I will refresh the patch or include it
in the changes for Issue17654
Alexandre Vassalotti added the comment:
I think it should be fixed though it is not a high-priority issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16231
___
Nick Coghlan added the comment:
+1 for Ezio's suggestion regarding tests that need the mock module. To simplify
backporting you may want to do something like the following in a helper module:
try:
import unittest.mock as mock
except ImportError:
try:
import
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file29988/aifc_1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17818
___
Guilherme Simões added the comment:
I didn't restore the menu in the shell window because it would be empty then.
Perhaps a better alternative is to automatically remove any empty menu. That
way if someone inserted a new option in the menu in the future it would show
automatically in the
New submission from Philippe Rouquier:
Hi,
the following statement yields different results in python2 and python3:
284397269195572115652769428988866694680//17 -
int(284397269195572115652769428988866694680/17)
In python3 it yields:
309657313492949847071
In python2 it yields:
OL
Python2's
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17821
___
___
Richard Oudkerk added the comment:
In Python 3 / gives float division, whereas in Python 2 it is integer
division, the same as //.
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17821
Richard Oudkerk added the comment:
Just to clarify, if you use float division then you get rounding errors.
309657313492949847071 is a rounding error:
x = 284397269195572115652769428988866694680//17
x - int(float(x))
309657313492949847071L
--
Philippe Rouquier added the comment:
Does your comment mean that this is bug should be closed as notabug since
anyone wanting to avoid such rounding error should use // operator?
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
Attached a new patch that improves the following things:
* added some tests;
* the code in the previous message is now handled correctly;
* the patch now raises a proper SyntaxWarning;
There are still several problems though:
* it doesn't work for the global
Richard Oudkerk added the comment:
Yes.
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17821
___
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17353
___
Roundup Robot added the comment:
New changeset a389700fbc74 by Ronald Oussoren in branch '2.7':
Ensure that plistlib doesn't corrupt deeply nested datastructures
http://hg.python.org/cpython/rev/a389700fbc74
New changeset 6a8cb4875ac6 by Ronald Oussoren in branch '3.3':
Ensure that plistlib
Florent Xicluna added the comment:
Another rant, because it matters to many of us:
http://lucumr.pocoo.org/2012/8/11/codec-confusion/
IMHO, the solution to restore str.decode and bytes.encode and return TypeError
for improper use is probably the most obvious for the average user.
--
Ezio Melotti added the comment:
-1
I see encoding as the process to go from text to bytes, and decoding the
process to go from bytes to text, so (ab)using these terms for other kind of
conversions is not an option IMHO.
Anyway I think someone should write a PEP and list the possible options
Ronald Oussoren added the comment:
The attached patch start wish and stops it by sending the 'exit' command. With
the patch I can run the tk tests without getting a skip. I cannot easily test
if the patch also does the right thing on buildbots, but have high hopes. I
did check that just
Ronald Oussoren added the comment:
I've updated the patch: it now contains a testcase (although the getaddrinfo
tests are stretching the definition of the word, the new test only checks that
the function doesn't crash)
--
Added file:
R. David Murray added the comment:
transform/untransform has approval-in-principle, adding encode/decode to the
type that doesn't have them has been explicitly (and repeatedly :) rejected.
(I don't know about anybody else, but at this point I have written code that
assumes that if an object
Ronald Oussoren added the comment:
Not sure what changed, but these tests are reported as failures when I run
'make test' and not as expected failures.
--
nosy: +ronaldoussoren
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
Florent Xicluna added the comment:
I am not a native english speaker, but it seems that the common usage of
encode/decode is wider than the restricted definition applied for Python 3.3:
Some examples:
* RFC 4648 specifies Base16, Base32, and Base64 Data Encodings
R. David Murray added the comment:
Ronald: in 3.4 only? If so I wonder if the subtests patch had an unintended
side effect...I'm pretty sure it touched the expected failure machinery somehow.
--
nosy: +r.david.murray
___
Python tracker
Ezio Melotti added the comment:
While not strictly necessary, a PEP would be certainly useful and will help
reaching a consensus. The PEP should provide a summary of the available
options (transform/untransforms, reintroducing encode/decode for bytes/str,
maybe others), their intended
Serhiy Storchaka added the comment:
- Using PyUnicode_FromFormat() works, but then I don't know how to convert
the result to const char*
PyUnicode_AsUTF8()
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
I considered that, but is it guaranteed that the output encoding is UTF-8?
What if the warning is printed on a Windows console that uses cp1252? I also
considered encoding it and then use PyBytes_AsString, but I was hoping in
something simpler (also I'm not
New submission from Guilherme Simões:
After changing the contents of a file in an Editor Window and closing without
saving the Save on Close window pops up. On both MacOS and Linux the user
can't do anything on the Editor Window anymore, but on Windows, not only can
the user continue to write
Ronald Oussoren added the comment:
Yes, only on 3.4:
==
ERROR: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest)
--
Traceback (most recent call
Nick Coghlan added the comment:
It's entirely possible the hack in test_socket (where it catches
unittest._ExpectedFailure to suppress the issues in the tearDown code after the
test fails) were invalidated by the subtest changes.
--
___
Python
Nick Coghlan added the comment:
+1 for someone stepping up to write a PEP on this if they would like to see the
situation improved in 3.4.
transform/untransform has at least one core developer with an explicit -1 on
the proposal at the moment (me).
We *definitely* need a generic
Serhiy Storchaka added the comment:
I considered that, but is it guaranteed that the output encoding is UTF-8?
PyErr_WarnExplicit() calls PyUnicode_FromString() which made an inverse
decoding from UTF-8.
--
___
Python tracker
Ronald Oussoren added the comment:
FWIW I've filed a bug report about the behavior of sendmsg with Apple, the
RADAR number is 13716133.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12958
Kyle Simpson added the comment:
I can't reproduce this issue for v2.7.2 anymore, and none of the other versions
have this problem.
Is it possible to regenerate the online docs for v2.7.2 before closing this
issue?
--
___
Python tracker
R. David Murray added the comment:
I was visualizing transform/untransform as being restricted to
buffertype-bytes and stringtype-string, which at least for binascii-type
transforms is all the modules support. After all, you don't get to choose what
type of object you get back from encode or
Matt Clarke added the comment:
It seems that any argument greater than 8 bytes is automatically converted
to a references. Thus, changing to using ctypes.POINTER works. For example:
callback_t = ctypes.CFUNCTYPE(None, ctypes.POINTER(myst_args))
Quite a simple solution in the end. Is it worth
Nick Coghlan added the comment:
If transform is a method, how do you plan to accept arbitrary buffer supporting
types as input?
This is why I mentioned memoryview: it doesn't provide decode(), but there's no
good reason you should have to copy the data from the view before decoding it.
R. David Murray added the comment:
I agree with you. transform/untransform are parallel to encode/decode, and I
wouldn't expect them to exist on any type that didn't support either encode or
decode. They are convenience methods, just as encode/decode are.
I am also probably not invested
Guido van Rossum added the comment:
str.decode() and bytes.encode() are not coming back.
Any proposal had better take into account the API design rule that the *type*
of a method's return value should not depend on the *value* of one of the
arguments. (The Python 2 design failed this test,
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
R. David Murray added the comment:
Senthil, are you saying (in the review) that we should treat the current return
value of full_url as a bug, and fix it in maintenance releases? It is
certainly true that its value does not match the documentation.
Ah. I see that get_full_url used to have
Éric Araujo added the comment:
Thanks for the update. The docs under /release/x.y.z are snapshots from that
release, so they are not continuously regenerated. If the current /2 and /2.7
docs are good, this can be closed.
--
resolution: - out of date
stage: - committed/rejected
Paul Hoffman added the comment:
Mark:
I don't see how math.isnan or math.isinf would be affected: we're not
proposing to make a float16 Python type, so math.isnan would never encounter a
float16 value.
I was assuming that this proposal would also make this part of class 'float'
just like
Terry J. Reedy added the comment:
What behavior on which system to you consider to be buggy? On 3.3.1, Win 7, all
seems fine. By selecting Windows as a component, you imply that something is
wrong on Windows.
on Windows, not only can the user continue to write[(if the user Cancels),] it
is
Mark Dickinson added the comment:
Paul: your example works because struct.unpack('f', packed_stuff)[0] returns a
regular Python float, backed by C double---i.e., exactly the same type that's
returned by struct.unpack('d', packed_stuff)[0]. In effect, the
single-precision C value is computed
Antoine Pitrou added the comment:
The problem with autodetecting is that it makes it impossible for an
application to use this library to verify that something is encoded in
a specific way. Explicit is better than implicit.
Agreed. Also, you generally known what format your data is in.
Georg Brandl added the comment:
FWIW, I'm not interested in seeing this added anymore.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Paul Hoffman added the comment:
I *think* what you are saying is that there will be no float16 type, but the
result of struct.unpack('eorwhatever', packed_stuff)[0] will be the same as
struct.unpack('f', packed_stuff)[0], yes? If so, that's what I wanted. I don't
want a new float16; I want
New submission from Serhiy Storchaka:
Quoting Victor Stinner from msg106669:
It's maybe possible for write some 2to3 fixers for the following examples:
encode(base64) = base64.b64encode(...)
encode(rot13) = do nothing (but display a warning?)
encode(zlib) = zlib.compress(...)
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17823
___
___
Python-bugs-list
Changes by Serhiy Storchaka storch...@gmail.com:
--
title: 2to3 fixers for - 2to3 fixers for missing codecs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17823
___
Dave Malcolm added the comment:
On Sat, 2013-04-20 at 21:25 +, Ned Deily wrote:
Ned Deily added the comment:
Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?
I was trying to think of one; the only reason I can think of is if there
are any compilers out
R. David Murray added the comment:
Interesting that you consider Windows working as expected, Terry. I thought
save/close dialogs were generally modal; but, then, I avoid GUIs whenever
possible so I could easily be wrong :)
--
nosy: +r.david.murray
Dave Malcolm added the comment:
BTW, is that GCC format checking code available anywhere?
Am I right in thinking that it was an out-of-tree patch to GCC, from the
pre-plugin days?
[My cpychecker code adds some similar checking, but it doesn't use this
attribute]
--
Zachary Ware added the comment:
After finally finding a way to check the status of the pushd stack, I found a
bug in my patch whereby an extra directory is left on the pushd stack at the
end of each run. As such, the version 5 patch changes from using 'goto end' to
using 'exit /B
Serhiy Storchaka added the comment:
What about backporting this fixes to 2.7?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10951
___
Gregory P. Smith added the comment:
consensus here appears to be bad idea... don't do this.
--
nosy: +gregory.p.smith
priority: high - normal
resolution: - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker
paul j3 added the comment:
Yes, http://bugs.python.org/msg166175 does use 'parse_args' in the second call.
But I think things would be more flexible if we had a second function:
def parse_???(self, args=None, namespace=None):
args, argv = self.parse_intermixed_args(args,
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz, pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13533
___
___
Nick Coghlan added the comment:
No, transform/untransform as methods are a bad idea, but these *codecs*
should definitely come back.
The minimal change needed for that to be feasible is to give errors raised
during encoding and decoding more context information (at least the codec
name and
Terry J. Reedy added the comment:
Because model is normal (as far as I know) I did not understand that 'continue
to write' meant doing so without hitting [Cancel] ;-). I might consider being
able to do so a feature *if* the dialog were the only one ever created and if
subsequent attempts to
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16427
___
___
Python-bugs-list
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz, pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9141
___
___
Terry J. Reedy added the comment:
If I open Command Prompt, and start Idle with
C:\Python\Python33python -m idlelib
I get the same attribute error without the Shell window closing. Perhaps not
having a console to write the traceback to closes 3.3 but not 2.7. Peculiar.
--
Gregory P. Smith added the comment:
okay, but i don't personally find any of these to be good ideas as codecs
given they don't have anything to do with translating between bytes-unicode.
--
resolution: wont fix -
stage: committed/rejected -
status: closed - open
Terry J. Reedy added the comment:
A different console message, Shell window not closed
Python 3.4.0a0 (default:bcfb6888fb8d, Apr 18 2013, 19:47:33)
import idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
File \cpython\lib\tkinter\__init__.py, line 1475, in
Demian Brecht added the comment:
As suggested by Senthil, I've broken this up into two patches: One that
implements this reusable Request (this one) and one that implements the new
(consistent) behaviour, in having full_url return the fragment.
I will also add a bug/patch requesting the
Changes by Demian Brecht demianbre...@gmail.com:
Added file:
http://bugs.python.org/file29995/request_17272.2.full_url_w_fragment.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17272
___
Nick Coghlan added the comment:
The codecs module is generic, text encodings are just the most common use
case (hence the associated method API).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Larry Hastings added the comment:
Serhiy: Oh, I get it, your critique was about the Note: part at the bottom.
It would have been helpful if you had inserted your feedback there, instead of
at the top. Yeah, you're right, the note was incorrect.
I considered adding a note saying that the
Guilherme Simões added the comment:
From what I could see the problem is that in MacOS askyesnocancel stops the
user from interacting with all windows and in Windows it stops the interaction
only in the root window (even when the parameter 'master' is used, as is the
case in IDLE). Since the
James Pye added the comment:
Thinking about this again.. perhaps a better approach would be to force the
embedder to define the symbol in their binary.
That is, libpython.x doesn't define Py_FatalError. The binary that links in
libpython defines it.
(and a me too on Jonathan's comments.. for
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz, pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1195571
___
___
Glenn Linderman added the comment:
Yes, a second function would give more flexibility.
Due to the approval in msg166175 to use the name parse_intermixed_args for
the functionality described there, it would probably be best to use that name
for that functionality.
So then we are left naming
New submission from Gustavo Niemeyer:
This simple script will spawn N Python interpreters that aren't properly
collected due to the improper error handling:
import pty
for i in range(N):
try: pty.spawn([/non-existent])
except: pass
--
components: Library (Lib)
messages: 187681
Raymond Hettinger added the comment:
iter_unpack() is closer to how we name other iter variants, so I think you
ought to stick with that. The other names are too creative (and hence less
guessable).
--
nosy: +rhettinger
___
Python tracker
Roger Serwy added the comment:
IDLE crashing is due to issue13582. We should maybe focus on that issue in the
near future as it has become a common theme in many bug reports.
--
___
Python tracker rep...@bugs.python.org
Roger Serwy added the comment:
I clicked submit too soon. The attached patch inhibits closing of the Editor
when the dialog box appears. It also sets the parent argument so that Tkinter
on Windows actually presents a modal dialog box.
What's happening is the the dialog box enters a nested Tk
Roger Serwy added the comment:
The Options menu will become populated as soon as other extensions get included
into IDLE, such as issue6143.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17532
89 matches
Mail list logo
