On Thu, Sep 09, 2021 at 12:29:46AM +0100, Rob Cliffe via Python-Dev wrote:
> Why not byte() ?
Too easy to typo it as bytes().
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
On Tue, Sep 14, 2021 at 12:33:32PM -0700, Guido van Rossum wrote:
> My view of this is:
>
> A. It's not an iterator if it doesn't define `__next__`.
>
> B. It is strongly recommended that iterators also define `__iter__`.
>
> In "standards" language, I think (A) is MUST and (B) is merely OUGHT o
If it helps, I have tons of code that tests for iterators using:
iter(obj) is obj
That has been a documented requirement for the iterator protocol
forever. Its in the PEP.
"A class that wants to be an iterator should implement two methods: a
next() method that behaves as described above, a
On Tue, Sep 14, 2021 at 09:38:38PM -0700, Guido van Rossum wrote:
> > I don't know what I would call an object that only has __next__,
> > apart from "broken" :-(
> >
>
> It's still an iterator, since it duck-types in most cases where an iterator
> is required (notably "for", which is the primary
On Tue, Sep 14, 2021 at 04:50:05PM -0700, Guido van Rossum wrote:
> TBH I don't think there is an *actual* problem here. I think it's just
> about choosing the right wording for the glossary (which IMO does not have
> status as a source of truth anyway).
+1
--
Steve
___
On Wed, Sep 15, 2021 at 08:57:58AM -0700, Guido van Rossum wrote:
[...]
> Yes, we all understand that. The reason I invoked "duck typing" is that as
> long as you don't use the iterator in a situation where iter() is called on
> it, it works fine. Just like a class with a readline() method works f
On Wed, Sep 15, 2021 at 04:01:31PM -0700, Guido van Rossum wrote:
> Steven's class A is the kind of class a custom sequence might return from
> its __iter__ method. E.g.
>
> class S:
> def __iter__(self):
> return A()
Correct, where A itself has a `__next__` method but no `__iter__`
On Sun, Sep 26, 2021 at 01:14:18AM +0200, jack.jan...@cwi.nl wrote:
> I’m getting increasingly worried about the future of Python,
That Python will become even more popular?
TIOBE: second place, 0.16% below C.
PYPL: first place, 12.3% above Java.
RedMonk: equal second with Java.
https://www.t
On Sun, Oct 03, 2021 at 04:47:57PM +0100, Irit Katriel via Python-Dev wrote:
> We wonder if people have a view on which of the following is clearer/better:
>
> 1. except *E as e: // except *(E1, E2) as e:
That looks like you're unpacking the tuple (E1, E2), and that's just
misleading and wrong
On Sun, Oct 03, 2021 at 11:34:55AM -0700, Guido van Rossum wrote:
> I also think that the bar should be pretty high before we reopen the
> *syntax* -- the PEP was approved without anyone (neither the SC, nor
> Nathaniel, nor anyone else) providing any feedback on the use of 'except
> *'. So I thin
On Mon, Oct 04, 2021 at 09:03:54AM -0700, Guido van Rossum wrote:
> The question was about which style to *recommend* (a la PEP-8).
Quote:
"At the moment * is a separate token so both are allowed, but we could
change that (e.g., make except* a token)"
If that is mistaken, that's fine, no harm d
On Mon, Oct 04, 2021 at 07:31:10PM +0100, Steve Dower wrote:
> To me, the "*name" looks most similar to how we write "*args" in a
> function definition, so I'd go for that.
That's exactly why we *shouldn't* go for that option. That is going to
confuse a lot of people that it is sequence unpackin
On Tue, Oct 05, 2021 at 11:17:25AM -0400, Calvin Spealman wrote:
> On Tue, Oct 5, 2021 at 10:51 AM Patrick Reader <_...@pxeger.com> wrote:
>
> > On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote:
> >
> > 1. except *E as e: // except *(E1, E2) as e:
> > 2. except* E as e: // except* (E1, E
Hi Sam,
On Thu, Oct 07, 2021 at 03:52:56PM -0400, Sam Gross wrote:
> I've been working on changes to CPython to allow it to run without the
> global interpreter lock. I'd like to share a working proof-of-concept that
> can run without the GIL.
Getting Python to run without the GIL has never been
On 16/02/13 16:41, Stefan Behnel wrote:
PyPy is indeed a work in progress in this area, but that doesn't
necessarily preclude it from being included.
That may be a matter of POV, but as long as PyPy fails to integrate (and
you just called that "not a main focus"), I find it hard to defend its
On 20/02/13 11:54, Fred Drake wrote:
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft wrote:
Let's not add anything to the stdlib till it has real world usage. Doing
otherwise is putting the cart before the horse.
I'd posit that anything successful will no longer need to be added to
the standar
On 21/02/13 10:22, Antoine Pitrou wrote:
On Wed, 20 Feb 2013 18:21:22 -0500
Donald Stufft wrote:
On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A
single 1 kB XML document can kill virtually any machine, eve
On 28/02/13 07:20, anatoly techtonik wrote:
* as an exercise - try to build a scroller for a running Python script
* it is impossible for Python 2 and probably for Python 3 as well
What do you mean by "a scroller"?
[...]
and why PSF doesn't comply the 4. Redistribution clause fr
On 28/02/13 23:26, Stefan Krah wrote:
Jesse Noller wrote:
We have one: p...@python.org
That's not exactly a public mailing-list.
Nope. But it's also where lawyers flock and these issues can rapidly be
resolved.
If the list isn't publicly archived, the same questions will arise over
and o
On 05/03/13 09:08, Brett Cannon wrote:
Depends on your paranoia. If you're worried about accidentally lifting IP
merely by reading someone's source code, then you wouldn't want to touch
code without the CLA signed.
Now I'm not that paranoid, but I'm still not about to commit someone's code
now
On 02/03/13 02:43, Demian Brecht wrote:
Cross-posting from python-ideas due to no response there. Perhaps it's
due to a general lack of usage/caring for cookiejar, but figured
/someone/'s got to have an opinion about my proposal ;)
Apparently not :-(
TL;DR: CookieJar > FileCookieJar > *Cooki
On 19/03/13 00:50, Neal Becker wrote:
def F(x):
return x
x = 2
F(x) = 3
F(x) = 3
SyntaxError: can't assign to function call
Do we really need this restriction? There do exist other languages without it.
What meaning would you give to "F(x) = 3", and why?
--
Steven
On 19/03/13 02:01, Hrvoje Niksic wrote:
On 03/18/2013 03:23 PM, Chris Angelico wrote:
The languages that permit you to assign to a function call all have
some notion of a reference type.
Assigning to function calls is orthogonal to reference types. For example,
Python manages assignment to s
On 21/03/13 11:15, Terry Reedy wrote:
getting back to CP versus IDLE...
From IDLE:
print('\x80')
print('\xc8')
È
Impressed? You should be. Open Start menu / Python33 / Python (command line)
and both of those result (modulo the specific character) in
UnicodeEncodeError: 'charmap' cod
On 03/04/13 23:47, Hrvoje Niksic wrote:
On 04/03/2013 01:17 PM, Nick Coghlan wrote:
> > >
> > I like Nick's answer to that: int *should* always return something of
> > exact type int. Otherwise you're always left wondering whether you
> > have to do "int(int(x))", or perhaps even "int(int(i
On 04/04/13 01:16, Barry Warsaw wrote:
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's intimately tied
to int(),
On 04/04/13 03:36, Guido van Rossum wrote:
Consider a subclass of int() that overrides __repr__() and __str__() to
print something fancy (maybe it defaults to hex; maybe it's an enum :-). I
want to be able to say repr(int(x)) and get the standard decimal
representation. Same with strings. If int
On 04/04/13 09:07, Cameron Simpson wrote:
On 03Apr2013 14:47, Hrvoje Niksic wrote:
| On 04/03/2013 01:17 PM, Nick Coghlan wrote:
| Why would one want to be absolutely sure of getting an int?
So that arithmetic can be relied upon? If a subclass can override
the add methods etc it can look like a
On 05/04/13 01:23, Oscar Benjamin wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached to the resulting object.
When I call int(), I'm expecting an int. That includes well-be
On 07/04/13 17:44, mar...@v.loewis.de wrote:
Martin, you guys are shooting yourself in a foot. Almost noone uses
python 3 in production, even at pycon, which is the more progressive
crowd. There is a giant group of people using python that are not as
vocal. While I bet some are using Python 3, Py
On 07/04/13 17:52, Maciej Fijalkowski wrote:
If they never migrate on the premises of python 3 being a better
language what does it say about python 3?
Very little. People stick with languages for all sorts of reasons,
including:
- It's what I know
- I don't like change
- That's what the clien
On 08/04/13 07:41, Barry Warsaw wrote:
I talked to someone at Pycon who was still using Python 1.5, which is probably
older than some of the people on this list ;).
Awesome! :-)
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On 13/04/13 08:58, Christian Tismer wrote:
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
[...]
Where would I add such a complaint, usually?
Or should I simply fix it?
It's a wiki. You can fix it yourself, next
On 13/04/13 05:33, Barry Warsaw wrote:
On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
I, too, would strongly prefer to see ordering within an enum. I use
home-made enums heavily in my code and find ordering comparisons useful
there.
This was all hashed out in gory detail on python-ideas
On 13/04/13 10:13, Glenn Linderman wrote:
can't define two names in the same enum to have the same value, per the PEP.
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
On 13/04/13 20:30, Ben Finney wrote:
"Stephen J. Turnbull" writes:
Mark Lawrence writes:
> People already use the bug tracker as an excuse not to contribute,
> wouldn't this requirement make the situation worse?
A failure to sign the CLA is already a decision not to contribute to
the dis
On 21/04/13 05:42, Barry Warsaw wrote:
On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
wasp = 1 #
On 21/04/13 15:33, Nick Coghlan wrote:
The PEP is fine, as it already allows duplicate names without encouraging them:
class Insect(Enum):
wasp = 1 # Preferred. Use this in new code.
bee = 2
ant = 3
# Backwards compatibility aliases
Insect.wsap = Insec
On 23/04/13 09:16, Greg Ewing wrote:
Victor Stinner wrote:
The last proposition is to add transform() and untransform() methods
to bytes and str types. ... If I remember
correctly, the missing point is how to define which types are
supported by a codec
Also, for any given codec, which directio
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more,
or less, strange than str('spam') or int(1) or list([]). Why
would you do that?
But as soon as you think of it in general terms:
some_
On 26/04/13 13:22, Greg wrote:
On 26/04/2013 3:12 p.m., Glenn Linderman wrote:
On 4/25/2013 7:49 PM, Nick Coghlan wrote:
You couldn't create an enum of callables, but that would be a
seriously weird thing to do anyway
But aren't all classes callable?
An enum of classes would be seriou
On 26/04/13 18:00, Greg Ewing wrote:
However, there's a worse problem with defining enum
inheritance that way. The subtype relation for extensible
enums works the opposite way to that of classes.
To see this, imagine a function expecting something
of type Colors. It knows what to do with red, g
On 27/04/13 12:51, Ethan Furman wrote:
On 04/26/2013 07:29 PM, Glenn Linderman wrote:
[...]
class Color( Enum ):
Enum.__enumerationItems__(
red=1,
green=2,
blue=3,
)
# other methods and assignments
Or, if we go with the metaclass magic
On 29/04/13 06:02, Guido van Rossum wrote:
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
Definite Issues:
- should enum items be of the type of the Enum class? (i.e. type(SPRING)
is Seasons)
IMO Yes.
+1
- should an enum item be selectable via __call__
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is even an issu
On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:
> Two examples:
>
> - the first few integers (up to 256 now, I think) are pre-created by the
> interpreter; when you do `int('7')` you are not getting a brand-new, never
> before used, integer 7 object, you're getting a cached in
On Sun, Apr 28, 2013 at 11:50:16PM -0700, Ethan Furman wrote:
> In other words, currently:
>
> class Color(Enum):
> red = 1
> green = 2
> blue = 3
>
> class MoreColor(Color):
> cyan = 4
> magenta = 5
> yellow = 6
> black = 7
>
> MoreColor.red is C
On 30/04/13 02:42, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky wrote:
I don't feel strongly about allowing ()-lookup in addition to []-lookup, but
in this paragraph the issue of multiple definitions has sneaked in :-)
flufl.enum disallows this:
class Color(Enum):
On 30/04/13 03:01, Guido van Rossum wrote:
Oh dear, this is actually a mess. I don't want MoreColor.red and
Color.red to be distinct objects, but then the isinstance() checks
will become confusing. If we don't override isinstance(), we'll get
not isinstance(Color.red, MoreColor)
isinstanc
On 30/04/13 04:29, Guido van Rossum wrote:
You are too verbose. I have already said what I needed to say.
Sorry about that, sometimes I do go on and on. Let me be more terse.
When it comes to enums, I believe that violating Liskov is a feature, not a bug.
Also, I understand that both Scala an
On 30/04/13 05:02, MRAB wrote:
Why is that backwards? MoreColor is a subclass of Color, so instances
of MoreColor are instances of Color, but instances of Color are not
instances of MoreColor. That's normal behaviour for subclasses. (All
cats are mammals, but not all mammals are cats.)
Let's s
On Mon, Apr 29, 2013 at 03:50:22PM -0700, Ethan Furman wrote:
> This just doesn't make sense to me:
>
> --> class Stuff(Enum):
> ... blue = 1
> ... china = 'really big country'
> ... random = (8273.199, 517)
>
> --> Stuff.blue.name == 'blue'
> --> Stuff.blue.value == 1
>
> --> Stuff.
On Tue, Apr 30, 2013 at 10:15:58AM +0100, Paul Moore wrote:
> Before I raise a bug for this, can someone confirm if I've simply missed
> something? I don't see any way, either in the docs or in the helpstrings
> from the codecs, of listing the codecs that have been registered.
>
> FWIW, I picked t
On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote:
> Latest code available at https://bitbucket.org/stoneleaf/aenum.
>
> --> class Color(Enum):
> ... red = 1
> ... green = 2
> ... blue = 3
Ethan, you seem to be writing a completely new PEP in opposition to
Barry's PEP 435.
On 02/05/13 01:09, Ethan Furman wrote:
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
Apparently I have to log in before I can even see the repo.
Not going to happen.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.or
On 02/05/13 08:54, Nick Coghlan wrote:
If enums had an "as_dict" method that returned an ordered dictionary, you
could do:
class MoreColors(Enum):
locals().update(Colors.as_dict())
Surely that is an implementation-specific piece of code? Writing to locals()
is not guaranteed to work, an
On 02/05/13 06:45, Antoine Pitrou wrote:
I was talking in the context where subclassing is allowed. I don't
think there's a use-case for subclassing of non-empty enums. On the
other hand, empty enums should probably allow subclassing (they are
"abstract base enums", in a way).
If you google fo
On 02/05/13 02:43, Guido van Rossum wrote:
Here's how I would implement "extending" an enum if subclassing were
not allowed:
class Color(Enum):
red = 1
white = 2
blue = 3
class ExtraColor(Enum):
orange = 4
yellow = 5
green = 6
flag_colors = set(Color) | set(ExtraColor)
Now
On 03/05/13 11:29, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and I'd like to make the current
CPython behaviour part of the language/library specificat
On 03/05/13 18:42, Antoine Pitrou wrote:
Le Fri, 3 May 2013 09:14:22 +1000,
Nick Coghlan a écrit :
I would suggest moving the field names into the class header for a
class based convenience API:
class Animal(Enum, members='cat dog'): pass
This looks good to me (assuming some people don't l
On 03/05/13 20:37, Paul Moore wrote:
On 2 April 2013 01:47, Daniel Holth wrote:
This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP Applications”
and “Windowed Python ZIP Applications”, and providing some simple
tooling t
On 04/05/13 15:13, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> > Rather than risk obscure bugs, I would suggest restricting the extensions
> > to 3 characters. For the “Windowed Python ZIP Applications” case, could we
> > use .pzw as the extension instead
On 05/05/13 20:05, Antoine Pitrou wrote:
I still would like to see Nick's class-based API preferred over the
functional API:
class Season(Enum, members='spring summer autumn'):
pass
-1
As already mentioned, this is no substitute for the functional API as it is a
statement, not an
On 06/05/13 03:07, Charles-François Natali wrote:
I'm chiming in late, but am I the only one who's really bothered by the syntax?
class Color(Enum):
red = 1
green = 2
blue = 3
I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases,
On 07/05/13 23:34, Eli Bendersky wrote:
One of the contended issues with PEP 435 on which Guido pronounced was the
functional API, that allows created enumerations dynamically in a manner
similar to namedtuple:
Color = Enum('Color', 'red blue green')
The biggest complaint reported against th
On 08/05/13 21:31, Alok Nayak wrote:
I asked this question here,
http://stackoverflow.com/questions/16435233/this-python-string-literals-documentation-couldnt-explain-me-single-quote-pres,
. I was advised to ask here
They were wrong. It is not relevant here, since it is not a question about
d
On 14/05/13 16:51, Gregory P. Smith wrote:
[...]
This sounds like a feature request for doctest. doctest could be educated
about enums and automatically compare to the integer value for such cases.
Please no. Enums are not special enough to break the rules.
Good: "Doctests look at the object'
On 20/05/13 09:27, Gregory P. Smith wrote:
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
Bad: doctests.
I'm hoping that core developers don't get caught-up in the "doctests are
bad meme".
So
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger wrote:
We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation. That said, it should be
recognized that some testing is better than no testing. And
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also contains
this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s), 8):
quanta = s[i: i + 8]
acc = 0
try:
On 20/05/13 23:38, Antoine Pitrou wrote:
On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano wrote:
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger wrote:
We should continue to encourage users to make thorough unit tests
and to leave doc
On 24/05/13 00:24, Ethan Furman wrote:
Here's the code that existed at one point:
for c in s:
val = _b32rev.get(c)
if val is None:
raise TypeError('Non-base32 digit found')
Even though there is no KeyError to convert in this incarnation, providing the
cause
On 24/05/13 01:04, Ethan Furman wrote:
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
I feel that the PEP should explicitly allow or disallow for the
implementation to accept dispatch on annotations, e.g.:
@func.register
def _(arg: int):
...
versus
@func.register(int)
def _(arg):
...
I
On 24/05/13 02:56, Paul Moore wrote:
On 23 May 2013 17:00, Walter Dörwald wrote:
Should it be possible to register multiple types for the generic function
with one register() call, i.e. should:
@fun.register(int, float)
def _(arg, verbose=False):
...
be allowed as a synonym fo
On 24/05/13 15:09, Nick Coghlan wrote:
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano wrote:
I don't think that they will. Being able to register multiple types with a
single call reads very naturally to me, while multiple decorators still
looks weird. Even after many years of seei
On 26/05/13 09:07, PJ Eby wrote:
"""
Transforms a function into a single-dispatch generic function. A **generic
function** is composed of multiple functions implementing the same
operation for different types. Which
implementation should be used during a call is determined by the
dispatch algori
On 29/05/13 04:00, Antoine Pitrou wrote:
On Tue, 28 May 2013 16:02:00 +0300
Serhiy Storchaka wrote:
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-
On 29/05/13 07:27, PJ Eby wrote:
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
Is it true that this cannot be used for instance and class methods? It
dispatches based on the first argument, which is "self" for instance
methods, whereas the second argument would almost certainly be the
On 04/06/13 12:43, 探晴 wrote:
Your email appears to be blank, except for a large chunk of HTML code. Did you
have something specific to say other than the subject line?
As for unbound methods, Guido's time machine strikes again. They're already
gone in Python 3.
py> class X:
... def sp
On 08/06/13 15:18, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Enumerations can be pickled and unpickled::
>
> >>> from enum import Enum
> >>> class Fruit(Enum):
> ... tomato = 1
> ... banana = 2
> ... cherry = 3
> ...
> >>>
On 22/06/13 01:29, Nick Coghlan wrote:
Basically, I want to hear from the Jython, PyPy and IronPython devs
that they're OK with us deleting Lib/stat.py. Hearing other CPython
devs say they're fine with it doesn't mean anything, since we're not
the ones that will have to do additional work as a re
On 21/06/13 01:35, Benjamin Peterson wrote:
2013/6/20 Charles-François Natali :
2013/6/20 Thomas Wouters :
If the .py file is going to be wrong or incomplete, why would we want to
keep it -- or use it as fallback -- at all? If we're dead set on having a
.py file instead of requiring it to be pa
On Tue, Jun 25, 2013 at 12:28:09AM +0200, Victor Stinner wrote:
> 2013/6/24 R. David Murray :
> > There is one. -X faulthandler. I'm sure others would agree about
> > -O, but that long predates -X.
>
> FYI I didn't chose "-X" because it is specific to CPython, but just
> because it becomes reall
On 26/06/13 08:44, Victor Stinner wrote:
And then I ran "make distclean"...
Victor, you're a cruel, cruel man. You've told us everything except the
solution to the mystery.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
On 14/07/13 21:09, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure completely undocumented
modules are also considered private:
-1 on this adjustment. If somebody cannot be bothered writing a one-line doc
string:
"This module is private, don't touch."
then they certa
On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
> On 15 July 2013 09:48, Steven D'Aprano wrote:
> > On 14/07/13 21:09, Nick Coghlan wrote:
> >
> >> Slight adjustment to the proposed wording to ensure completely
> >> undocumented
&g
On Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | I'd go further, and say that no more private modules should be
> | accepted for the std lib unless they have a leading underscore. I
> | suppose for backwards
On Mon, Jul 15, 2013 at 03:34:08PM +1200, Ben Hoyt wrote:
> Thanks, Nick -- that's helpful info. Writing such a PEP is a nice idea, but
> I think it'd be beyond me (I'm not familiar enough with CPython internals,
> protocols, etc).
>
> Can you explain what you mean by "symmetric protocol rather th
On 16/07/13 10:23, Chris McDonough wrote:
If what's being described here does become a rule, there is reason to
believe that future users who treat this PEP as the word-of-god (and
there are a *lot* of them; I hear from people literally every week who
want to "PEP8-ify" my code in some limited-v
On 16/07/13 20:28, Richard Oudkerk wrote:
On 16/07/2013 6:44am, Nick Coghlan wrote:
Clarifying what constitutes an internal interface in a way that
doesn't require renaming anything is a necessary prerequisite for
bundling or bootstrapping the pip CLI in Python 3.4 (as pip exposes
its internal i
On 16/07/13 22:02, Thomas Wouters wrote:
On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote:
PEP 8 advises developers to use absolute imports rather than explicit
relative imports.
Why? Using absolute imports couple the internal implementation of a
package to its public name - you can't just
On 17/07/13 19:05, Terry Reedy wrote:
Saying that input arguments can be "Unicode strings as well as 8-bit strings'
(the wording is from 2.x, carried over to 3.x) does not necessary exclude other
inputs.
"8-bit strings" seems somewhat ambiguous to me. In UTF-8, many Unicode strings
are 8-bi
On 19/07/13 04:46, Serhiy Storchaka wrote:
18.07.13 20:48, Guido van Rossum написав(ла):
I believe there are only a few places where en-dashes should be used,
for most things you should use either em-dash or hyphen. Consult your
trusted typography source (for US English, please, punctuation
pref
On 19/07/13 18:38, Nick Coghlan wrote:
I don't know about "common". I had no idea there were 3 dash types
*Way* more than three.
hyphen
minus sign (not the same as a hyphen!)
en-dash
em-dash
two-em-dash
three-em-dash
figure dash
horizontal bar
swung dash
plus another half-dozen or so non-Eng
Hi Syed,
On 30/07/13 07:57, syed khalid wrote:
I am attempting to import modules from Shogun to python from a non-standard
python directory ie from my /home/xxx directory. is there a way on ubuntu
to selectively some modules, scripts, data from one directory and others
modules, scripts from ano
On 01/08/13 22:44, Nick Coghlan wrote:
4. Lines up to 99 characters are now permitted (but 79 is still the
preferred limit)
Coincidentally, there was a discussion about line length on python-list over
the last couple of days. I think the two most relevant comments are by Skip
Montanaro:
ht
On 01/08/13 22:44, Nick Coghlan wrote:
With feedback from Guido, Barry, Raymond and others, I have updated
PEP 8 to better describe our current development practices. It started
as an update to describe the different between public and internal
interfaces and to advise against using wildcard impo
Hi Alexander,
On 02/08/13 00:48, Alexander Shorin wrote:
Hi Ronald,
I understand this, but I'm a bit confused about fate of lambdas with
such guideline since I see no more reasons to use them with p.9
statement: long lines, code duplicate, no mock and well tests etc. -
all these problems could
On 02/08/13 06:52, Alexander Belopolsky wrote:
On Thu, Aug 1, 2013 at 4:29 PM, Terry Reedy wrote:
def f(x): return 2*x
f = lambda x: 2*x
Am I the only one who finds the second line above much more readable than
the first? The def statement is not intended to be written in one line.
The r
Hi,
I have raise a tracker item and PEP for adding a statistics module to the
standard library:
http://bugs.python.org/issue18606
http://www.python.org/dev/peps/pep-0450/
and I'm about to submit a patch containing my updated code and tests, but I've
run into a problem with testing. My exist
601 - 700 of 1539 matches
Mail list logo
