New submission from Lachlan Kingsford:
An error is being raised that 'There is no disk in the drive. Please insert a
disk into drive \Device\Harddisk1\DR1. Cancel, Try Again, Continue)'.
The line of code referred to has no reference to any file or disk access. None
of its calling procedures
Vinay Sajip added the comment:
It looks as if ensurepip is where changes should happen. The venv code just
makes a subprocess.check_output() call to ensurepip, and anything that
ensurepip outputs would be displayed on the console.
--
___
Python
Georg Brandl added the comment:
next() is quite unlike match() and search(), as you almost never use next() on
iterators directly. Rather, the iterator is iterated by constructs like a for
loop or a comprehension, or another function that consumes it (list, map, ...)
--
nosy:
Tim Golden added the comment:
I very much doubt that this is a Python issue as such.
Other things being equal, I would expect Harddisk\DR1 to be a CD-ROM or
some other removable disk. Using something like winobj.exe from
sysinternals should show what it expects to be on a given machine. It's
Michael Foord added the comment:
Assertions are not uncommon in setUp. setUp is for setting up common state
shared between tests and I regularly want to assert that state creation /
preconditions are correct.
I've never been bitten by this issue (I rarely use expectedFailure), but it's
New submission from Stephan Monecke:
`python2 test.py` results in the following error:
Traceback (most recent call last):
File test.py, line 1, in module
import seaborn as sns
File /path/seaborn.py, line 4, in module
sns.set(style=ticks)
AttributeError: 'module' object has no
Stephan Monecke added the comment:
Edit: test.py contains just import seaborn as sns
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22740
___
Van Ly added the comment:
While next() is rarely used directly on iterators, as you say, it may help to
remind the experienced reader of the mechanical characteristic in essence which
a new reader on first approach uses to construct a mental model.
--
New submission from Van Ly:
-- suggest the following because
-- the parenthetical parts interrupt the reading too often
len(s)
Returns a length count, the number of objects in argument s which may be a
sequence, or mapping: a string, list or tuple, or a dictionary.
--
assignee:
Stephan Monecke added the comment:
Problem found. Induced by a .pyc file in the folder.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22740
___
Changes by Georg Brandl ge...@python.org:
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22740
___
Nick Coghlan added the comment:
Argh, you're making me page _testembed back into my brain. I try to avoid
having to do that ;)
Anyway, this doesn't look like the right fix to me - although it may indeed be
a test bug uncovered by a VC10-VC14 behavioural change in the behaviour of
printf().
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22731
___
___
Python-bugs-list
Ethan Furman added the comment:
I do not think 'next' is needed in this context. Unlike 'match' and 'search',
'next' is a function that can be used with any iterator and mentioning it here
is unnecessary.
--
___
Python tracker
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22738
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22741
___
___
Python-bugs-list
STINNER Victor added the comment:
The PEP 3151 introduced specialized subclasses of OSError. Antoine Pitrou
conducted a survey to decide which errors are common enough to merit a builtin
exception:
http://legacy.python.org/dev/peps/pep-3151/#appendix-a-survey-of-common-errnos
ENOSPC is not
Stefan Krah added the comment:
The original wording is clearer (this also applies to similar issues
that have been opened recently).
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22741
Antoine Pitrou added the comment:
That said I am not against adding a new error for this, but I agree the need is
probably rather rare (the error is rare in itself, and there's not much to do
if you hit a disk space issue, usually).
I'm going to wait for other people to come with comments and
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22256
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22737
___
___
Python-bugs-list
STINNER Victor added the comment:
Would it be acceptable to implement a pipe2 shim for those platforms?
If I understand correctly, you propose to add an option inheritable parameter
to os.pipe():
def os.pipe(inheritable=False):
...
The PEP 446 was written to fix race conditions.
Changes by Matt Frank matthew.i.fr...@intel.com:
--
nosy: +WanderingLogic
Added file:
http://bugs.python.org/file37041/audioop_ctypes_test_link_with_libm.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21668
Matt Frank added the comment:
Additionally,
* audioop calls floor()
* _ctypes_test calls sqrt()
Patch attached.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21668
___
Changes by Matt Frank matthew.i.fr...@intel.com:
--
nosy: +freakboy3742
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21668
___
___
Changes by Matt Frank matthew.i.fr...@intel.com:
--
nosy: +freakboy3742
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20306
___
___
STINNER Victor added the comment:
audioop_ctypes_test_link_with_libm.patch
+ libraries=['m'])
Why not using math_libs here? It would also be nice to add a comment explaining
why libm is needed in each module.
Can someone please combine both patches?
--
New submission from Alexander Belopolsky:
print(\N{ROCKET})
Traceback (most recent call last):
File pyshell#1, line 1, in module
print(\N{ROCKET})
File idlelib/PyShell.py, line 1352, in write
return self.shell.write(s, self.tags)
UnicodeEncodeError: 'UCS-2' codec can't encode
New submission from Friedrich Spee von Langenfeld:
The W3C has published two versions of the standard specification for the
Extensible Markup Language (XML) [version 1.0 and 1.1]. I know that the W3C
expects all parsers to understand both versions. I propose to state here
Matt Frank added the comment:
audioop_ctypes_test_link_with_libm.patch
+ libraries=['m'])
Why not using math_libs here?
math_libs is defined in detect_modules(). But the _ctypes_test
extension is defined in a different function: detect_ctypes().
The other
Василий Макаров added the comment:
I can confirm this issue is fixed for now. Closing ticket..
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22695
New submission from tegavu:
Windows does not like/permit folders with spaces in the beginning or folders
and files with a tailing space character, as this will cause problems.
The python functions for os.mkdir will solve this by eliminating the blanks
automatically.
But os.path.join() will
New submission from Wolfgang Rohdewald:
The attached script works with Python2.7. With Python3.4, it produces
Traceback (most recent call last):
File /usr/lib/python3.4/cgitb.py, line 268, in __call__
self.handle((etype, evalue, etb))
File cgibug.py, line 12, in handle
R. David Murray added the comment:
If I understand you correctly, that would mean that if the namespace keyword is
not used, we'd have the fixed behavior, but if the namespace keyword is used,
we'd have the backward compatible behavior? If I'm understanding correctly,
that sounds like a good
New submission from Wolfgang Rohdewald:
The attached script shows the non-ascii characters wrong wherever they occur,
including the exception message and the comment in the source code.
Looking at the produced .html, I can say that cgitb simply passes the single
byte utf-8 codes without
R. David Murray added the comment:
That would not be consistent with the rest of the docs. Consider, for example,
that the full documetation of dictionary views
(https://docs.python.org/3/library/stdtypes.html#dictionary-view-objects),
which are iterables in much the same way that the
R. David Murray added the comment:
Can you ever imagine the assertions in the setUp being what you would want
reported as an expected failure? I would think that setUp assertion failure
would be something you would want to be always reported as a failure, even if
you expect the test itself
Steve Dower added the comment:
Not so keen on having separate folders for Python version, mostly because I
want to avoid having the current version in too many locations. I've settled on
patchlevel.h as the canonical source of the version number for my VC14 branch -
everything else should
Michael Foord added the comment:
Maybe if the expectedFailure is applied to the whole class and it's the setUp
that is unable to work. I've never seen it used that way of course (mostly
because it doesn't work that way) - but I *can* imagine it.
--
Steve Dower added the comment:
Practically this is very easy to do, and I'm more than willing to author
detection into the new PCbuild files.
Having nasm mirrored on svn.python.org (or anywhere on a PSF host) would be
real nice though. I don't particularly like making the build system rely on
R. David Murray added the comment:
I don't understand how your suggested change would affect the font size issue
(nor do I really understand it as a sentence).
For your second suggestion (which is unrelated), how about instead:
-c str : interpret str as a program (terminates option list)
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: - resolved
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22740
___
Zachary Ware added the comment:
I'm ambivalent on per-version externals dirs by now; I've since found it much
easier to maintain hg-shared repos per branch. I'll go ahead with this shortly
on all three branches, unless there are objections to it on 2.7 and 3.4.
--
versions: +Python
Steve Dower added the comment:
Argh, you're making me page _testembed back into my brain. I try to avoid
having to do that ;)
Hehe, sorry.
My guess would be that VC10 is translating '\n' to '\r\n' in the
printf() calls, and VC14 has stopped doing that.
To confirm my theory: check if it
Amaury Forgeot d'Arc added the comment:
html is text, so the file mode should be 'w'.
But I don't reproduce the behavior with Python version v3.4.2.
Which version are you using exactly?
--
nosy: +amaury.forgeotdarc
___
Python tracker
Steve Dower added the comment:
I missed c_size_t somehow, but as eryksun says, it's not strictly the same
thing. Of course, my current patch isn't the same thing either as it only
supports 32-bit and 64-bit pointer sizes.
I could make a bigger change to use c_void_p and compare its .value
R. David Murray added the comment:
Agreed. The original follows the rules of standard written English (especially
as regards to punctuation), while the suggested replacement does not.
--
nosy: +r.david.murray
resolution: - not a bug
stage: - resolved
status: open - closed
R. David Murray added the comment:
I would classify that as a bug in mkdir (it should raise an error). The
blank-elimination is almost certainly being done at the OS layer (windows)
rather than the Python layer, though, and I doubt it is something we can fix at
the Python layer for backward
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14304
___
___
R. David Murray added the comment:
I don't think what html is is relevant here. Hook is going to be dealing with
strings, though, so 'w' is indeed correct.
The script works fine for me as well. (Also tested it on 3.3.2 since I had it
laying around, so it's not a recent bugfix).
--
R. David Murray added the comment:
If you look at the file, you'll find that the data is in utf-8 (at least if
your locale is a utf-8 locale). However, html is by default interpreted as
latin-1, so that's what the webrowser displays when you pass the file on disk
to it. If you add
tegavu added the comment:
Well then the bug is also for example in the open() to create a file, beause it
will also remove tailing spaces (files can have spaces in the front, while
folders cannot have spces on either side).
Although I still think an API to create a path should warn if this
Steve Dower added the comment:
Paths are processed by the Windows API. This processing includes (at least):
* resolve to current directory
* convert forward slashes to backslashes
* remove adjacent backslashes
* trim trailing dots and spaces from names
* resolve short path names
This
Steve Dower added the comment:
Sounds good to me. I thought about the shared repo approach, but I don't
understand fully how merging between 2.7, 3.4 and default works in that
scenario (simply because I've never tried it - maybe it's really easy?)
--
R. David Murray added the comment:
Yeah, to os.path, paths are just strings, and there's no reference made to the
actual file system. The blanks are valid on unix, for example (unless you pass
them to the shell without escaping them). As Steve indicated, parts of Pathlib
might make a
Robert Collins added the comment:
I've updated the patch to try and address the niggling clarity issues from the
review. Please let me know what you think (and if I hear nothing I'll commit it
as-is since the review was still ok).
--
Added file:
Robert Collins added the comment:
assertions in setUp are fine IMO. But here's the thing. WHat should this code
do?
class Demo(unittest.TestCase):
def setUp(self):
raise Exception('hi')
def test_normal(self):
# this should NOT be covered by expectedFailure
New submission from Matt Frank:
On systems where configure is unable to find langinfo.h (or where nl_langinfo()
is not defined), configure undefines HAVE_LANGINFO_H in pyconfig.h. Then in
pythonrun.c:get_locale_encoding() the call to nl_langinfo() is wrapped in an
#ifdef, but the #else path
Antoine Pitrou added the comment:
Well, if c_size_t is incorrect, then let's go with the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22732
___
Zachary Ware added the comment:
Basically, after:
hg clone h.p.o/cpython default
hg share default 3.4
hg share default 2.7
hg -R 3.4 update 3.4
hg -R 2.7 update 2.7
the 2.7, 3.4, and default directories are separate working copies created from
the same history, each at a different revision.
Terry J. Reedy added the comment:
Since all other dependency directories are dependency version specific, the
only problem with a common external directory is the unversioned tcltk/. What
do you plan to do with that?
--
___
Python tracker
Zachary Ware added the comment:
There's no change from the status quo on that front: the only change
is that the $(externalsDir) VS variable becomes ..\externals instead
of ..\... Is there an open issue for versioning the tcltk[64] dirs?
--
___
STINNER Victor added the comment:
I'm confused because http://bugs.python.org/issue8610 (from 2010) seems
to have come down on the side of deciding that nl_langinfo() failures
should be treated as implicitly returning either ASCII or UTF-8
It's very important than Py_DecodeLocale and
Van Ly added the comment:
The font choice is a matter of style beyond me. I commented on it as I saw it.
The second rendering looks in Capital relative to the first rendering. The
problem wasn't there in v.2.7.5. In saying that, perhaps the information would
be picked up by someone
Van Ly added the comment:
(Well that is a stick in the mud and slap in the face attitude to different
ways of describing what is there.) You have the documentation for len(s)
perfect, __for_everyone__.
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
Well, again, your suggested change for sys.argv is less optimal English. The
text as is seems fine to me.
'feed' is a term generally used when there is a source separate from the
command (for example, we speak about a unix pipe feeding data from one command
Van Ly added the comment:
I don't know what you mean by optimal English. As is, the English is of the
native English speaker's comfy couch guides speaking to guides kind rather than
guides speaking to audience wanting to be guided by.
The suggestion I offered is imperfect and can be improved
Van Ly added the comment:
-c str : interpret str as a program (terminates option list)
+1 (feed is shorter)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22738
___
Wolfgang Rohdewald added the comment:
If you cannot offer a solution for arbitrary unicode, you have no solution at
all. Afer all, that is what unicode is about: support ALL languages, not only
your own.
I do not quite understand why you think this is not a bug.
If cgitb encodes unicode like
Changes by Wolfgang Rohdewald wolfg...@rohdewald.de:
--
resolution: - remind
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22746
___
___
Wolfgang Rohdewald added the comment:
This now works with mode 'w' and after reinstalling the packages. My Python is
3.4.0 (ubuntu).
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
New submission from Berker Peksag:
Porting Extension Modules to Python 3 document mention about PyString_*
functions in Python 3. I think the correct prefix should be PyUnicode_*.
From https://docs.python.org/3/howto/cporting.html#str-unicode-unification:
Python 3’s str() (PyString_*
72 matches
Mail list logo
