On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
Personally, if there's a bunch of push-back against just adding
TransformDict directly, why don't we make it provisional? I thought that
was what provisional was for (meaning: we're going to add it, PyPI is not
really
On Sat, Sep 14, 2013 at 02:25:42AM +0100, MRAB wrote:
On 14/09/2013 01:49, Steven D'Aprano wrote:
d = TransformDict(...)
for key in data:
key = d.get_canonical(key)
value = d[key]
print({}: {}.format(key, value))
I think must be missing something. I thought that iterating
On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
On 09/13/2013 05:49 PM, Steven D'Aprano wrote:
+1 on __transform__ method on dicts.
What would __transform__ do? Just canonicalize the key, or also save the
original key? How much front-end work will each user have to do
On Fri, Sep 13, 2013 at 06:40:06PM -0700, Ethan Furman wrote:
and if you wanted the transformed key you would apply the transform
function to the key.
Indeed. The question is: how? It is entirely possible that your function
has a TransformDict alone, and no memory of the transform
statistics.rst file.
I don't recall any other outstanding issues, if I have forgotten any,
please remind me.
On Fri, Sep 13, 2013 at 5:59 PM, Steven D'Aprano st...@pearwood.infowrote:
On Sun, Sep 08, 2013 at 10:51:57AM -0700, Guido van Rossum wrote:
Never mind, I found the patch and the issue. I
On Tue, Sep 17, 2013 at 02:21:16PM -0700, Guido van Rossum wrote:
Congrats, I've accepted the PEP. Nice work! Please work with the reviewers
on the issue on the code.
Thank you, and thanks to everyone who contributed with the discussion.
(Steven or Oscar, if either of you could work Oscar's
On Thu, Sep 19, 2013 at 01:54:08PM -0700, Ben Gift wrote:
I think the lambda keyword is difficult to understand for many people. It
would be more pythonic to use an empty def call instead.
Hi Ben, and welcome! Is this your first post? I'm afraid I don't
recognise your name.
I think this
Guys, this thread is not Python-Dev territory. It should have gone to
Python-Ideas. I repeat what I posted two days ago:
Proposals for changes to syntax and functionality are normally
expected to gather feedback on python-ideas before coming to
python-dev for final approval or
Hi all,
I have a question about how I should manage documentation for the
statistics module for Python 3.4. At the moment, I have extensive
docstrings in the module itself. I don't believe anyone has flagged that
as too much information in a code review, so I'm going to assume that
large
On Sun, Sep 22, 2013 at 10:20:46AM +0200, Antoine Pitrou wrote:
On Sun, 22 Sep 2013 13:13:04 +1000
Steven D'Aprano st...@pearwood.info wrote:
Hi all,
I have a question about how I should manage documentation for the
statistics module for Python 3.4. At the moment, I have extensive
On Sun, Sep 22, 2013 at 05:54:57AM -0700, Eli Bendersky wrote:
IMHO the right way to think about it is that the .rst files are by far the
more important documentation. Sometimes we forget that most Python
programmers are people who won't go into the source to read docstrings.
Docstrings are
On Sun, Sep 22, 2013 at 10:07:28AM -0700, Guido van Rossum wrote:
Authors writing 3rd party packages can do what they want.
But for the stdlib it's been settled for ages: docstrings should be concise
(but not cryptic(*)), longer documentation go into the separately written
text for
On Mon, Sep 23, 2013 at 07:53:00AM -0700, Guido van Rossum wrote:
there is no rule that because you can
access something on the class you should be able to access it on the
instance. Try asking an instance for its class's __mro__ or __bases__.
It might not be a rule, but it's certainly the
This is getting off-topic, if you're not interested in English grammar
you should stop reading.
On Mon, Sep 23, 2013 at 03:18:01PM -0400, Alexander Belopolsky wrote:
I don't think Returns bar. is a valid English sentence because it lacks
subject.
Subjectless sentences are unusual in
On Sun, Sep 29, 2013 at 08:51:37PM +0800, 张佩佩 wrote:
Hello:
As far as I know, there is not a language support user defined operator
overloading.
Python3 can overloading belowed operators.
[...]
(Do I miss something ?)
Yes, many.
On Sun, Sep 29, 2013 at 03:35:27PM -0400, Ned Batchelder wrote:
It isn't just a matter of a more complex parser: where would the parser
get the information about these new operators? The obvious first answer
is that they would be defined as part of classes, but that means the
operator
On Sat, Oct 05, 2013 at 01:27:37AM +0200, Victor Stinner wrote:
I have no idea of the price of renting a botnet, it's probably
expensive (and illegal as well).
Twelve cents per machine. Cheaper in bulk, and cheaper still for
machines outside of the US. For those on a budget, you can get ten
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
(If we cannot find a better name, we may add more specialized classes:
KeyInsensitiveDict and IdentiyDict. But I like the idea of using my
own transform function.)
-1 on a plethora of specialised dicts.
I do think that a
On Mon, Oct 07, 2013 at 02:55:44PM -0700, Ethan Furman wrote:
On 10/07/2013 02:24 PM, Steven D'Aprano wrote:
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote:
if type(self) is not dict:
# This only applies to subclasses, not dict itself.
try:
transform
On Mon, Oct 07, 2013 at 06:17:09PM -0700, Mark Janssen wrote:
Sorry I missed the original discussion, but isn't this a simple case
of putting a decorator around the getitem method (to transform the
input key) and a single line in the body of the setitem method, making
this very easy adaptation
On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote:
This PEP proposes a syntax for positional-only parameters in Python.
Positional-only parameters are parameters without an externally-usable
name; when a function accepting positional-only parameters is called,
positional
On Wed, Oct 09, 2013 at 12:20:18PM +0200, Antoine Pitrou wrote:
Hello,
Just noticed the following quirk:
type.__subclasses__()
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: descriptor '__subclasses__' of 'type' object needs an argument
Yet it would
On Wed, Oct 09, 2013 at 02:25:18PM -0400, Terry Reedy wrote:
Unlike Georg, I think '/' is plausibly ok. You should, however,
explicitly say in the PEP that it was selected not randomly but by rough
analogy. Division (/) is the inverse of multiplication (*), and
positional-only is sort of
On Wed, Oct 09, 2013 at 09:46:00PM +0100, Mark Shannon wrote:
There is no need to create an undefined value.
Rather than define a parameter by assigning a fake value, just don't
define it. We already do this for non-parameter locals and it could be
extended to parameters.
'range' would
On Wed, Oct 09, 2013 at 04:15:36PM +0200, Larry Hastings wrote:
- parameters in optional groups should just have an implied =None
that can be overriden if desired.
No no no! You can't have a default value, and you definitely couldn't
use None.
range() decides what its arguments mean
On Sat, Oct 12, 2013 at 10:48:41AM +0100, Paul Moore wrote:
On 12 October 2013 01:53, Victor Stinner victor.stin...@gmail.com wrote:
t's easy to mix up PEP numbers. For example, Martin von Loewis wrote
two major PEP related to Unicode: 383 and 393. These numbers are
close, only one digit is
On Tue, Oct 15, 2013 at 10:20:03AM +0200, Victor Stinner wrote:
Both issues are related and should be fixed in the *same* commit.
Python should provide an option to encode explicitly filenames to
UTF-8. Or maybe better: encode to UTF-8 by default, with an option to
encode to cp437, and another
On Wed, Oct 16, 2013 at 09:24:11AM +1000, Nick Coghlan wrote:
Even though it eventually
convinced me to change the name, this thread still epitomises everything
that sucks about soul destroying, energy draining bikeshed painting that
makes me wonder why I ever bother trying to make anything
Hi Hakril,
I think this question is probably off-topic for this list. This list is
for development of the Python compiler, not for development with Python,
and questions like this should probably go to python-l...@python.org
(also mirrored as comp.lang.python if you have Usenet access). But I
On Mon, Nov 04, 2013 at 08:47:53PM +, John Klos wrote:
[...]
The short answer is to skip those tests on VAXen. The better answer is to
patch any isnan functions to always return false on VAXen and patch any
code which tries to parse, for instance, float(NaN) to use something
uncommon,
On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
http://bugs.python.org/issue19332
Duplicate of this: http://bugs.python.org/issue6017
The conclusion on that also was that it is not worth guarding against
such an unusual circumstance.
--
Steven
On Wed, Nov 06, 2013 at 11:32:33PM +0100, Victor Stinner wrote:
Hi,
I'm trying to avoid unnecessary temporary Unicode strings when
possible (see issue #19512). While working on this, I saw that Python
likes preparing an user friendly message to explain why getting an
attribute failed. The
On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote:
I now gave up on sandboxing Python. I just would like to warn other
core developers that trying to put a sandbox in Python is not a good
idea :-)
Do you mean CPython?
Do you think it would be productive to create an independent
On Thu, Nov 14, 2013 at 04:55:19PM -0500, Tres Seaver wrote:
Fixing any bug is changing behavior; 2.7 is not frozen for bugfixes.
It's not a given that the current behaviour *is* a bug. Exception
messages in 2 are byte-strings, not Unicode. Trying to use Unicode
instead is not, as far as I
On Thu, Nov 14, 2013 at 09:09:06PM -0500, Terry Reedy wrote:
1.5 was around for a long time; not sure if it is completely gone yet.
It's not. I forget the details, but after the last American PyCon,
somebody posted a message about a fellow they met who was still using
1.5 in production.
--
On Thu, Nov 14, 2013 at 04:02:17PM -0800, Chris Barker wrote:
On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver tsea...@palladion.com wrote:
Fixing any bug is changing behavior; 2.7 is not frozen for bugfixes.
Thank you.
The real question is whether third-party code will break when the
On Fri, Nov 15, 2013 at 02:28:48PM +1100, Cameron Simpson wrote:
Non-ascii Unicode strings are just a special case of the more general
problem of what to do if printing the exception raises. If
str(exception.message) raises, suppressing the message seems like a
perfectly reasonable
On Fri, Nov 15, 2013 at 05:13:34PM +1000, Nick Coghlan wrote:
A few things I noticed while implementing the recent updates:
- as you noted in your other email, while MAL is on record as saying
the codecs module is intended for arbitrary codecs, not just Unicode
encodings, readers of the
On Fri, Nov 15, 2013 at 10:22:28AM +0100, Antoine Pitrou wrote:
On Fri, 15 Nov 2013 09:03:37 +1000 Nick Coghlan ncogh...@gmail.com wrote:
And add transform() and untransform() methods to bytes and str types.
In practice, it might be same codecs registry for all codecs just with
a new
On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote:
I agree that conflating the two doesn't help the discussion.
While removing docstrings may be beneficial on memory-constrained
devices, I can't remember a single situation where I've wanted to
remove asserts on a production
On Sun, Nov 17, 2013 at 01:50:31AM +1000, Nick Coghlan wrote:
No, that's the wrong question to ask. The onus is on *you* to ask Who
is this feature for? Do they still need it? Can we meet their needs in
a different way?. You're the one proposing to break things, so it's
up to you to make the
On Sat, Nov 16, 2013 at 11:16:48AM -0500, Donald Stufft wrote:
Personally I think that none of the -O* should be removing asserts. It feels
like a foot gun to me. I’ve seen more than one codebase that would be
completely broken under -O* because they used asserts without even knowing
-O*
On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote:
On Sun, 17 Nov 2013 18:04:43 +1100
Steven D'Aprano st...@pearwood.info wrote:
On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote:
I agree that conflating the two doesn't help the discussion.
While removing
On Sun, Nov 17, 2013 at 11:35:21AM +0100, Antoine Pitrou wrote:
You didn't answer my question: did you actually use -OO in production,
or not? Saying that -OO could have helped you optimize something you
didn't care about isn't a very strong argument for -OO :)
Ah, sorry, I misunderstood your
On Tue, Nov 19, 2013 at 05:28:48PM -0800, Jim J. Jewett wrote:
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
Serhiy Storchaka wrote:
If the transform() method will be added, I prefer to have only
one transformation method and specify a direction by the
On Fri, Nov 29, 2013 at 03:25:14PM +, Kristján Valur Jónsson wrote
about the PEP process:
How about acknowledging that these waters are dark and murky and help
making things better?
Well, how about? If Anatoly has a concrete proposal, surely he can propose a
patch to make things
On Fri, Dec 06, 2013 at 07:28:57AM +0100, Gregory Salvan wrote:
Hi,
maybe a syntax like that can correspond:
class MyObject(metaclass=ObjectSpec):
''' MyObject doc'''
'attr1 contains something'
attr1 = None
'attr2 contains something'
attr2 = str
'method1 do
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
Oh, yes, a %T shortcut for length limited type name of the supplied
object would be brilliant. We need this frequently for C level error
messages, and I almost always have to look at an existing example to
remember the exact
On Mon, Dec 16, 2013 at 07:30:56AM +1000, Nick Coghlan wrote:
On 16 Dec 2013 02:58, Ethan Furman et...@stoneleaf.us wrote:
On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
Oh, yes, a %T shortcut for length limited type name
On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg drsali...@gmail.com wrote:
So far the results are looking good for 3.x.
Python-dev probably is a bit special.
Why? Most Python-Dev people have day jobs, and the version of Python
On Thu, Jan 09, 2014 at 05:11:06PM +1000, Nick Coghlan wrote:
On 9 January 2014 10:07, Ben Finney ben+pyt...@benfinney.id.au wrote:
So, if what you want is to parse text and not get gibberish, you need to
*tell* Python what the encoding is. That's a brute fact of the world of
text in
On Thu, Jan 09, 2014 at 01:00:59PM +, Kristján Valur Jónsson wrote:
Which reminds me, can Python3 read text files with BOM automatically yet?
I'm not sure what you mean by that. If you mean, can Python3 distinguish
between UTF-16BE and UTF-16LE on the basis of a BOM, then it's been able
On Thu, Jan 09, 2014 at 02:08:57PM -0800, Ethan Furman wrote:
If latin1 is used to convert binary to text, how convoluted is it to then
take chunks of that text and convert to int, or some other variety of
unicode?
For example: b'\x01\x00\xd1\x80\xd1\83\xd0\x80'
If that were decoded
On Fri, Jan 10, 2014 at 12:22:02PM +1100, Chris Angelico wrote:
On Fri, Jan 10, 2014 at 11:53 AM, anatoly techtonik techto...@gmail.com
wrote:
2. introduce autodetect mode to open functions
1. read and transform on the fly, maintaining a buffer that
stores original bytes
On Fri, Jan 10, 2014 at 06:17:02PM +0100, Juraj Sukop wrote:
As you may know, PDF operates over bytes and an integer or floating-point
number is written down as-is, for example 100 or 1.23.
I'm sorry, I don't understand what you mean here. I'm honestly not
trying to be difficult, but you
On Sat, Jan 11, 2014 at 01:56:56PM +0100, Juraj Sukop wrote:
On Sat, Jan 11, 2014 at 6:36 AM, Steven D'Aprano st...@pearwood.infowrote:
If you consider PDF as binary with occasional pieces of ASCII text, then
working with bytes makes sense. But I wonder whether it might be better
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
On 01/11/2014 07:38 AM, Steven D'Aprano wrote:
The point that I am making is that many people want to add formatting
operations to bytes so they can put ASCII strings inside bytes. But (as
far as I can tell) they don't need to do
On Sat, Jan 11, 2014 at 04:15:35PM +0100, M.-A. Lemburg wrote:
I think we need to step back a little from the purist view
of things and give more emphasis on the practicality beats
purity Zen.
I complete agree with Stephen, that bytes are in fact often
an encoding of text. If that text is
On Sat, Jan 11, 2014 at 05:33:17PM +0100, M.-A. Lemburg wrote:
FWIW: I quite liked the Python 2 model, but perhaps that's because
I already knww how Unicode works, so could use it to make my
life easier ;-)
/incredulous
I would really love to see you justify that claim. How do you use the
On Sat, Jan 11, 2014 at 07:22:30PM +, MRAB wrote:
with open(outfile.pdf, w, encoding=latin-1) as f:
f.write(pdf)
[snip]
The second example won't work because you're forgetting about the
handling of line endings in text mode.
So I did! Thank you for the correction.
--
Steven
On Sat, Jan 11, 2014 at 04:28:34PM -0500, Terry Reedy wrote:
The problem with some criticisms of using 'unicode in Python 3' is that
there really is no such thing. Unicode in 3.0 to 3.2 used the old
internal model inherited from 2.x. Unicode in 3.3+ uses a different
internal model that is
On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
AFAIK (and just for the record), there could be both Latin1 text and UTF-16
in a PDF (and other encodings too), depending on the font used:
[...]
In Python2, txt is just a str, but in Python3 handling everything as latin1
On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote:
On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano st...@pearwood.infowrote:
On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
AFAIK (and just for the record), there could be both Latin1 text and
UTF-16
On Sun, Jan 12, 2014 at 11:16:37PM +1000, Nick Coghlan wrote:
content = '\n'.join([
'header',
'part 2 %.3f' % number,
binary_image_data.decode('latin-1'),
utf16_string.encode('utf-16be').decode('latin-1'),
'trailer']).encode('latin-1')
On Mon, Jan 13, 2014 at 07:31:16AM +0900, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
then the name is horribly misleading, and it is best handled like this:
content = '\n'.join([
'header',
'part 2 %.3f' % number,
binary_image_data.decode
wrote:
On 01/11/2014 06:29 PM, Steven D'Aprano wrote:
[...]
Since you're talking to me, it would be nice if you addressed the same
use-case I was addressing, which is mixed: ascii-encoded text,
ascii-encoded numbers, ascii-encoded bools, binary-encoded numbers, and
misc-encoded text.
I
On Mon, Jan 13, 2014 at 01:03:15PM +1100, Steven D'Aprano wrote:
code speaks louder than words: http://www.pearwood.info/ethan_demo.py
[...]
Ethan refers to code like:
template % (срЃ.encode('cp1251').decode('latin-1'), 42,
blob.decode('latin-1'))
You did say to use a *text* template
On Mon, Jan 13, 2014 at 07:58:43PM -0500, Terry Reedy wrote:
This discussion strikes me as more appropriate for python-ideas. That
said, I am leery of a heuristics module in the stdlib. When is a change
a 'bug fix'? and when is it an 'enhancement'?
Depends on the nature of the heuristic.
On Tue, Jan 14, 2014 at 10:58:49AM -0500, R. David Murray wrote:
On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman et...@stoneleaf.us wrote:
Has anyone actually used __bytes__ yet? What for?
bytes(email.message.Message()) returns the message object serialized to
wire format.
--David
On Tue, Jan 14, 2014 at 10:16:17AM -0800, Guido van Rossum wrote:
Hm. It is beginning to sound more and more flawed. I also worry that
it will bring back the nightmare of data-dependent UnicodeError back.
E.g. this (from tests/basic.py):
def
On Wed, Jan 15, 2014 at 01:03:13PM +1300, Greg Ewing wrote:
Nick Coghlan wrote:
That way lies the Python 2 text model, and we're not going there. It's
probably best to think of asciistr as a way of demonstrating a
rhetorical point about the superiority of the Python 3 text model
Hmmm...
On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote:
Neil Schemenauer wrote:
Objects that implement __str__ can also implement __bytes__ if they
can guarantee that ASCII characters are always returned,
I think __ascii_ would be a better name. I'd expect
a method called __bytes__ on
On Wed, Jan 15, 2014 at 09:25:04AM -0500, Eric V. Smith wrote:
On 1/15/2014 8:21 AM, Chris Angelico wrote:
On Wed, Jan 15, 2014 at 11:22 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
I don't think that it is possible to write an interpreter that is fully
compatible for all it accepts.
On Wed, Jan 15, 2014 at 10:34:48PM +, Mark Lawrence wrote:
On 15/01/2014 22:22, Brett Cannon wrote:
On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano st...@pearwood.info
mailto:st...@pearwood.info wrote:
On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote:
Neil
On Wed, Jan 15, 2014 at 05:46:07PM -0800, Glenn Linderman wrote:
On 1/15/2014 4:03 PM, Steven D'Aprano wrote:
What precisely does it do? If it's so obvious, why is this thread so
long?
It produces a formatted representation of the object in bytes. For
numbers, that would probably
On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote:
Meta enough that I'll take Guido out of the CC.
Nick Coghlan writes:
There are plenty of data formats (like SMTP and HTTP) that are
constrained to be ASCII compatible,
ASCII compatible is a technical term in
On Thu, Jan 16, 2014 at 08:23:13AM -0800, Ethan Furman wrote:
As I understand it, str.format will call the object's __format__. So, for
example, if I say:
u'the value is: %d' % myNum(17)
then it will be myNum.__format__ that gets called, not int.__format__;
I seem to have missed
On Thu, Jan 16, 2014 at 01:08:47PM -0800, Ryan Smith-Roberts wrote:
socket.getservbyname(servicename[, protocolname])
This is not an inspectable signature, since pure Python does not support
bracketed arguments. To make it inspectable, we must give protocolname a
(valid Python) default
On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
Overriding Principles
=
In order to avoid the problems of auto-conversion and Unicode exceptions
that
could plague Py2 code, all object checking will be done by duck-typing, not
by
values contained in a
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
Numeric Format Codes
To properly handle int and float subclasses, int(), index(), and float()
will be called on the objects intended for (d, i, u), (b, o, x, X
On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote:
In this specific case, our general communication about the different
purposes of the core lists *isn't* particularly good,
Nick, I beg to differ: I think that our communication in this regard
actually is quite reasonable. Before
On Fri, Jan 24, 2014 at 08:07:43PM -0800, Larry Hastings wrote:
(Quick, because apparently nobody reads the long ones!)
In Python 3.3:
class C:
...def foo(self, a): pass
...
c = C()
help(c.foo)
shows you the signature foo(self, a).
That matches the
On Sun, Jan 26, 2014 at 11:40:33PM -0500, Alexander Belopolsky wrote:
I would say no fix is needed for this doc because the signature suggests
(correctly) that passing times by keyword is not supported.
How do you determine that? Passing times by keyword works in Python 3.3:
py from itertools
On Mon, Jan 27, 2014 at 04:29:04AM -0800, Larry Hastings wrote:
The code currently has semantics that cannot be accurately represented
in a Python signature. We could do one of three things:
1) Do nothing, and don't allow inspect.Signature to produce a signature
for the function. This
On Mon, Jan 27, 2014 at 10:06:57PM -0800, Larry Hastings wrote:
If I were writing it, it might well come out like this:
[snip example]
+1 on this wording, with one minor caveat:
.. note: if times is specified using a keyword argument, and
provided with a negative value, repeat yields
On Fri, Jan 31, 2014 at 07:23:52PM -0800, Larry Hastings wrote:
Python is the language that cares about backwards-compatibility--bugs
and all. If your code runs on version X.Y, it should run without
modification on version X.(Y+Z) where Z is a positive integer.
Therefore it would be
On Sat, Feb 01, 2014 at 10:20:24PM +1000, Nick Coghlan wrote:
On 1 February 2014 16:04, Ethan Furman et...@stoneleaf.us wrote:
So we only fix bugs that don't work at all? By which I mean, if the
interpreter doesn't crash, we don't fix it?
No, we make a judgment call based on the severity
Hi all,
Over on the Python-ideas list, there's a thread about the new statistics
module, and as the author of that module, I'm looking for a bit of
guidance regarding backwards compatibility. Specifically two issues:
(1) With numeric code, what happens if the module become more[1]
accurate
On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote:
Eli Bendersky wrote:
For instance, it is sometime non-trivial to know which exceptions some
function may throw. When you write a try...raise statement, you think
hard about covering all the bases. In an expression you're unlikely
On Fri, Feb 21, 2014 at 04:42:36PM -0800, Ethan Furman wrote:
This is not just about better handling of [missing] default values, but of
better exception handling. This PEP adds the ability to use a scalpel
instead of a sledge hammer.
Beautifully said!
--
Steven
On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote:
Inconvenience of dict[] raising KeyError was solved by
introducing the dict.get() method. And I think that
dct.get('a', 'b')
is 1000 times better than
dct['a'] except KeyError: 'b'
I don't think it is better. I think that
On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote:
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico ros...@gmail.com wrote:
+Had this facility existed early in Python's history, there would have been
+no need to create dict.get() and related methods;
FWIW, after
On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote:
[...]
So can we please try to stop scheduling another major Python version
breaking almost all modules and all applications just to be pendantic?
No, we should not remove any old feature in Python 4. Python 4 should
be just a
On Thu, Mar 13, 2014 at 07:54:18AM +1100, Chris Angelico wrote:
On Thu, Mar 13, 2014 at 7:26 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I think you (or someone) first needs to find a BDFL delegate.
Traditionally, with syntax changes, there is a good chance that Guido
doesn't want to
anatoly techtonik wrote:
On Wed, Jul 4, 2012 at 9:31 PM, Terry Reedy tjre...@udel.edu wrote:
A sliding window for a generic iterable requires a deque or ring buffer
approach that is quite different from the zip-longest -- grouper approach.
That's why I'd like to drastically reduce the scope
anatoly techtonik wrote:
Which is the 33th most voted Python question on SO -
http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464
I am curious how you get that number. I do note that there are about 15
other Python SO questions that seem
Nick Coghlan wrote:
On Sun, Jul 15, 2012 at 9:18 AM, Benjamin Peterson benja...@python.org wrote:
Open questions
==
There are two open questions for this PEP:
* Should ``list`` expose a kwarg in it's constructor for supplying a length
hint.
* Should a function be added either to
Antoine Pitrou wrote:
The point is that 0 is a legitimate value for a length hint. Simple
implementations of __length_hint__ will start returning 0 as a
legitimate value and you will wrongly interpret that as don't know,
which kinds of defeat the purpose of __length-hint__ ;)
That said, I
Mark Shannon wrote:
So how does an iterator express infinite length?
The suggestion was it should return -1.
What should happen if I am silly enough to do this:
list(itertools.count())
This will fail; it should fail quickly.
That depends on your OS. I've just tested it now on Linux
Antoine Pitrou wrote:
First, you can't implement __length_hint__ for a generator, which is the
preferred (the most practical) way of writing iterators in pure Python.
Limitations of generators are no reason for not improving iterators which are
not generators. __length_hint__ already exists;
401 - 500 of 1505 matches
Mail list logo
