Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue1644818>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue504152>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue1759169>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue8392>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue2736>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue4007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue1289118>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
assignee: skip.montanaro ->
___
Python tracker
<http://bugs.python.org/issue1374063>
___
___
Python-bugs-list mailing list
Un
Changes by Skip Montanaro :
--
assignee: skip.montanaro ->
___
Python tracker
<http://bugs.python.org/issue2623>
___
___
Python-bugs-list mailing list
Un
Changes by Skip Montanaro :
--
assignee: skip.montanaro ->
___
Python tracker
<http://bugs.python.org/issue1659>
___
___
Python-bugs-list mailing list
Un
Skip Montanaro added the comment:
Confirmed on Mac OSX.
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue8856>
___
___
Python-bugs-list m
Skip Montanaro added the comment:
Sorry, forgot the compiler and OS version:
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
Mac OSX 10.5.8
S
--
___
Python tracker
<http://bugs.python.org/issue8
Skip Montanaro added the comment:
This problem has come up before. It was a bug introduced I think when
the subprocess module was first incorporated into Python. I don't
recall if the default was changed in 2.7 or 3.x. Can you demonstrate
the problem with Python 2.7 or 3.1? If not
Skip Montanaro added the comment:
Can you provide me with a concrete example which fails for you?
I don't have ready access to a Windows machine with Python on
it but should be able to arrange something at work, however before
going through the exercise of spending admin time to install
P
Skip Montanaro added the comment:
I got access to Python 2.6.5 on Windows and ran this simple
example:
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "copyright", "credits" or "licens
Skip Montanaro added the comment:
> If the documentation is not clear enough about requiring binary, it is
> a doc bug.
The documentation for both csv.reader and csv.writer state (this is from the
Python 2.7 version):
If *csvfile* is a file object, it must be opened with the &#
Skip Montanaro added the comment:
Look around the issues. I'm pretty sure I worked on the
unbounded size issue at one point.
Skip
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/i
Skip Montanaro added the comment:
There is the non-zero cost of keeping two copies of that bit of
information in-sync with each other (and the code).
If I execute "pydoc time" I get a link to the online module
docs. It's not there when I execute "pydoc time.strftime"
Changes by Skip Montanaro :
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
Catherine,
Did my suggestion to alter pydoc output so it always contains a link to the
enclosing module's documentation not seem like a reasonable compromise?
Another problem with embedding the format codes in the docstring is that it
opens up a Pandora&
Skip Montanaro added the comment:
A couple wording comments:
"All streams are careful about the type of data you give to them"
would read better as "All streams accept specific types of data".
"The default mode is ``'r'`` (open for reading text, synonym o
Skip Montanaro added the comment:
>> Finally, not specific to this change, but I wonder if rather than
>> having distinct io.StringIO and io.BytesIO classes it would be better
>> to have a single io.MemoryIO class which takes mode arguments just
>&g
Skip Montanaro added the comment:
>> Did my suggestion to alter pydoc output so it always contains a link
>> to the enclosing module's documentation not seem like a reasonable
>> compromise?
Catherine> I actually don't understand how that would h
Skip Montanaro added the comment:
I thought Fred Drake wrote the code that generated that file, but that
was a long time ago in a galaxy far, far away. Perhaps Georg has
subsumed it into his Sphinx/Python doc workflow?
(making Fred "nosy" so he sees this thread...)
S
-
Skip Montanaro added the comment:
Any progress on this? Is the best thing to just set LANG?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue4
Skip Montanaro added the comment:
I'm sure you can craft cases where one order is preferable to
another, but I don't think you can make the case in general
that first in, first out is preferable to last in, first out,
or any other ordering of exit functions.
--
nosy: +skip
Skip Montanaro added the comment:
No, just a result of the finite machine representation of
floats:
>>> repr(1.255)
'1.2549'
so the machine representation of 1.255 is actually less
than that value and round() is doing the right thing.
--
no
Skip Montanaro added the comment:
Retro> I didn't thought about the fact that binary floating point is so
Retro> imprecise and can cause the round() to "error" in some
Retro> situations.
Details on the limitations of floating point arithmetic are here:
Skip Montanaro added the comment:
Not that anybody needs my input on this, but...
Given the range of people advocating for this change, this looks to me
like it should be a release blocker for 3.2. Raymond's comment about
performance seems especially important, and since the world seems
Skip Montanaro added the comment:
I added a placeholder to the What's New document. Since it will affect
extension module authors it should be mentioned at a higher level than just
Misc/NEWS.
--
___
Python tracker
<http://bugs.py
Skip Montanaro added the comment:
I would prefer the gcc-like behavior. I realize there
are constraints on making changes in distutils1, so what
you propose sounds fine to me.
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue1371826>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
Should you be pushing anything to 2.5?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11581>
___
___
Skip Montanaro added the comment:
See Issue 11439.
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11579>
___
___
Python-bugs-list mailin
Skip Montanaro added the comment:
Yes, but this is not a security issue.
--
___
Python tracker
<http://bugs.python.org/issue11581>
___
___
Python-bugs-list mailin
Skip Montanaro added the comment:
John> John Machin added the comment:
John> Can somebody please review my "doc patch" submitted 2 months ago?
My apologies. I have it in my sandbox, but a combination of the switch to
Mercurial and lack of round tuits has conspired
Skip Montanaro added the comment:
Actually, I was thinking of another doc patch for the csv module.
Your changes (or something very like them) made it into the 3.2
release, as you can see here:
http://docs.python.org/py3k/library/csv.html
S
--
resolution: -> accepted
sta
Skip Montanaro added the comment:
Tom Pinckney thinks it's a big deal. I suspect he might be interested
to know why you think it's not. We are entitled to our own opinions
about privacy, but the request at hand concerns another person's
privacy. He's the one
Skip Montanaro added the comment:
I interpreted "not a big deal" to mean that having addresses exposed
was not a big deal. Too many pronouns perhaps.
--
status: pending -> open
___
Python tracker
<http://bugs.pytho
Changes by Skip Montanaro :
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11456>
___
___
Python-bugs-
Changes by Skip Montanaro :
--
assignee: skip.montanaro ->
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10515>
___
___
Python-
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11439>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11445>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11419>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11421>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10954>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10444>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10401>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9650>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9788>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue8387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
John> Skip, The changes that I suggested have NOT been made. Please
John> re-read the doc page you pointed to. The "writer" paragraph does
John> NOT mention that newline='' is required when writing. The "writer"
New submission from Skip Montanaro :
At Antoine's behest, I tried running
./python.exe -m test -j2
in my cpython sandbox and saw several test case failures which
didn't appear when I executed a simple
make test
He suggested I add the -W flag and try again. I did, but I don
Skip Montanaro added the comment:
Thanks. That worked better. Here is the tail end of the output
showing the verbose test output.
--
Added file: http://bugs.python.org/file21362/output
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
Antoine> Skip, can you please try "make distclean" and then rebuild from
Antoine> scratch?
I did. The last output was after
make distclean
./configure ... my usual suspects ...
make
./python.exe -j2 -w
I will try one more
Skip Montanaro added the comment:
Antoine> New changeset 9aa6097131ef by Antoine Pitrou in branch '3.2':
Antoine> Issue #11653: fix -W with -j in regrtest
Antoine> http://hg.python.org/cpython/rev/9aa6097131ef
Antoine> New changeset c381b35e4f31 by Antoine Pit
Skip Montanaro added the comment:
Brett> The import failures are because you didn't rebuild (I added a new
Brett> function to imp). Re-build and the import issues will go away.
An easy mistake to make. I'm used to running "make test" which would have
guaranteed
Skip Montanaro added the comment:
Ned> Skip, what parameters are you using with ./configure ?
Pretty vanilla. Install in my directory tree, get libraries from MacPorts:
--prefix=/Users/skip/local --enable-shared LDFLAGS=-L/opt/local/lib
CPPFLAGS=-I/opt/local/include
I thought you
Skip Montanaro added the comment:
+1. That was the first thing I looked for when I checked
my email today.
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue14732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
> Changes by Éric Araujo :
>
>
> --
> nosy: +skip.montanaro
Thanks, but I'm out of the Python development business, except as it
pertains to my day job...
Skip
--
nosy: +skip.montanaro
__
Skip Montanaro added the comment:
> Skip: I used the nosy field autocomplete which is based on the experts file
> in the devguide; I can mark you "retired" in that file so that your name does
> not show up in autocomplete (but humans will still know that you might be
&
Skip Montanaro added the comment:
Might such a cache lay the groundwork for more aggressive optimizations
by JITs like Unladen Swallow?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10
Skip Montanaro added the comment:
Why is setting your threads as daemons not an option?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10
Skip Montanaro added the comment:
>From the comment in the test_csv.py:
+# XXX: I don't know what the correct behavior should be for these.
+# Currently the first one raises an error that the delimiter can't
+# be determined while the second one retur
Skip Montanaro added the comment:
> FWIW, (simple)json module serializes subclasses of builtin types
> just as expected.
Does that round trip properly? For instance, if you serialize an
instance of a list subclass does it unserialize as a list instance
or as the subclass?
Perhaps JS
Skip Montanaro added the comment:
I get two failures with David's latest patch. Abstracting from
a lightly modified patch:
sample was: 'a,b,"c,d"\r\ne,f,g', got: '', expected: ','
sample was: '"a,b,c,d"\r\ne', got:
Skip Montanaro added the comment:
Also, this comment in test_csv.py puzzles me:
# given that all three lines in sample3 are equal,
# I think that any character could have been 'guessed' as the
# delimiter, depending on dictionary order
As a human looking
Skip Montanaro added the comment:
Here's my candidate patch. Instead of returning an empty string
as the delimiter it returns a comma.
--
Added file: http://bugs.python.org/file20111/csv_delimiter_tests.patch
___
Python tracker
Skip Montanaro added the comment:
John,
The API for the open() builtin function has changed. You should open
the output file with newline="" instead of using the default. Take a
look at the documentation for open() and csv.reader:
http://docs.python.org/py3k/library/func
Skip Montanaro added the comment:
On my Mac it displays "12345". I don't see that as a big problem.
It raises ValueError for a year of -1. This is with build py3k:87566.
If someone wants to feed a year > to time.strftime I don't see that
as a big problem. I l
Skip Montanaro added the comment:
Skip> On my Mac it displays "12345". I don't see that as a big problem.
haypo> Why do you say "problem"? It is the correct result :-)
I agree. I interpreted your ticket as complaining that it should raise
a ValueError if
Skip Montanaro added the comment:
If you intend this to be "safe" in the security sense of the word, I
suggest you release it in PyPI and post a note on comp.lang.python
(a.k.a. python-l...@python.org) asking people to try and break it.
--
nosy: +skip
Skip Montanaro added the comment:
Looking at the csv.rst file I see this statement early in the py3k
docs:
If *csvfile* is a file object, it should be opened with ``newline=''``.
There is also a footnote about the consequences of leaving it out:
.. [#] If ``newline=''
Skip Montanaro added the comment:
My suggestion attached.
--
keywords: +patch
Added file: http://bugs.python.org/file20497/csv.rst.diff
___
Python tracker
<http://bugs.python.org/issue10
Skip Montanaro added the comment:
I disagree. Both os.popen and os.system work fine in the proper context
and are easier to use (and remember how to use) than the subprocess
module. You don't give any examples of breakage, or whether said
breakage is platform-dependent.
--
Skip Montanaro added the comment:
Given this code:
#!/usr/bin/env python
class C:
def bomb(self):
1/0
c = C()
c.bomb()
when run it produces
Traceback (most recent call last):
File "", line 8, in
File "", line 5, in bomb
ZeroDivisionError: integer divisi
Skip Montanaro added the comment:
I'm not sure you can get there from here, certainly not in a
straightforward way. The traceback formatter gets a reference to
the code object (traceback -> frame -> code). That object has a name
attribute (which is what's displayed) but i
Skip Montanaro added the comment:
I agree with Antoine, however, if you can come up with a
reasonable patch which implements the desired behavior, I
think it would be reasonable to add it to Python 3.3. The
definition of "reasonable" is subject to interpretation.
As I indicated in
Skip Montanaro added the comment:
Eric> Note that os.popen is implemented with subprocess.
That seems somewhat wrong to me. There is a stdio popen function which
os.popen used to expose. I thought that was the goal (thin wrapper around
many library functions, then build higher level stuff
Changes by Skip Montanaro :
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
Here's a patch.
--
keywords: +patch
nosy: +skip.montanaro
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20753/compile.diff
___
Python tracker
<http://bugs.py
Skip Montanaro added the comment:
Working on a test case too.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list mailin
Changes by Skip Montanaro :
Removed file: http://bugs.python.org/file20753/compile.diff
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list m
Skip Montanaro added the comment:
It's not so easy as first appeared.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list m
Skip Montanaro added the comment:
Okay, this looks better. I was confusing myself with leftover .pyc
files I think. Test included.
--
Added file: http://bugs.python.org/file20754/compile.diff
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
Georg, I think this might need to sneak into 3.2.
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
3.2 and earlier versions are all frozen, but for 3.3 it might make sense to
bump the version number of the bytecode and change STORE_MAP to take the key
and value in the opposite order, thus allowing to remove the ROT_TWO I had to
add to make this work
Skip Montanaro added the comment:
As Georg suggested, it is correct in 2.4, wrong in 2.5.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Pytho
Skip Montanaro added the comment:
> To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD
> opcodes need minor modifications (just switch the u and w variable
> assignments).
Either of which would not be possible in anything other that 3.3 or
lat
New submission from Skip Montanaro :
I'm working my way through the steps necessary to check out and build
all versions of Python since 2.4 using Mercurial checkouts. I encountered
my first problem with 2.5. It seems the Mercurial checkout creates the
Python-ast.[ch] files before the
Changes by Skip Montanaro :
--
versions: +Python 2.5
___
Python tracker
<http://bugs.python.org/issue11419>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Skip Montanaro :
Trying to build Python 2.5 from a fresh Mercurial checkout I get the
following error trying to build modules using setup.py build:
% nice make
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -L/opt/local/lib -bu
Skip Montanaro added the comment:
Can you explain how I'm supposed to build Python 2.5 from a Mercurial
checkout? What is magic about Sept 2011?
--
___
Python tracker
<http://bugs.python.org/is
201 - 300 of 650 matches
Mail list logo
