New submission from Chris Jerdonek:
This issue is to add a function to the os module for getting the path to the
default shell (e.g. os.getdefaultshell()).
In issue 16255, it was reported that on Android, the path to the default shell
is /system/bin/sh rather than /bin/sh which it is on other
Chris Jerdonek added the comment:
I created issue 16353 for adding a function to the os module for getting the
path to the default shell.
The current issue 16255 could be addressed in 3.4 by calling such a function
from the subprocess module. For earlier versions (since enhancements
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
title: It would be nice if documentation pages linked to other versions of the
same document - documentation pages should link to other versions of the same
page
Chris Jerdonek added the comment:
Can you give an example of what you would like the API to look like (i.e. what
you would like to be able to type from the command-line if, say, configuring
logging as in the SO post)?
I'm not sure I understand why a wrapper script isn't a good enough solution
Chris Jerdonek added the comment:
I recommend closing this as a duplicate.
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16331
Chris Jerdonek added the comment:
Both patches (for 2.7 3.2) are almost the same as the original patch.
Conflicts were trivial.
For future reference, it's okay (and perhaps preferable) to upload a patch just
for the default branch when no substantive changes are needed for other
branches
Chris Jerdonek added the comment:
Excessively large source files are a sign of bad software design.
Do you [want to] weigh in the python-dev discussion about splitting
unicodeobject.c?
Nick did weigh in starting here:
http://mail.python.org/pipermail/python-dev/2012-October/122391.html
Chris Jerdonek added the comment:
I could be misinterpreting the documentation, but it looks to me like the
examples given are behaving as documented:
parameter_list ::= (defparameter ,)*
( * [parameter] (, defparameter)*
[, ** parameter
Chris Jerdonek added the comment:
Duplicate of issue 9232 (enhancement request).
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - Allow trailing comma in any function argument list.
___
Python tracker rep
Chris Jerdonek added the comment:
If you are planning to further split support.py, then I'm -1.
Ezio, this issue is not to split up support.py. Nick already responded to you
to this effect in the fourth comment above. Also, in the second comment to
this issue, I said that this issue
Chris Jerdonek added the comment:
Nick would be a better person to review the patch since IIRC he worked a bunch
on that module (e.g. in the changeset you mentioned). But if I get a chance I
will take a look.
--
___
Python tracker rep
Chris Jerdonek added the comment:
Before we discuss wording, it's not clear to me whether all possibilities have
been checked. I count 2*3*2=12 possibilities to check (excluding src and dst
being on different filesystems):
src: file or directory
dst: file, empty directory, or non-empty
Chris Jerdonek added the comment:
Thanks for the patch.
-self.testNames = (self.defaultTest,)
+if isinstance(self.defaultTest, str):
+self.testNames = (self.defaultTest,)
+else:
+self.testNames = tuple(self.defaultTest
Chris Jerdonek added the comment:
Hmm. This patch still raises the has no docstrings ValueError if not tests
is True. And because the patch changes the default DocTestFinder, it's
possible that the patch changes behavior in non-error use cases.
Why not just return an empty TestSuite
Chris Jerdonek added the comment:
testscenarios copies the tests, it doesn't call the constructor for the class;
My suggestion on how to override __str__ (by assignment to __class__) doesn't
require that the constructor be called.
--
___
Python
Chris Jerdonek added the comment:
It occurs to me that logic for detecting the shell might make sense for being
part of the os module, e.g. os.getdefaultshell().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16255
Chris Jerdonek added the comment:
So the relevant code is this:
def getDescription(self, test):
...
43 return str(test)
...
What I'd like is to have this be something like:
44 return test.id()
Or anther way this could be done would be to make TestCase.__str__ call
self.id()
Note
Chris Jerdonek added the comment:
This issue does not seem limited to a particular page. For example, the
Previous topic link for the Python Standard Library part:
http://docs.python.org/library/index.html
is 9. Full Grammar specification, which is the last section of the following
part
Chris Jerdonek added the comment:
http://docs.python.org/tutorial/ the previous link goes to
http://docs.python.org/whatsnew/2.0.html.
This seems correct to me since the 'All What's new documents since 2.0' part
of the documentation occurs immediately before the Tutorial part, and 2.0
Chris Jerdonek added the comment:
Note that the 2.0 issue was previously reported in issue 4988 and issue 7683.
The issue I described occurs because the parts on the home page are listed in
an order different from their order in the table of contents:
http://docs.python.org/
http
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16288
___
___
Python
Chris Jerdonek added the comment:
It seems simple enough for us to make the default configurable
This seems good to do in any case (as opposed to having the string be
hard-coded), and we can test it independently of Android. There is a
recently added test in the 3.x branches that can
Chris Jerdonek added the comment:
The last \n is needed for the reason Andrew mentioned, but it is true that the
sentence could probably be rephrased to reduce the chance of confusion.
--
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
I would suggest something like this:
In text mode, the default when reading is to convert platform-specific line
endings (\n on Unix, \r\n on Windows) to just \n. When writing in text mode,
the default is to convert occurrences of \n back to platform
Chris Jerdonek added the comment:
Here is a somewhat simpler way to reproduce (following the same definition of
x):
dir(x)
...
TypeError: object does not provide __dir__
x.__dir__
built-in method __dir__ of cell object at 0x10c182950
dir(x)
['__class__', '__delattr__', '__dir__', '__doc__
Chris Jerdonek added the comment:
Committed. Thanks for the report!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: behavior - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16266
Chris Jerdonek added the comment:
Attaching updated patch based on Ezio and Antoine's comments. Let me know if
I'm not using the correct or preferred terminology around buffer objects and
the buffer protocol.
It doesn't seem like the section on the buffer protocol actually says what
objects
Chris Jerdonek added the comment:
Reattaching patch (a line was missing).
--
Added file: http://bugs.python.org/file27592/issue-13538-3-default.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13538
Chris Jerdonek added the comment:
This should be reported in another issue though.
Has this been done?
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10836
New submission from Chris Jerdonek:
This issue is to fix invocations of URLError so that reasons are not passed
in for the filename argument of the URLError constructor.
Ezio found and described this issue when commenting on issue 10836:
http://bugs.python.org/issue10836#msg172988
In more
Chris Jerdonek added the comment:
For tracking purposes, I created issue 16250 for what you observed above, which
as you said is related to but not the same as Nick's issue 16247.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Chris Jerdonek added the comment:
raise URLError('local file error: not on local host')
I should also point out that URLError invocations with formats like the above
already do occur in Lib/urllib/request.py. For example:
raise URLError('ftp error: no host given')
exc = URLError
Chris Jerdonek added the comment:
I couldn't find any doc for bytes.join, etc.
One of the contributing factors to this is that bytes doesn't have its own
class entry in the same way that, for example, list, dict, and memoryview have.
This creates a stumbling block for readers because
Chris Jerdonek added the comment:
For future reference, this affects 3.2 onwards. It probably makes sense to
address this in the same branches in which we plan to address issue 16247
(currently set to 3.3 onwards).
--
stage: - needs patch
versions: +Python 3.3
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +asvetlov, chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16255
Chris Jerdonek added the comment:
I would just say that str(bytesobj, encoding, errors) is equivalent to
bytesobj.decode(encoding, errors) (assuming it really is).
Good suggestion. And yes, code is shared in the following way:
http://hg.python.org/cpython/file/d3c7ebdc71bb/Objects
Chris Jerdonek added the comment:
Committed without changing the first sentence, as Éric preferred.
Thanks for the report, Mark!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
title: list.remove in for loop - add to looping techniques tutorial a note
about modifying sequence
type: - enhancement
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep
Chris Jerdonek added the comment:
Thanks, Raymond. I will be doing that later today.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16225
Chris Jerdonek added the comment:
Committed. Thanks for reporting the suggestion, Ian.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16225
Chris Jerdonek added the comment:
I have worked with languages where you are explicitly warned that you must
not mess with the loop variable
There is a warning in this part of the tutorial:
It is not safe to modify the sequence being iterated over in the loop...
(from http
Chris Jerdonek added the comment:
Attached is a simple way of addressing this (essentially copying the verbiage
and example from the other page). If we want, we could make the sample code
different so that the reader doesn't see the same thing twice.
--
keywords: +patch
stage
Chris Jerdonek added the comment:
I wonder why the note must be there at all. None of the 2.x docs have been
updated to cover the 3.x versions of Python. Otherwise, every 2.x page could
use such a disclaimer.
Here is where the note was added:
http://hg.python.org/cpython/rev/bdef454f7212
Chris Jerdonek added the comment:
It is safe to modify a sequence during iteration if it's size not increased.
What do you mean by safe? The example given by the original commenter does
not increase the size either. I believe safe is meant in the sense of
avoiding possibly unexpected
Chris Jerdonek added the comment:
I don't think there is a need to update the 3.1.x version of the
documentation in that respect.
versions: +Python 3.3, Python 3.4 -Python 3.1
This issue was just about the 2.7 version. 3.x doesn't contain the language
mentioned by the original commenter
Chris Jerdonek added the comment:
3.x doesn't contain the language mentioned by the original commenter.
3.2 onwards I mean.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16227
Chris Jerdonek added the comment:
I filed this in case it signals some underlying issue with search that could
use improving (and that may affect other search terms). I can change the title
to remove the focus on those two terms.
--
___
Python
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
title: server-side clone not found by devguide's search box - some terms not
found by devguide's search box
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16222
Chris Jerdonek added the comment:
But in general the advice should be: if you want to insert or remove elements
during iteration, iterate over a copy.
I would expand this to cover changing the list in any way. I think the point
being made is that iteration doesn't implicitly make a copy
Chris Jerdonek added the comment:
That proposal sounds fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16227
___
___
Python-bugs-list
Chris Jerdonek added the comment:
Attaching proposed patch.
--
keywords: +patch
Added file: http://bugs.python.org/file27571/issue-16227-1-27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16227
Chris Jerdonek added the comment:
Attaching revised patch.
--
Added file: http://bugs.python.org/file27573/issue-16225-2-default.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16225
Chris Jerdonek added the comment:
I would not rephrase the first two lines.
Why not? The current language focuses on the negative (explaining problems)
while we prefer an affirmative tone:
http://docs.python.org/devguide/documenting.html#affirmative-tone
Chris Jerdonek added the comment:
Reattaching. I duplicated a variable definition that was defined previously.
--
Added file: http://bugs.python.org/file27575/issue-16225-3-default.patch
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
I mean it does not lead to crash, hang, etc.
I agree. I removed the word safe in the patch I attached to reduce
ambiguity. Regarding unexpected behavior, remember that the tutorial is for
beginners/newcomers
Chris Jerdonek added the comment:
It will be nice somewhere in deep clarify for experts what happens with list
iterator if the list changed.
There is a note somewhat to this effect here:
http://docs.python.org/dev/reference/compound_stmts.html#the-for-statement
Note There is a subtlety
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16206
Chris Jerdonek added the comment:
Attaching a proposed patch along the lines suggested by Éric.
--
keywords: +patch
versions: +Python 3.4
Added file: http://bugs.python.org/file27556/issue-13538-1-default.patch
___
Python tracker rep
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15936
___
___
Python
New submission from Chris Jerdonek:
Neither searching for server-side nor clone in the devguide Quick Search
box pulls up the mention of server-side clones:
http://docs.python.org/devguide/committing.html#long-term-development-of-features
--
components: Devguide
messages: 172849
nosy
New submission from Chris Jerdonek:
The documentation for dict() (for both the built-in function and the class
constructor) should display multiple signatures as do dict.__doc__ and the
documentation for, say, str().
Currently, the dict() documentation just has one signature:
dict([arg
New submission from Chris Jerdonek:
The method signatures for some of the classes documented in library/stdtypes
lack the class name. For example, the list, dict, set, and memoryview methods
lack the class name. Adding the class name will help to distinguish methods
from functions
Chris Jerdonek added the comment:
I think I would be more okay with this if it weren't for the fact that some
functions also appear indented under their class entries (making them look like
methods). Right now, there's no visual distinction between the functions and
the methods. Prefixing
Chris Jerdonek added the comment:
So it looks like the class name gets stripped when rendering if you prefix the
method name with the class name and the methods are nested beneath the class.
So it seems like the options are to either (1) move the non-methods outside the
class (e.g. before
New submission from Chris Jerdonek:
This issue is to add a str class entry to the built-in types page like we have
for dict, set, memoryview, etc:
http://docs.python.org/dev/library/stdtypes.html
This will let us reference ``str`` the class separately from ``str()`` the
built-in function
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
title: add class name to method signatures in stdtypes docs - distinguish
methods from non-methods in classes in the stdtypes docs
___
Python tracker rep...@bugs.python.org
http
New submission from Chris Jerdonek:
[Found by Ezio]
The built-in function documentation has what looks like two separate
definitions of the built-in function type():
http://docs.python.org/dev/library/functions.html#type
These two definitions should be combined into one with a multi-line
Chris Jerdonek added the comment:
If :class:`str` and :func:`str` point respectively to stdtypes.rst and
functions.rst once a class directive is added to stdtypes.rst, then we can do
that.
I agree. I would suggest starting small by adding a stub class entry above the
string methods
Chris Jerdonek added the comment:
Attaching proposed patch.
--
keywords: +patch
Added file: http://bugs.python.org/file27546/issue-16206-1-default.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16206
Chris Jerdonek added the comment:
Let me start over with what I'm suggesting, because the idea wasn't fully
developed when I first filed this issue.
I'm thinking that we should create a class entry for str that contains the
current string methods nested beneath it -- a bit like issue 12901
Chris Jerdonek added the comment:
Perhaps if some machines expect otherwise that should be documented,
otherwise might we change them.
The very beginning of the ctypes documentation has documentation to that effect:
Note: Some code samples reference the ctypes c_int type. This type
Chris Jerdonek added the comment:
I don't know off-hand. But maybe an additional note or code comment at the
first instance in a code example would help. Switching the examples to c_long
might serve only to shift potential confusion from the examples to someone's
personal machine
Chris Jerdonek added the comment:
I'll say it again, the devguide should be short enough to be practical for
someone learning to contribute.
Better organization could help here. I could see the devguide being a
combination of (1) a brief document meant to be read cover to cover
Chris Jerdonek added the comment:
Would this be the appropriate place for the links to the two essays:
Personally, I would start out with a question in the FAQ. It could be called
something like, When is a change to Python justified? and go after or in the
same section as the question
Chris Jerdonek added the comment:
Either there's another way to run those tests on selected platforms that can
be used instead
A way to do it could be to register new doctest directives that skip the marked
test based on the value of sys.platform. If we remove the directives, we lose
Chris Jerdonek added the comment:
This is the suggested change in the bug report I linked to above (providing we
are using 2.3 or later):
If you'd like the latter in hgweb, you can get it by editing '|user' [to
'|emailuser'] in the templates.
(from http://bz.selenic.com/show_bug.cgi?id
Chris Jerdonek added the comment:
FTR there were a few actual errors that I fixed (mostly about bytes vs
string).
Great! Note that for the others, I was just trying to make the files parseable
rather than passing. Currently, doctest aborts out on the files I fixed
without even attempting
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
assignee: docs@python - chris.jerdonek
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16199
Chris Jerdonek added the comment:
Fixed. Thanks for the report, Mark!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16199
New submission from Chris Jerdonek:
3.3 added a dedicated section to the docs for the str type. However,
references to :class:`str` still link to the documentation of the built-in
function str().
This issue is to update references to the str class to point to the new section
on the str type
Chris Jerdonek added the comment:
I'm not sure if Sphinx would allow it, but it would be nice if references to
the function str() could link to the built-in function documentation, and
references to the class str could link to the section on the str type
Chris Jerdonek added the comment:
This may have been addressed to some extent by issue 14783:
http://hg.python.org/cpython/rev/3773c98d9da8
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13538
Chris Jerdonek added the comment:
The documentation seems to take a similar approach with dict:
http://docs.python.org/dev/library/stdtypes.html#dict
http://docs.python.org/dev/library/functions.html#func-dict
--
___
Python tracker rep
Chris Jerdonek added the comment:
replacing repr(args[0]) with repr(executable) in the identified python should
be sufficient for this bug as originally reported.
Yes, almost. The executable variable is a bytes object so it needs to be
fsdecoded first.
I have a test and fix
Chris Jerdonek added the comment:
I made some comments on the changes as committed here:
http://mail.python.org/pipermail/python-dev/2012-October/122125.html
It would be cleaner to use the self.assertRaises() pattern here and
also probably better to share code across the three test methods
New submission from Chris Jerdonek:
Currently, when subprocess.Popen() raises a FileNotFoundError on POSIX systems,
the error message helpfully includes the path not found. But it does not do so
on Windows.
This issue is to include the path also in the messages of the corresponding
errors
Chris Jerdonek added the comment:
Maybe better to fix Windows behavior for unifying FileNotFoundError?
I created issue 16185 to include the path in the messages of the corresponding
errors on Windows.
--
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Yes, the workaround should be applied in those cases as well.
I added the workaround to the last remaining example. Nick was right before in
that three of the four examples I mentioned above were in the part about
option flags rather than in the part about
New submission from Chris Jerdonek:
I got the following irker-related errors when committing about 20 minutes ago:
remote: added 3 changesets with 2 changes to 1 files
remote: buildbot: change(s) sent successfully
remote: sent email to roundup at rep...@bugs.python.org
remote: notified python
Chris Jerdonek added the comment:
Thanks, Georg. Can this new directive be applied to individual code blocks
though (or be modified to do so)?
After a closer review (as mentioned in my comment above), it seems that the
doctest directives should only be displayed in the code snippets
Chris Jerdonek added the comment:
Like these that discuss the behavior of the doctest.IGNORE_EXCEPTION_DETAIL
option (but before doctest directives have been introduced):
http://hg.python.org/cpython/file/0d6910bef979/Doc/library/doctest.rst#l543
The key is that you can have options take
Chris Jerdonek added the comment:
Georg suggested removing the doctest directives from the examples I mentioned.
As currently written, they don't help them pass if doctest were run on the .rst
file. That sounds fine to me for now.
--
___
Python
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16115
Chris Jerdonek added the comment:
It's working now, thanks.
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16187
Chris Jerdonek added the comment:
This seems to look good now. Can this be closed, or is there something else
that needed to be done as well?
--
resolution: - fixed
stage: needs patch - commit review
status: open - pending
___
Python tracker rep
New submission from Chris Jerdonek:
This issue is to configure hg.python.org to display the full e-mail name on the
annotate pages. Currently, instead of displaying everything before the @
symbol, the pages display only the portion of e-mail addresses up to the first
. or @, for example tim
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16115
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16161
Chris Jerdonek added the comment:
BTW, the patch fails for 3.2 and 3.3 but works for 3.4
By patch do you mean test? And by works, do you mean fails or succeeds?
:)
I haven't prepared a patch yet, but I just started working on it. On my
machine, I found that the test fails as is on 3.3
Chris Jerdonek added the comment:
Thanks, Senthil!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15922
___
___
Python-bugs-list mailing list
701 - 800 of 1573 matches
Mail list logo
