Eric V. Smith added the comment:
For int, the spec is:
[[fill]align][sign][#][0][width][,][.precision][type]
So, for "06d", "0" is matched as the literal 0, "6" is matched as width, and
"d" is matched as type.
For "\x00<6d", "\x00&qu
Eric V. Smith added the comment:
I suggest using whatever language explains what "u'%s' %obj" does. It's the
same behavior.
>From the SO question, given:
class A(object):
def __str__(self):
return 'as str'
def __unicode__(self):
Eric V. Smith added the comment:
I'm going to go ahead and close this. Alternate formatting was added to float
and complex. I think leaving this issue open just confuses whether or not that
support was added. I know I had to go back and double check.
Since decimal never participat
Eric V. Smith added the comment:
I believe that comment was referring to the subject of this bug:
$ ./python
Python 3.4.1+ (3.4:bec6f18dd636, Jun 12 2014, 20:23:30)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more informat
Eric V. Smith added the comment:
I agree that glob shouldn't sort. In addition, iglob definitely can't sort, and
I don't think you want to have glob sort but iglob not sort.
--
nosy: +eric.smith
status: pending -> open
___
Pyt
Eric V. Smith added the comment:
I agree with David. And, it already works, but uses '/', not '+':
>>> b / "_name.dat"
PosixPath('/tmp/some_base/_name.dat')
-1 to using + to be the equivalent of:
>>> pathlib.Path(str(b) + "_n
Eric V. Smith added the comment:
To Heikki Partanen excellent point in the review about date __format__ strings
allowing you to combine date formatting with other types of formatting:
This is a great point. It's the lack of this that (for example) requires the
logging module to h
Eric V. Smith added the comment:
It might be more motivating if you (Xavier de Gaye) could let us know of a
real-world problem caused by this behavior.
--
___
Python tracker
<http://bugs.python.org/issue16
Eric V. Smith added the comment:
I agree it's a bug. And the fix looks good to me.
Having said that: I haven't looked at the import.c version to verify what is
happening. Does the test pass under 3.2?
--
___
Python tracker
<http://bu
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I agree on just switching to rpmbuild, at least for 3.4.
--
___
Python tracker
<http://bugs.python.org/issue11122>
___
___
Pytho
Eric V. Smith added the comment:
Because this is a new feature, it could only be added to Python 3.4. Changing
versions.
--
components: +Installation
nosy: +eric.smith
type: behavior -> enhancement
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
Eric V. Smith added the comment:
The more I think about this, the more overly restrictive I realize it is. If
the type of the object really is "object", then it can use string formatting.
It's only for non-objects that I want to add the error.
I'll re-open it and give
Eric V. Smith added the comment:
I agree that we should close this as "won't fix" in 2.7.
--
___
Python tracker
<http://bugs.python.org/issue7300>
___
__
Eric V. Smith added the comment:
What Barry said. :)
I haven't had time to check yet: but why does site.py need the __file__
attribute? Maybe that's the actual problem.
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
I think this issue should be closed, since we're doing as we're instructed by
the OS. If someone wants to open a new issue for the "m" format specifier type,
I'd support that.
--
nosy: +eric.smith
_
Eric V. Smith added the comment:
Isn't this really just an inappropriate use of a string instead of a list? If
indeed this is in the documentation, it should be changed.
I still don't like:
>>> p.add_argument('a', choices=list('abc'))
but at least it wo
Eric V. Smith added the comment:
+1
I'll note (by inspection only) your example code doesn't work under Python 3.x!
:)
(print as a statement)
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
I think ''.join() will always be faster than ''.format(), for a number of
reasons (some already stated):
- it doesn't have to pass the format string
- it doesn't have to do the __format__ lookup and call the resulting function
Eric V. Smith added the comment:
I retract the datetime comment. Given what we're trying to accomplish, I think
we only need to support types that are supported by 2.7's %-formatting.
--
___
Python tracker
<http://bugs.python.
Eric V. Smith added the comment:
So it sounds like the use case is (as Glyph said in msg180432):
- Provide a transition for users of 2.7's of str %-formatting into a style
that's compatible with both str in 2.7 and bytes in 3.4.
In that case the only options I see are to implement
Eric V. Smith added the comment:
I think this change should not be made: it's a slippery slope, because there
are thousands of places in the stdlib where a similar change could be made.
It's the nature of duck typing that you're not going to get a great error
message everywh
Eric V. Smith added the comment:
+1 for PyIndex_AsLong()
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue4591>
___
___
Python-bugs-list mailin
Eric V. Smith added the comment:
On 09/17/2013 09:34 AM, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> Because most often the time at which you want the original key is the point
> at which you are about to re-serialize the data...so you need the value too.
Eric V. Smith added the comment:
On 09/17/2013 10:12 AM, Eric V. Smith wrote:
> On the other hand, I don't have a use case for the original key, anyway.
> So I don't have a strong feeling about this, other than it feels odd
> that the answer to the original question (I think
Eric V. Smith added the comment:
Can you print out sys.executable and sys.path in both cases, and post the
results here?
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19
Eric V. Smith added the comment:
Glad to see it's working.
--
resolution: fixed -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Eric V. Smith added the comment:
The Windows (and before it MS-DOS) EOF character is Ctrl-Z. Try that.
Depending on the toolset you use, it might use Ctrl-D as EOF. Cygwin's python
uses Ctrl-D.
--
nosy: +eric.smith
___
Python tracker
Eric V. Smith added the comment:
It's trying to be consistent on whatever platform it's on. I'd rather
python.exe match all other text-based .exe's on Windows. We can't have it both
ways.
But I agree it's a hassle. Cross-platform is a problem that Cygwin is tryi
Eric V. Smith added the comment:
Closing as rejected.
--
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric V. Smith added the comment:
If you could write up a concrete proposal, including which format specifiers
would be supported, that would be helpful.
Would it be extensible with something like __bformat__?
There's really quite a bit of work to be done to specify how this would
Eric V. Smith added the comment:
Also, with the PEP 393 changes, the implementation will be much more difficult.
Sharing code with str (unicode) will likely be impossible, or require much
refactoring of the existing code.
--
___
Python tracker
Eric V. Smith added the comment:
I've lost track what we were talking about. I thought we were trying to support
b''.format() in 3.4, for a restricted set of arguments.
I don't see how a third-party package is going to help, if the goal is to allow
3.4 to be source comp
Eric V. Smith added the comment:
Can you provide some code which demonstrates this?
It's easier to address this if we have known working (or non-working) examples.
Thanks.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
This isn't strictly related to printing a tuple. It's the difference between
str() and repr():
>>> print (u"äöü") # uses str
äöü
>>> print repr(u"äöü")
u'\xe4\xf6\xfc'
When the t
Eric V. Smith added the comment:
As Martin points out, your first example is printing a string, not a tuple. The
parens here are not building a tuple, they are just used for grouping in the
expression, and are not doing anything in this example.
So my explanation still holds: everything is
Eric V. Smith added the comment:
Remember that one reason for importing the C version at the bottom of the
python version is so that alternate implementations (PyPy, IronPython, Jython)
could provide partial versions of the C (or equivalent) versions. By importing
after the Python version
New submission from Eric V. Smith:
In
http://docs.python.org/library/string.html#format-specification-mini-language,
it says "The fill character can be any character other than ‘{‘ or ‘}’."
But that's not actually true. It's only true when using str.format, as it does
Eric V. Smith added the comment:
See also issue 19238.
--
___
Python tracker
<http://bugs.python.org/issue19289>
___
___
Python-bugs-list mailing list
Unsub
Eric V. Smith added the comment:
See also issue 19289.
--
___
Python tracker
<http://bugs.python.org/issue19238>
___
___
Python-bugs-list mailing list
Unsub
Eric V. Smith added the comment:
Looks good to me. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue19238>
___
___
Python-bugs-list mailing list
Unsub
Eric V. Smith added the comment:
I suggest you get consensus on this idea on the python-ideas mailing list first.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19
New submission from Eric V. Smith:
The python source code usually uses "customiz*" (341 instances) over
"customis*" (19 instance, 8 of which are in logging).
I realize "foolish consistency", and all that, but I think the documentation
should all use the sam
Eric V. Smith added the comment:
It looks like you need to use double-backslashes everywhere in your path, or
use single backslashes and raw strings (r"").
--
nosy: +eric.smith
resolution: -> invalid
status: open -> closed
___
Pytho
Eric V. Smith added the comment:
Apologies for reading too quickly. I've reopened this.
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.
Eric V. Smith added the comment:
Can you provide a small, stand-alone program that demonstrates the problem? In
particular, I want to see how this filename is provided to logging.
--
___
Python tracker
<http://bugs.python.org/issue19
Changes by Eric V. Smith :
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue19528>
___
___
Python-bugs-list
Eric V. Smith added the comment:
Thanks, Peter.
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Eric V. Smith added the comment:
Agreed with Nick. I think it's clear than any change to the behavior will have
to take place inside os.path. I just don't know what that change would be.
--
___
Python tracker
<http://bugs.python.
Eric V. Smith added the comment:
This patch covers the files that Vinay did not update.
--
Added file: http://bugs.python.org/file32677/customise-2.diff
___
Python tracker
<http://bugs.python.org/issue19
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19640>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue8402>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19638>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19660>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
While I think that the dotted_name restriction should be relaxed and it should
instead be a style guide issue, I have to agree with Benjamin here: the
difference in grammar complexity is zero and shouldn't drive the dec
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue14910>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
assignee: -> eric.smith
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Eric V. Smith added the comment:
Shouldn't the existing calls to abspath() be changed to os.path.abspath()? Or
are both patches meant to be applied? I don't think the first patch applies
cleanly any more.
In any event: the deprecation and test look good to me. So assuming we get r
Eric V. Smith added the comment:
Now that I think about it, maybe we don't need a deprecation warning.
http://legacy.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
says:
"Imported names should always be considered an implementation detail. Other
modules must n
Eric V. Smith added the comment:
I don't think we can change the exception type in a bugfix release, if ever. I
don't see much point in changing the exception type: it's just churn.
I'm +1 for a better error message. I'm -0 on changing the error mes
Eric V. Smith added the comment:
0xaand 1
is parsed as
0xaa nd 1
which is not valid syntax.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue21
Changes by Eric V. Smith :
--
stage: -> resolved
___
Python tracker
<http://bugs.python.org/issue21979>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
To be more clear: the parser takes the longest token that could be valid. Since
"n" can't be part of a hex number, parsing stops there, returning "0xaa" as the
first token.
So:
>>> 0xaaif 1 else 0
Eric V. Smith added the comment:
Please respond to the other bug. No need to open a new bug when responding to
an existing issue. Thanks.
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
Eric V. Smith added the comment:
Looks fine to me. Normally I'd define the class being returned before the
function returning it, but it doesn't really make a difference.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
I agree that Decimal is wrong here. PEP 3101 says the result should include the
trailing '%'.
--
___
Python tracker
<http://bugs.python.o
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue2>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I think this would need to be implemented by adding bytes.__format__. I can't
think of a way to make it work on bytes-like objects in general.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
I'm not particularly wild about the .precision syntax either, but I think the
feature is generally useful.
Adding bytes.__format__ is exactly what "special output for bytes" _is_, as far
as format() is concerned.
Another option would be to inve
Eric V. Smith added the comment:
Can you explain why you want to subclass them?
--
nosy: +eric.smith
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issu
Eric V. Smith added the comment:
Changing to 3.5 only, as this is an API addition so it can only be added there.
I think that raising an exception instead of retuning None for a multicast
address would be a better API.
Any chance you can write some tests?
Thanks!
--
nosy
Eric V. Smith added the comment:
Where did you download the installer from?
How are you running the installer?
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue22
Eric V. Smith added the comment:
Is there some particular problem you're trying to solve, which this would make
easier?
Without a use case, I'm -1.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.o
Changes by Eric V. Smith :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22532>
___
___
Eric V. Smith added the comment:
No need to explain it. It sounds like it's not generally useful, so I'm still
-1.
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
Where are you seeing this?
On an Ubuntu 13.10 x86 box, I see:
>>> complex(-0.0)
(-0+0j)
This is with 2.7.5+, 3.3.2+ (from Ubuntu distro), and with 3.5.0a0 and
3.4.2rc1+ built locally.
--
___
Python track
Eric V. Smith added the comment:
No problem!
For completeness, I also see the correct behavior on cygwin 32-bit 2.7.3 and
3.2.3. I don't have access to a straight Windows version.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric V. Smith :
--
nosy: +eric.smith, mark.dickinson
___
Python tracker
<http://bugs.python.org/issue22546>
___
___
Python-bugs-list mailing list
Unsub
Eric V. Smith added the comment:
I think this is a result of changing the precision of str() to match repr().
2.7 prints:
'3.14159265359'
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
You've identified the main problem: would None go first or last? Modify your
key function to make the decision appropriate for you, returning either a very
small or very large value for None, as appropriate.
If you really want to see this behavior changed
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue22557>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
You might want to check out https://bitbucket.org/ctismer/namelesstuple, which
uses a similar approach.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue22
Eric V. Smith added the comment:
What platform is this on? Looking quickly through posix.execve (which is what I
think gets called), it looks like it just calls C's execve().
Also, what's your use case for this? I realize it might be a standard behavior,
but it seems like a bad
Eric V. Smith added the comment:
os.execvp calls os._execvpe which calls posix.execv which calls execv. At least
that's how I think it works.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
I know that. This is mostly just a note to myself so I can remember what I've
looked at the next time I have a few moments to look at the bug. Or, anyone
else who wants to track it down.
--
___
Python tracker
Eric V. Smith added the comment:
It seems to me that by giving it an __index__ method, you're saying it can be
used as an integer. It's not surprising to me that hex(), oct(), and bin()
would work with a Grade.F object. If anything, I'd say that more places should
use __index__
Eric V. Smith added the comment:
Yes, I think adding __index__ to d, i, o, u, U, and c is the correct thing to
do here.
--
___
Python tracker
<http://bugs.python.org/issue19
Eric V. Smith added the comment:
If you were going to make this change, I'd think you'd have to look for
__index__ and then __int__. But I'll admit I haven't thought through all of the
ramifications. It would be interesting to see wh
Eric V. Smith added the comment:
I'm not clear on this: is this a new feature you'd like to see, or is this
documented behavior of a DictReader that's not working?
If it's a new feature, the earliest it can be implemented is in 3.5.
Eric V. Smith added the comment:
My (poorly phrased) question really was: is resetting fieldnames documented to
force a re-read of the column headers? I don't see that it is, so I'm going to
call this a 3.5 enhancement request.
I agree with David that we can't change DictRe
Eric V. Smith added the comment:
Yes, looking through Objects/unicodeobject.c, 'u', 'i', and 'd' are treated the
same everywhere.
--
___
Python tracker
<
Eric V. Smith added the comment:
I think you want to either also testing the number of elements in t, or in just
compare t to (row["a"], row["b"]) (untested).
--
nosy: +eric.smith
___
Python tracker
<http://bug
Eric V. Smith added the comment:
While I think this is an improvement, I don't think we can make this change in
behavior at this stage in 3.4. Won't it have to go in 3.5?
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
I agree the behavior is bad and should be fixed. But it's a new feature that
will break existing code, and 3.4 is in beta, and therefore feature freeze.
Unfortunately, I think this has to go into 3.5, unless you can get Larry to
grant you an exce
Eric V. Smith added the comment:
See issue 7994 and issue 9856. This behavior has been deprecated for a while,
and is now an error.
--
assignee: -> eric.smith
resolution: -> invalid
status: open -> closed
___
Python track
Eric V. Smith added the comment:
Oops, I missed the "should be documented" part of your message. That's true,
and I'll leave this open. But I'll change it to a doc request and assign it
accordingly.
--
assignee: eric.smith -> docs@python
components: +Doc
Eric V. Smith added the comment:
This is no different from other places in python where white space is optional.
As long as the parser can tell the end of a token, there need not be white
space before the next token.
For example:
>>> 1+2
3
>>> 1 + 2
3
However, if the pars
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue20284>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I agree with Raymond: it would have been nice to do this, but it's too late.
Closing.
--
nosy: +eric.smith
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python
2201 - 2300 of 2699 matches
Mail list logo
