Roundup Robot added the comment:
New changeset ee7b713fec71 by Victor Stinner in branch 'default':
Issue #15478: os.lchflags() is not always available when os.chflags() is
available
http://hg.python.org/cpython/rev/ee7b713fec71
--
___
Python tracker
Serhiy Storchaka added the comment:
See also my comments to previous patch about repr() and error message checking.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13349
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: docs@python - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16339
___
Andreas Stührk added the comment:
See also issue #11824 for the ABI tags changes.
--
nosy: +Trundle
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16047
___
Serhiy Storchaka added the comment:
Some conclusions of discussion at Python-ideas
(http://comments.gmane.org/gmane.comp.python.ideas/17719):
1. commonpath() should eat double slashes in input (['/usr/bin', '/usr//bin']
- '/usr/bin'). In any case the current implementation eats slashes on
Serhiy Storchaka added the comment:
I fully agree with Éric. Just don't do this.
--
nosy: +serhiy.storchaka
resolution: - invalid
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14260
Martin v. Löwis added the comment:
Am 12.11.12 14:53, schrieb Tom Pohl:
What do I expect from FD (x//y):
1. Perform a division (I don't care about the details here).
2. Return an integer value q (even if it's stored in a float).
3. The absolute difference between the mathematical division
Stefan Krah added the comment:
Well, there was a test_circular_imports() failure on (I think) the
Windows-amd64 bot last week, but I can't access it any more.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
I'm not so sure. If dicts or classes are used for configuration
or informational purposes, I prefer them to be locked down.
An example of the first is the decimal context, where it was possible
to write context.emax = 9 instead of context.Emax = 9 without getting
Changes by Abel Farias bigcity6...@gmail.com:
--
title: re.groupindex available for modification and continues to work, having
incorrect data inside it - re.grupindex available for modification and
continues to work, having incorrect data inside it
Changes by Abel Farias bigcity6...@gmail.com:
--
nosy: +Abel.Farias
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14260
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
title: re.grupindex available for modification and continues to work, having
incorrect data inside it - re.groupindex available for modification and
continues to work, having incorrect data inside it
Ned Batchelder added the comment:
ITSM this could use more clarification. It is subtle and baffling. I'm
struggling to come up with sentences to make it clearer, though.
--
nosy: +nedbat
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Does argparse actually convert (x)range objects to a list or set (the help
indicates the latter) for internal use?
No, it leaves the provided choices argument as is.
Here is what the documentation says argparse accepts: Any object that supports
the *in*
R. David Murray added the comment:
Given Nick's point about itemgetter, I agree this isn't worth doing. I
wouldn't want the signatures of attrgetter and itemgetter to no longer be
parallel.
Min isn't a problem, by the way, since it accepts an iterator as a single
argument.
--
Christian Schubert added the comment:
Would you please submit a PSF contributor agreement form?
FYI: did that yesterday 9:43 UTC, no reaction (yet)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8865
Éric Araujo added the comment:
I propose using a MappingProxy type in 3.4 and add an example to the docs for
stable versions.
--
resolution: invalid -
stage: - needs patch
versions: +Python 2.7, Python 3.3, Python 3.4
___
Python tracker
New submission from Philipp Hagemeister:
On my system, {} has become significantly slower in 3.3:
$ python3.2 -m timeit -n 100 '{}'
100 loops, best of 3: 0.0314 usec per loop
$ python3.3 -m timeit -n 100 '{}'
100 loops, best of 3: 0.0892 usec per loop
$ hg id -i
ee7b713fec71+
$
Serhiy Storchaka added the comment:
I confirm that.
$ ./python -m timeit -n 100 '{};{};{};{};{};{};{};{};{};{}'
2.6: 0.62 usec
2.7: 0.57 usec
3.1: 0.55 usec
3.2: 0.48 usec
3.3: 1.5 usec
Randomization is not affecting it.
--
keywords: +3.3regression
nosy: +serhiy.storchaka
Serhiy Storchaka added the comment:
Copy or proxy may affect performance. We will need to make benchmarks to see
how much.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14260
___
anatoly techtonik added the comment:
Tested on Windows. Test is attached.
--
keywords: +patch
Added file: http://bugs.python.org/file27976/test_register.py.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13615
Serhiy Storchaka added the comment:
Ah, this is an effect of PEP 412. The difference exists only for creating
dicts up to 5 items (inclusive).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16465
Éric Araujo added the comment:
Thanks, this helps.
--
stage: test needed - needs patch
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13615
___
anatoly techtonik added the comment:
Better test case.
--
Added file: http://bugs.python.org/file27977/test_register.py.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13615
___
anatoly techtonik added the comment:
Fix.
--
Added file: http://bugs.python.org/file27978/register.py.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13615
___
Serhiy Storchaka added the comment:
May be using the free list for keys will restore performance.
--
nosy: +benjamin.peterson, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16465
___
New submission from anatoly techtonik:
Given:
1. there is no .pypirc
2. users enters credentials to register command
3. user refuses to create .pypirc
Outcome:
password is not being stored and subsequent (upload) command doesn't get it.
Attached is the test case.
--
assignee:
anatoly techtonik added the comment:
Fix is attached.
--
Added file: http://bugs.python.org/file27980/register.py.2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16466
___
anatoly techtonik added the comment:
So, if upload command never accepted repository by section name I am +1 for
closing this issue (and opening a new one if symlink workaround is required).
--
nosy: +techtonik
___
Python tracker
New submission from Anthony Tuininga:
With Python 3.3, the ability to create a Python interpreter independent of a
Python installation (as is done with cx_Freeze and other such freezing tools)
has become more difficult to accomplish. Py_Initialize() requires the presence
of a frozen importlib
R. David Murray added the comment:
The file certainly exists, since Python requires it to run. It sounds like
cx_Freeze just doesn't support Python3.3 yet. I don't see that this is a
Python bug.
--
nosy: +r.david.murray
___
Python tracker
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16157
___
___
Éric Araujo added the comment:
If you read the first message again, or the docs, you can see that -r repo-name
was indeed supported.
--
title: upload command no longer accepts repository by section name - upload
command no longer accepts repository by section name
versions: +Python
Éric Araujo added the comment:
Thanks. I remember previous discussion about this (mailing list or bug), I’ll
look for it before applying.
--
stage: - patch review
type: - behavior
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker
Anthony Tuininga added the comment:
The file importlib.h is used when building the Python interpreter but it is
*not* available in a standard (non-source) distribution of Python. I have
copied the file from a source distribution of Python and that does in fact
work, but I don`t want to make
Terry J. Reedy added the comment:
I do not agree with the patch. A summary of my view: Range objects support the
'in' operator and they are an intended option for choices, and, as I said
before, are exactly the right option for arithmetic sequences with more than a
few items. The problem is
Changes by Terry J. Reedy tjre...@udel.edu:
--
nosy: -terry.reedy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13615
___
___
Python-bugs-list
Amaury Forgeot d'Arc added the comment:
I tried to remove all references to #include importlib.h and
_Py_M__importlib, and added the lines in _AddBaseModules():
self.AddAlias(_frozen_importlib, importlib._bootstrap)
self.IncludeModule(_frozen_importlib)
Even if it's not optimal (the
Changes by Shivaram Lingamneni sling...@cs.stanford.edu:
--
nosy: +slingamn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16298
___
___
Tim Golden added the comment:
I'm sorry, but I genuinely can't see what you're trying to say here. If you
believe that there's a bug in Python's standard library, can you show a
reproducible *Python* testcase for it, please (using the pywin32 modules if
that helps) and state clearly what you
Roundup Robot added the comment:
New changeset fcfaca024160 by Antoine Pitrou in branch 'default':
Issue #12428: Add a pure Python implementation of functools.partial().
http://hg.python.org/cpython/rev/fcfaca024160
--
nosy: +python-dev
___
Python
Antoine Pitrou added the comment:
Sorry for the delay. I have now committed the patch to 3.4 (default). Thank you!
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
versions: +Python 3.4 -Python 3.3
___
Python
Antoine Pitrou added the comment:
Would you please submit a PSF contributor agreement form?
FYI: did that yesterday 9:43 UTC, no reaction (yet)
Don't worry, it can take some time to process. We can still apply your
patch, though, since you said you sent a contributor agreement.
--
Karthk Rajagopalan added the comment:
Hi Tim,
Thanks for your reply.
I added test case using perl and python since it was easy to reproduce using
perl socket module and show the issue happening with python's subprocess.py.
There is definitely an action required in subprocess.py to catch
Te-jé Rodgers added the comment:
I have also just been bitten by this. Is there anyway that this can be updated
to support the dotted notation?
--
nosy: +tjd.rodgers
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8400
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15478
___
Changes by py.user bugzilla-mail-...@yandex.ru:
--
title: re.groupindex available for modification and continues to work, having
incorrect data inside it - re.groupindex is available for modification and
continues to work, having incorrect data inside it
Changes by Thomas Kluyver tak...@gmail.com:
--
nosy: +takluyver
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16467
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Does this regression impact any real-world program?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16465
___
Eric Snow added the comment:
The following from the changeset left me with questions:
-from _functools import partial, reduce
+try:
+from _functools import reduce
+except ImportError:
+pass
* Why the try block when there wasn't one before?
* Should reduce be added to __all__ only
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8400
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +brett.cannon, eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16467
___
___
Brian Thorne added the comment:
* Why the try block when there wasn't one before?
* Should reduce be added to __all__ only conditionally?
My mistake, the try block should have just covered the import of partial - that
is after all the exceptional circumstance we can deal with by using the
Raymond Hettinger added the comment:
Does this regression impact any real-world program?
That is a blow-off response. A huge swath of the language is affected by
dictionary performance (keyword args, module lookups, attribute lookup, etc).
Most programs will be affected to some degree --
Eric Snow added the comment:
Possibly reduce could be handled in a similar way with a fallback python
implementation? Otherwise your suggestion of conditionally adding it to
__all__
makes sense to me.
In the meantime I'd expect the import of _functools.reduce to not be wrapped in
a try
Matt Joiner added the comment:
I look forward to your feedback Ezio.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14373
___
___
New submission from Chris Jerdonek:
This issue is to ensure that argparse.ArgumentParser() accepts objects that
support the in operator for the choices argument to
ArgumentParser.add_argument().
As observed by Terry in the comments to issue 16418:
http://bugs.python.org/issue16418#msg175520
Anthony Tuininga added the comment:
Thanks to Amaury for his suggestion. It resolves the problem completely and
answers the question I had about how to proceed. For others who may come across
this, the key was to generate the importlib._bootstrap module (which is what is
found in importlib.h)
New submission from Case Van Horsen:
When attempting to convert a float(nan), float(inf), or float(-inf),
fractions.Fraction() raises different exceptions than int()
int(float(nan))
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot convert float NaN to
Tom Pohl added the comment:
You still get me wrong. Thanks to your explanations and to my personal
knowledge about this topic (programming for 28 years now; PhD in
CS/numerics/HPC) I now fully understand the technical details about the current
implementation of FD. The problem I see is that
Raymond Hettinger added the comment:
FWIW, I agree with this being closed. The current behavior is a fact-of-life
for anyone using binary floating point.
The decimal module is provided people who want more intuitive behaviors when
dividing by numbers like 0.1 which are exactly
Yongzhi Pan added the comment:
Great they are backported to 2.7. Dictionary and set comprehensions are not
documented in the tutorial of 2.7, though they are in the language reference.
Is it OK to add these to the tutorial? I've uploaded a patch.
--
nosy: +fossilet
Added file:
Ezio Melotti added the comment:
I wonder if we should keep the original Python implementation alongside the new
C version. If we do, it would be nice to see a 100% coverage of the Python
version and have the tests check both the implementations.
--
Ezio Melotti added the comment:
Is it OK to add these to the tutorial? I've uploaded a patch.
Yes, but please create a new issue.
How about fixing set.__repr__ ?
Is it broken?
--
___
Python tracker rep...@bugs.python.org
Tom Pohl added the comment:
This is a fact-of-life for anyone using binary floating point:
x = 0.0
while x != 1.0: print(x); x += 0.1 # so long
This is not: 1 // 0.1 = 9.0 because math.floor(1/0.1) is able to come up with
the result that is expected from an operator called floor division.
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti, mark.dickinson, rhettinger, skrah
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16469
___
Antoine Pitrou added the comment:
Possibly reduce could be handled in a similar way with a fallback python
implementation? Otherwise your suggestion of conditionally adding it to
__all__
makes sense to me.
In the meantime I'd expect the import of _functools.reduce to not be
wrapped
Ezio Melotti added the comment:
Even better would be to link to the changelog page instead, but that's only
available for Python 3.3/3.4 (does this issue affect 2.7/3.2?).
http://docs.python.org/3.3/whatsnew/changelog.html
--
nosy: +ezio.melotti, georg.brandl
stage: - needs patch
Ezio Melotti added the comment:
See also #12428.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14373
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
Does this regression impact any real-world program?
That is a blow-off response. A huge swath of the language is affected
by dictionary performance (keyword args, module lookups, attribute
lookup, etc).
I was merely suggesting to report actual
New submission from Yongzhi Pan:
Dictionary and set comprehensions are backported to 2.7 in issue #2333. The are
not documented in the tutorial of 2.7, though they are in the language
reference. Is it OK to add these to the tutorial? I've uploaded a patch.
--
assignee: docs@python
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16470
___
72 matches
Mail list logo
