paul rubin added the comment:
I would prefer that %d signal an error 100% of the time if you give it a
float. It should not accept 42.0. It is for printing integers.
--
nosy: +phr
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by Paul Winkler:
--
components: Documentation
nosy: slinkp
severity: normal
status: open
title: unittest.findTestCases undocumented
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Paul Winkler:
I cannot find anything about findTestCases on any of the library doc
pages, certainly not at http://docs.python.org/lib/unittest-contents.html
where I'd expect it to be.
__
Tracker <[EMAIL PROTECTED]>
<http://b
Paul Pogonyshev added the comment:
Yes, help with unit tests would be appreciated. Especially since it is
not supposed to fix anything, so I'm not sure what unit tests should be
like...
BTW, trying to understand why the patch didn't remove unreachable code
in your first example, I no
Paul Pogonyshev added the comment:
Speaking of which, I propose that codestr[] array is made one byte
longer and RETURN_VALUE opcode wrote in that extra byte. It will be
removed by this patch anyway (if it is accepted), but we'll remove a way
to accidentally disable peephole optimizer.
I
Paul Pogonyshev added the comment:
Thanks for writing the test.
Yes, I did read the comment. As I understood it, RETURN_VALUE is needed
only so that various optimization can assume codestr[] cannot suddenly
end without one. E.g. if you match for BINARY_ADD, you can safely check
the next
Paul Pogonyshev added the comment:
Well, I cannot guarantee it will _always_ be eliminated, since I too
don't really know when generated bytecode can (currently) end in
non-return. However, if before it ended in non-return, that non-return
must have been unreachable, obviously (else code
Paul Pogonyshev added the comment:
Actually, it is even better. Since you don't increment codelen, that
extra RETURN_VALUE is "virtual" in that it acts as a sentinel, but will
not appear in the resulting bytecode. You can test this by backing out
the patch and disassembling
Paul Pogonyshev added the comment:
Using slightly modified PyGObject (so that it gives more useful error
message in pyg_enum_new) and adding 'raise' in the end of attached
example, I got this:
Traceback (most recent call last):
File "", line 5, in
ValueError: value out
Paul Pogonyshev added the comment:
It doesn't seem 'pickle' itself works:
>>> import pickle
>>> import gtk
>>> s = pickle.dumps (gtk.RC_TOKEN_LOWEST, pickle.HIGHEST_PROTOCOL)
>>> pickle.loads (s)
__main__:1: Warning: cannot retrieve class
Paul Pogonyshev added the comment:
Please close this issue. It is a PyGObject bug, nothing to do with
Python: http://bugzilla.gnome.org/show_bug.cgi?id=519645
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Paul Pogonyshev added the comment:
Hashes being equal for different objects cannot be a bug. At most an
enhancement request...
--
nosy: +_doublep
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Paul Pogonyshev added the comment:
Damn, I wrote a patch too ;)
--
nosy: +_doublep
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2246>
__
___
Pyth
Paul Pogonyshev added the comment:
I think it would be better not to hardcode specific 2 exceptional cases
and indeed follow that second way of instanceof(..., Exception). I
think it was introduced exactly to separate "things that can be caught
by default" from "things that may
Paul Molodowitch added the comment:
Patch for sgmllib.py (and test_sgmllib.py)
Correctly parses quoted attribute - allowing for brackets, newlines, etc
within attributes - implemented by altering the loop which finds
attributes within parse_starttag so it checks for open-ended quotes, and
makes
Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:
Since I'm not on python-dev, I'll mention here that the new behavior
makes no sense to me at all. Which is best highlighted by Frank in
msg63414.
--
nosy: +_doublep
_
Tracker &
New submission from Paul Pogonyshev <[EMAIL PROTECTED]>:
This optimization targets a common case of functions like this:
def foo(a, b):
if a:
if b:
return 'true'
Before the optimization:
6 0 LOAD_FAST0 (a)
New submission from Paul Molodowitch <[EMAIL PROTECTED]>:
**
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**
The original message was recei
Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:
Also, this is the reason for while() in the patch. Consider this function:
def bar(a, b, c):
if a:
if b:
if c:
return 'true'
Before the patch:
11 0 LOAD_FAST
New submission from Paul Komkoff <[EMAIL PROTECTED]>:
The datetime.datetime class overrides some arithmetic operations for it
to be able to add or subtract timedeltas. However, the result of A + B
operation, where A is instance of a subclass of datetime and B is
timedelta instance will be
Paul Komkoff <[EMAIL PROTECTED]> added the comment:
I just checked the astimezone method - it also does this.
As with timedelta... well, it's not critical for me now but it worth
thinking about :)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Paul Molodowitch <[EMAIL PROTECTED]> added the comment:
errr... why was my last message classified as spam? =(
Is there some policy here I'm violating that I'm unaware of? I would
think consolidating of similar issues would be a good thing...
Paul Winkler <[EMAIL PROTECTED]> added the comment:
I'm working on this (at the pycon sprint).
--
nosy: +slinkp
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
paul rubin <[EMAIL PROTECTED]> added the comment:
Rather than factorial how about a product function, so factorial(n) =
product(xrange(1,n+1)). I do like the idea of an imath module whether
or not it has factorial, and the topic of this rfe has drifted somewhat
towards the desirability o
Changes by Paul Winkler <[EMAIL PROTECTED]>:
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1180>
__
___
Python-bugs-list mailing
Paul Winkler <[EMAIL PROTECTED]> added the comment:
The attached patch implements a command-line option to disable loading
of $HOME/.pydistutils.cfg.
After talking to Martin Loewis, I decided not to implement the override
part, because if it's a one-time thing you can just pass the
Changes by Paul Winkler <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9762/python_distutils_1180.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Paul Winkler <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9763/python_distutils_1180.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Paul Kippes <[EMAIL PROTECTED]>:
Without the command line interface to sqlite3, there is no easy method
of extracting a database into an SQL dump file. This creates a problem
should a user want to create an in-memory database (which is useful for
a performance boos
New submission from Paul Moore <[EMAIL PROTECTED]>:
This patch adds a new get_data function to the pkgutil module, allowing
access to data stored in the package directory. It wraps the PEP 302
loader "get_data" function, so that it works with such loaders (for
example, zipimp
Paul Moore <[EMAIL PROTECTED]> added the comment:
I'm not sure I understand. It uses pkgutil.get_loader, which returns a
wrapper for filesystem modules. You pointed me to it. It seems to work,
that's what test_getdata_filesys is testing in test_pkgutil.py.
Can you supply a tes
Paul Moore <[EMAIL PROTECTED]> added the comment:
Is that true? loader.load_module(pkg) should return sys.modules[pkg]
without reloading if it already exists. See PEP 302 "Specification part
1: The Importer Protocol":
The load_module() method has a few responsibilities tha
Changes by Paul Moore <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9792/pkgutil.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2439>
__
Paul Moore <[EMAIL PROTECTED]> added the comment:
Nick, thanks I now see the issue. I'll work up a test to check for this
(and then correct it :-)).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Paul Moore <[EMAIL PROTECTED]> added the comment:
But that's not a valid loader.
I'm still struggling here. I see what you're trying to get at, but I
can't see how I can write a valid loader that does this.
To test the problem you're suggesting (that the code ca
Paul Moore <[EMAIL PROTECTED]> added the comment:
It has to be a valid loader, as I see no reason to support loaders that
aren't valid. In any case, I did try incrementing a counter and it
doesn't demonstrate the problem. If you try the currently attached
patch, you should see
Paul Moore <[EMAIL PROTECTED]> added the comment:
Thanks for the update. Something's seriously screwy here. I am getting
no failures, so you can probably see why I was confused. Can you tell me
what platform, etc (anything that might be relevant) and I'll try to see
Paul Moore <[EMAIL PROTECTED]> added the comment:
By the way, for comparison, I'm running the test (under Windows) using
rt -q -v test_pkgutil from the PCBuild directory. I can't see how
test_getdata_filesys can fail, as long as you're running it from the
correct
Paul Moore <[EMAIL PROTECTED]> added the comment:
Ah, no. I see your command line. I get the same failure as you in that
case. I can see why test_getdata_filesys fails in that case, I'll fix
that. I'm confused as to why test_alreadyloaded fails there but not via
rt.bat, but ne
Paul Moore <[EMAIL PROTECTED]> added the comment:
OK, I found it. There were 2 problems, the double-loading one, and a
problem with adding my importer to sys.meta_path - if the test failed, I
wasn't removing it (so it was there for the next test, and interfering
with it).
Here'
Changes by Paul Moore <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9799/pkgutil.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2439>
__
Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:
This is caused by EWAssayParam being an old-style class. Dunno if it is
a bug in Python or not.
--
nosy: +_doublep
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Paul Kippes <[EMAIL PROTECTED]> added the comment:
Thanks so much.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2426>
__
___
Python-bugs-list mailing
New submission from Paul Davis <[EMAIL PROTECTED]>:
Replicated on:
#Ubuntu 7.0
Python 2.5.1 (r251:54863, Mar 7 2008, 03:39:23)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
#OS 10.4.11
Python 2.5.1 (r251:54863, Oct 26 2007, 16:52:32)
[GCC 4.0.1 (Apple Compute
Paul Davis <[EMAIL PROTECTED]> added the comment:
No prob.
On Sun, Apr 6, 2008 at 7:06 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote:
>
> Gerhard Häring <[EMAIL PROTECTED]> added the comment:
>
> Thanks for reporting this. It's fixed in r621
New submission from Paul Bonser <[EMAIL PROTECTED]>:
The documentation for IMPORT_NAME at
http://docs.python.org/lib/bytecodes.html doesn't mention the fact that
the instruction requires two parameters to be on the stack.
TOS and TOS1 should map to the fromlist and level parame
Paul Moore <[EMAIL PROTECTED]> added the comment:
Thanks,
Paul.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2439>
__
___
Python-bugs-list mailing list
Paul Winkler <[EMAIL PROTECTED]> added the comment:
looks good to me, thanks!
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1753732>
_
___
Python
Paul Winkler <[EMAIL PROTECTED]> added the comment:
Here's an alternate patch that uses a bit of dependency injection to
avoid the need for monkeypatches in setup/teardown. This means some
trivial changes to Distribution.__init__(). I slightly prefer this
approach, but some might ar
Changes by Paul Winkler <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10105/python_distutils_1180_2.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Paul Winkler <[EMAIL PROTECTED]> added the comment:
Phillip, thanks, I missed that script_args is always passed by
core.setup(). I'm replacing the patches with two new versions that check
self.script_args instead of sys.argv (and assumes false if for some
reason script_args isn
Changes by Paul Winkler <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9763/python_distutils_1180.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Paul Winkler <[EMAIL PROTECTED]> added the comment:
and here's the revised version of the dependency-injection approach.
Added file: http://bugs.python.org/file10122/python_distutils_1180_2.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Paul Winkler <[EMAIL PROTECTED]> added the comment:
Phillip, here's another revision of the monkeypatch-in-setUp() approach,
simplified per your suggestions.
Added file: http://bugs.python.org/file10129/python_distutils_1180_3.patch
__
Tracker <[E
Paul Winkler <[EMAIL PROTECTED]> added the comment:
In what way is the comment in core.py inaccurate? I only added the
phrase "and override config files", which is an important side effect of
parse_command_line().
__
Tracker <[EMAI
New submission from Paul Winkler <[EMAIL PROTECTED]>:
A comment in unittest.py says "these functions should be considered
obsolete". But I've seen a lot of code in the wild still using
unittest.makeSuite(MyTestCase)... in fact it's used frequently in the
python stan
New submission from paul rubin <[EMAIL PROTECTED]>:
This is observed in Python 2.5.1, I haven't tried any later versions.
d = collections.deque(xrange(10))
random.shuffle(d)
is quite slow. Increasing the size to 200k, 300k, etc. shows that the
runtime increases quadratical
paul rubin <[EMAIL PROTECTED]> added the comment:
If it's not a bug, it is at least a surprising gotcha that should be
documented in the manual. The collections module is described in the
library docs as "high performance container datatypes" but I could not
possibly
New submission from Paul Melis <[EMAIL PROTECTED]>:
On the 3.0 release page (http://python.org/download/releases/3.0/) the
link to the online documentation is http://docs.python.org/dev/3.0.
However, the doc pages there show the version documented to be "Python
v3.1a0". The
New submission from Paul Goins <[EMAIL PROTECTED]>:
Just got Python 3.0 final on Windows and was testing out IDLE, and it's
having some issues.
Specifically:
* Options -> Configure IDLE..., General Tab:
Change Default Source Encoding from None to UTF-8
* Create a new python fi
New submission from Paul Melis <[EMAIL PROTECTED]>:
The second to last item under "Removed Syntax" (about relative imports)
shows ReST markup in the HTML file, probably not the way it should read:
The only acceptable syntax for relative imports is from .``[*module*]
:keywor
Paul Winkler <[EMAIL PROTECTED]> added the comment:
Whatever happened with this? I don't see it mentioned in the NEWS file
for the 2.6 line.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Paul Nasrat :
--
nosy: +pnasrat
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore :
This patch takes the existing "simplegeneric" decorator, currently an
internal implementation detail of the pkgutil module, and exposes it as
a feature of the functools module.
Documentation and tests have been added, and the pkgutil code has been
upda
Paul Moore added the comment:
Well spotted! I missed that when I checked. I will add tests and
documentation.
I agree that generic is better. I only left it as it was because the
original intent was simply to move the existing code - but that's not a
particularly good reason for keep
Paul Moore added the comment:
Here's an updated patch.
Added file: http://bugs.python.org/file12936/generic.patch
___
Python tracker
<http://bugs.python.org/i
Paul Moore added the comment:
Fair comment. As Ryan said, it's a bit of a bikeshed issue. I prefer
"generic", on the basis that I'd prefer to keep the simple name for the
simple use - something as complex as the RuleDispatch version could use
the name "dispatch"
Paul Moore added the comment:
Agreed about the compatibility. It's there from pkgutil, where to be
honest, it's even less necessary, as simplegeneric was for internal use
only, there. I'm certainly not aware of any backward compatibility
requirements for functools.
Assuming nobo
Paul Melis added the comment:
The "archive" and "subscribe" links for the C++ SIG is incorrect, as the
URL seems to have changed from
http://mail.python.org/pipermail/c++-sig
to
http://mail.python.org/pipermail/cplusplus-sig
---
Paul Moore added the comment:
Agreed (in principle). However, in practice the subtleties of override
order must be documented (and a method of implementation must be
established!!!) Consider:
>>> class A:
... pass
...
>>> class C:
... __metaclass__ = abc.ABCMe
Paul Moore added the comment:
Very good point. Registering for the standard ABCs seems like an
important use case. Unfortunately, it seems to me that ABCs simply don't
provide that capability - is there a way, for a given class, of listing
all the ABCs it's registered under? Even if
Paul Moore added the comment:
Here's an updated patch. I've reverted to the name "simplegeneric" and
documented the limitation around ABCs (I've tried to give an explanation
why it's there, as well as a hint on now to work around the limitation -
let me know if
Paul Moore added the comment:
In principle I don't have a problem with the automatic generation of an
EXE (I assume it generates a shell script with no extension on Unix?)
but it should be done in such a way that the EXE is version-independent.
This is necessary to ensure that pure-p
paul j3 added the comment:
'-1' and '-1.23' are recognized as numbers, and treated as arguments. '-1'
requires some special handling because it is allowed as a flag, as in
parser.add_argument('-1','--one')
'-1:00' on the ot
Paul Moore added the comment:
> as well as potentially being able to be a script or .pyz launcher with a
> simple rename.
Would it be possible to also make the launcher work when prepended to a
zipfile? That's a really useful use-case (make a zipapp automatically runnable,
Paul Moore added the comment:
This is Windows (shell) behaviour. To avoid this, you need to add the .py
extension to the PATHEXT environment variable.
--
___
Python tracker
<https://bugs.python.org/issue47
Paul Ganssle added the comment:
I think this approach is probably the best we can do, but I could also imagine
that users might find it to be confusing behavior. I wonder if there's any
informal user testing we can do?
I guess the ISO 8601 spec does call "Z" the "
New submission from Paul Ganssle :
In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative
`Return ...`: https://bugs.python.org/issue9305#msg110912
Currently we're pretty consistent about `Return ...`, which is consistent with
PEP 257: https://peps.python.or
New submission from Paul Ganssle :
Currently, the `datetime` documentation has this to say about naïve datetimes:
> A naive object does not contain enough information to unambiguously locate
> itself relative to other date/time objects. Whether a naive object represents
> Co
New submission from paul rubin :
Inspired by a question on comp.lang.python about how to deal with an int set
composed of integers and ranges. Range objects like range(1,5,2) contain
start, stop, and step values, but it's messy and potentially tricky to get the
actual first and last v
paul rubin added the comment:
Oh nice, I didn't realize you could do that. len(range) and bool(range) (to
test for empty) also work. Ok I guess this enhancement is not needed. I will
close ticket, hope that is procedurally correct, otherwise feel free to fix.
T
Paul Moore added the comment:
I added the label for you.
--
___
Python tracker
<https://bugs.python.org/issue25172>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
To clarify, I think adding the label needs core dev (or maybe triager) rights
on github, so I don't think it's something you can do yourself.
--
___
Python tracker
<https://bugs.python.o
paul j3 added the comment:
I'm not set up to work with the current development distribution (via github).
All my proposed patches are diffs for earlier repos.
Paul
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
This is normal behaviour of the Windows console command line editing. Python
simply inherits the standard console behaviour.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
Paul Ganssle added the comment:
New changeset 27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 by Paul Ganssle in
branch '3.8':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15227)
https://github.com/python/cpython/commit/27b38b99b3a154fa5c25cd67fe01fb
Paul Ganssle added the comment:
New changeset ed44b84961eb0e5b97e4866c1455ac4093d27549 by Paul Ganssle in
branch '3.7':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15226)
https://github.com/python/cpython/commit/ed44b84961eb0e5b97e4866c1455ac
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
paul j3 added the comment:
hai shi
Do you have a specific need for this, or do you want it just for the same of
completeness?
--
___
Python tracker
<https://bugs.python.org/issue9
paul j3 added the comment:
But see
https://bugs.python.org/issue37793
for a discussion of whether 'container' is as good a descriptor as 'iterable'.
--
___
Python tracker
<https://bug
paul j3 added the comment:
That usage formatting is extremely brittle. It's not just "" metavar that can
mess it up. Other 'usual' characters can mess it in the same way.
The underlying problem is that it formats the whole usage, and if it is too
long tries to
Paul Ganssle added the comment:
> I would support this addition. The timedelta class already has accessors for
> days and seconds, why not for hours and minutes?
The `timedelta.days` and `timedelta.seconds` accessors do not do what is being
requested here. The component accessors jus
paul j3 added the comment:
https://bugs.python.org/issue26510
https://bugs.python.org/issue33109
There was some flip/flop over whether required should be true by default or not
- the current behavior is False, (the 3.3.0)
The lasting change since this issue in 2012 is that `add_subparsers
Paul Ganssle added the comment:
This is a duplicate of #35829.
The reason that 'Z' is not supported is that `fromisoformat()` is not a general
ISO 8601 parser, but rather is intended to be the inverse of `isoformat()`. See
the documentation here:
https://docs.python.org/d
Paul Ganssle added the comment:
> Defining isoformat() and fromisoformat() as functional inverses is misguided.
> Indeed, it's not even true:
`isoformat()` is not the inverse of `fromisoformat()`, that doesn't work
because there are multiple strings that isoformat() can
New submission from Paul Ganssle :
Per Antoine's comment in the discourse thread (
https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220/6 ):
> ... the doc isn’t helpful, as it doesn’t give any alternative.
I think we can link to dateutil.parser.isoparse as an alt
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +15272
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15596
___
Python tracker
<https://bugs.python.org/issu
Change by paul j3 :
--
nosy: +paul.j3
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue27227>
___
___
Python-bugs-list mailing list
Un
Paul Ganssle added the comment:
This is only a semi-arbitrary restriction. Realistically, `datetime` is not a
particularly good way to represent times much older than the 17th or 18th
century (and if you're using time zones, it gets increasingly inaccurate as you
go further back from
Paul Ganssle added the comment:
Sorry for the late response after a patch, but I'm actually -1 on this patch. I
don't think it buys us very much in terms of the API considering it only has 3
parameters, and it adds some complexity to the code (in addition to the
performance issue)
301 - 400 of 3008 matches
Mail list logo
