On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> * will enums break doctests or any existing user code
>
Those are already broken by design. We shouldn't be limited just because
someone wrote a bad test that assumed a particular repr of a value. We've
On Sun, May 12, 2013 at 3:04 PM, Ben Hoyt wrote:
> > And if we're creating a custom object instead, why return a 2-tuple
> > rather than making the entry's name an attribute of the custom object?
> >
> > To me, that suggests a more reasonable API for os.scandir() might be
> > for it to be an iter
On 05/13/2013 10:01 PM, Glenn Linderman wrote:
On 5/13/2013 7:36 PM, Ethan Furman wrote:
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure out using
an earlier NamedInt class:
class NIE( IntET, Enum ):
x = ('NIE.x', 1)
On 05/13/2013 10:01 PM, Glenn Linderman wrote:
Sorry if this sounds repetitious, but all the other times I've mentioned it, it
has been in a big discussion of other
stuff too.
It's a while 'til 3.4. A bitfield-type enum may show up in the docs, if no
where else. ;)
--
~Ethan~
On 5/13/2013 7:36 PM, Ethan Furman wrote:
2) Is something like demo2 interesting to anyone but me? Of course, I
think it would be great for reporting flag values
using names rather than a number representing combined bit fields.
No idea. ;)
There's been some talk of Enum-ing constants in th
On 5/13/2013 7:36 PM, Ethan Furman wrote:
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure
out using an earlier NamedInt class:
class NIE( IntET, Enum ):
x = ('NIE.x', 1)
y = ('NIE.y', 2)
z = ('NIE.z', 4)
and t
On 05/13/2013 07:36 PM, Ethan Furman wrote:
Here's your code, revamped. I did make a slight change in the meta -- I moved
the name assignment above the __init__
call so it's available in __init__.
--8<
from ref435 import Enum
from flags
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure out using
an earlier NamedInt class:
class NIE( IntET, Enum ):
x = ('NIE.x', 1)
y = ('NIE.y', 2)
z = ('NIE.z', 4)
and then expressions involving members of NIE (an
> OK, you got me! I'm now convinced that a property is a bad idea.
Thanks. :-)
> I still like to annotate that the function may return a cached value.
> Perhaps lstat() could require an argument?
>
> def lstat(self, cached):
> if not cached or self._lstat is None:
> self._
> I'd to see the numbers for NFS or CIFS - stat() can be brutally slow
> over a network connection (that's why we added a caching mechanism to
> importlib).
How do I know what file system Windows networking is using? In any
case, here's some numbers on Windows -- it's looking pretty good! This
is
On Mon, 13 May 2013 13:21:17 -0400
Terry Jan Reedy wrote:
> On 5/13/2013 9:20 AM, Maciej Fijalkowski wrote:
>
> > The strong reference there is a feature. Descriptors keep the class
> > alive if somehow the class disappears and the descriptor itself does
>
> Is this feature stated or implied in
On 5/13/2013 9:20 AM, Maciej Fijalkowski wrote:
The strong reference there is a feature. Descriptors keep the class
alive if somehow the class disappears and the descriptor itself does
Is this feature stated or implied in the reference manual?
3.3.2.1. Implementing Descriptors
3.3.2.2. Invokin
On 05/13/2013 12:06 AM, Raymond Hettinger wrote:
Ethan's email suggests that against my advice he is in-fact going to go through
the standard library, applying enums
quite broadly.
I think you are falling victim to Wizard's First Rule: people will believe what
they want to be true, or are af
Am 13.05.2013 02:21, schrieb Ben Hoyt:
> Are you suggesting just accessing .cached_lstat could call os.lstat()?
> That seems very bad to me. It's a property access -- it looks cheap,
> therefore people will expect it to be. From PEP 8 "Avoid using
> properties for computationally expensive operatio
On May 12, 2013, at 04:49 PM, Raymond Hettinger wrote:
>After the long design effort for the enum module, I'm sure there will be a
>forthcoming effort to apply them pervasively throughout the standard library.
We usually, explicitly, try not to do such wholesale adoptions in the stdlib
when new f
> Like it or not, people rely on this behavior. I don't think CPython
> (or PyPy) can actually afford to change it. If so, documenting it
> sounds like a better idea than leaving it undocumented only known to
> the "inner shrine"
>
+1. I am relying on this.
On 13 May 2013 10:20, Maciej Fijalkowski wrote:
> On Mon, May 13, 2013 at 1:49 PM, Kristján Valur Jónsson
> wrote:
>> Hello python-dev.
>>
>> I‘m working on a patch to remove reference cycles from heap-allocated
>> classes: http://bugs.python.org/issue17950
>>
>> Part of the patch involves makin
On Mon, May 13, 2013 at 1:49 PM, Kristján Valur Jónsson
wrote:
> Hello python-dev.
>
> I‘m working on a patch to remove reference cycles from heap-allocated
> classes: http://bugs.python.org/issue17950
>
> Part of the patch involves making sure that descriptors in the class
> dictionary don’t con
On Mon, May 13, 2013 at 10:25 PM, Ben Hoyt wrote:
> Okay, I've renamed my "BetterWalk" module to "scandir" and updated it
> as per our discussion:
>
> https://github.com/benhoyt/scandir/#readme
Nice!
> PERFORMANCE: On Windows I'm seeing that scandir.walk() on a large test
> tree (see benchmark.p
Hi Ben,
Am 13.05.13 14:25, schrieb Ben Hoyt:
...It's not yet production-ready, and is basically still in API and
performance testing stage. ...
In any case, I really like the API (thanks mostly to Nick Coghlan),
and performance is great, even with DirEntry being written in Python.
PERFORMANCE:
Okay, I've renamed my "BetterWalk" module to "scandir" and updated it
as per our discussion:
https://github.com/benhoyt/scandir/#readme
It's not yet production-ready, and is basically still in API and
performance testing stage. For instance, the underlying scandir_helper
functions don't even retu
Hello python-dev.
I'm working on a patch to remove reference cycles from heap-allocated classes:
http://bugs.python.org/issue17950
Part of the patch involves making sure that descriptors in the class dictionary
don't contain strong references to the class itself.
This is item 2) in the defect de
On Sun, May 12, 2013 at 2:01 PM, Antoine Pitrou wrote:
> On Fri, 03 May 2013 12:43:41 +1000
> Steven D'Aprano wrote:
>> 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(): i
Raymond Hettinger wrote:
> I would like to ask for a little restraint and for there to
> be individual cost/benefit evaluations for each case.
+1
> For external constants, some thought needs to be given to:
> * is the current API working just fine (i.e. decimal's ROUND_DOWN)
For compatibility
Le Mon, 13 May 2013 00:06:52 -0700,
Raymond Hettinger a écrit :
>
> On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
>
> > Thanks for the insights, Raymond. I don't think anyone is planning
> > on rushing anything. We still have to get the enum module itself
> > committed and a serious review
Raymond Hettinger writes:
> whether users will see any actual benefits (particularly for
> internal constants).
I don't understand the parenthetical remark. It seems to me that
changing internal constants should have the benefits that Ethan points
to for understanding, debugging, and interacti
On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
> Thanks for the insights, Raymond. I don't think anyone is planning on rushing
> anything. We still have to get the enum module itself committed and a serious
> review process has just started for that, so it will take time.
>
> There's no ge
27 matches
Mail list logo
