Re: [Python-Dev] relative import circular problem

Le Tue, 2 Apr 2013 09:28:17 +, Kristján Valur Jónsson a écrit : > Right, as I explained in my reply to Barry, I was imprecise. > But the “from X import Y” is the only way to invoke relative imports, > where X can have leading dots. This syntax places the constraint on X > that Y is actually an

Re: [Python-Dev] Semantics of __int__(), __index__()

Le Wed, 03 Apr 2013 08:21:22 -0700, Ethan Furman a écrit : > On 04/03/2013 08:14 AM, Nick Coghlan wrote: > > > > On 4 Apr 2013 00:18, "Barry Warsaw" > > wrote: > >> > >> __index__() is a bit trickier because it is not tied directly to > >> type conversion. In this case,

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

Le Thu, 4 Apr 2013 06:57:14 +0200, Charles-François Natali a écrit : > > Are you planning to cover the code quality of the interpreter itself > > too? I've been recently reading through the cert.org secure coding > > practice recommendations and was wondering if there has is any > > ongoing effort

Re: [Python-Dev] Semantics of __int__(), __index__()

Le Fri, 5 Apr 2013 01:47:45 +1100, Chris Angelico a écrit : > > class Foo: > pass > > class Bar(Foo): > pass > > Is there any argument that I can pass to Foo() to get back a Bar()? > Would anyone expect there to be one? Sure, I could override __new__ to > do stupid things, but in terms

Re: [Python-Dev] The end of 2.7

On Sat, 6 Apr 2013 17:02:17 -0400 Benjamin Peterson wrote: > Obviously, there will be people who would be > happy if we kept maintaining 2.7 until 2025, but I think at this > juncture 5 total years of maintenance is reasonable. This means there > will be approximately 4 more 2.7 releases. > > Tho

Re: [Python-Dev] The end of 2.7

On Sun, 07 Apr 2013 18:11:03 +1000 Steven D'Aprano wrote: > 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, > incl

Re: [Python-Dev] [Python-checkins] cpython (3.3): Process DEFAULT values in mock side_effect that returns iterator.

On Mon, 8 Apr 2013 10:52:30 +0100 Michael Foord wrote: > On 7 April 2013 14:44, andrew.svetlov wrote: > > > http://hg.python.org/cpython/rev/18fd64f1de2d > > changeset: 83179:18fd64f1de2d > > branch: 3.3 > > user:Andrew Svetlov > > date:Sun Apr 07 16:42:24 2013 +0300 > >

Re: [Python-Dev] cpython (3.3): don't run frame if it has no stack (closes #17669)

On Wed, 10 Apr 2013 23:01:46 +0200 (CEST) benjamin.peterson wrote: > http://hg.python.org/cpython/rev/35cb75b9d653 > changeset: 83238:35cb75b9d653 > branch: 3.3 > parent: 83235:172f825d7fc9 > user:Benjamin Peterson > date:Wed Apr 10 17:00:56 2013 -0400 > summary: > d

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On Thu, 11 Apr 2013 14:11:21 -0700 Guido van Rossum wrote: > Hey Antoine, > > Some of my Dropbox colleagues just drew my attention to the occurrence > of case folding in pathlib.py. Basically, case folding as an approach > to comparing pathnames is fatally flawed. The issues include: > > - most

Re: [Python-Dev] casefolding in pathlib (PEP 428)

Le Thu, 11 Apr 2013 15:42:00 -0700, Guido van Rossum a écrit : > On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou > wrote: > > On Thu, 11 Apr 2013 14:11:21 -0700 > > Guido van Rossum wrote: > >> Hey Antoine, > >> > >> Some of my Dropbox colleagues jus

Re: [Python-Dev] casefolding in pathlib (PEP 428)

Le Fri, 12 Apr 2013 08:06:37 -0400, Devin Jeanpierre a écrit : > On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou > wrote: > > Ok, I've taken a look at the code. Right now lower() is used for two > > purposes: > > > > 1. comparisons (__eq__ and __ne__) > &g

Re: [Python-Dev] casefolding in pathlib (PEP 428)

Le Fri, 12 Apr 2013 14:43:42 +0200, Ronald Oussoren a écrit : > > On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote: > >> > >> > >> Perhaps it would be best if the code never called lower() or > >> upper() (not even indirectly via os.path.normca

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On Fri, 12 Apr 2013 19:42:25 +0200 Ralf Schmitt wrote: > Guido van Rossum writes: > > > Actually, I've heard of code that dynamically falls back on short > > names when paths using long names exceed the system limit for path > > length (either 256 or 1024 IIRC). But short names pretty much requi

Re: [Python-Dev] A decade as a core dev

On Thu, 18 Apr 2013 11:02:37 -0400 Brett Cannon wrote: > Today marks my 10 year anniversary as a core developer on Python. I > wrote a blog post to mark the occasion > (http://sayspy.blogspot.ca/2013/04/a-decade-of-commits.html), but I > wanted to personally thank python-dev for the past decade (a

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Hello, Le Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky a écrit : > > We're happy to present the revised PEP 435, collecting valuable > feedback from python-ideas discussions as well as in-person > discussions and decisions made during the latest PyCon language > summit. We believe the proposa

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Hello, (sorry for the previous message attempt - my mouse pointer hit the send button before I was finished with it) Le Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky a écrit : > > We're happy to present the revised PEP 435, collecting valuable > feedback from python-ideas discussions as well

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Le Tue, 23 Apr 2013 10:24:18 -0400, "R. David Murray" a écrit : > > > > I'm having a problem with the proposed implementation. I haven't > > found any mention of it, so apologies if this has already been > > discussed: > > > > >>> from flufl.enum import * > > >>> class C(Enum): > > ... a = 1 >

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Le Wed, 24 Apr 2013 00:22:40 +1000, Nick Coghlan a écrit : > > Looking at the source > (https://bazaar.launchpad.net/~barry/flufl.enum/trunk/view/head:/flufl/enum/_enum.py), > I'm not seeing any fundamental technical issues with merging the Enum > and EnumValue class definitions, and then using "

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

On Thu, 25 Apr 2013 04:19:36 +0200 Lennart Regebro wrote: > On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull > wrote: > > RFC 4648 repeatedly refers to *characters*, without specifying an > > encoding for them. [...] > > Base64 is an encoding that transforms between 8-bit streams. No, it i

Re: [Python-Dev] slow hg clone of python repo?

On Wed, 24 Apr 2013 16:24:15 -0700 Guido van Rossum wrote: > It's a big repo. Patience. We are actually having bandwidth issues with the current OSU/OSL hosting of python.org machines, which is affecting not only hg.python.org but also pypi.python.org, for at least some users. I believe Noah and

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Le Thu, 25 Apr 2013 08:38:12 +0200, Lennart Regebro a écrit : > On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou > wrote: > > On Thu, 25 Apr 2013 04:19:36 +0200 > > Lennart Regebro wrote: > >> On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull > >> wrote:

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Le Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky a écrit : > > To programmatically access enumeration values, use ``getattr``:: > > >>> getattr(Colors, 'red') > The PEP should mention how to get an enum from its raw value: >>> Colors[1] or: >>> Colors(1) It would

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Le Thu, 25 Apr 2013 05:21:50 -0700, Eli Bendersky a écrit : > > > > or: > > > > >>> Colors(1) > > > > > > > This syntax was considered initially but then rejected because it's > confusing, and there already exists a way to lookup by value > (Colors[1]). Well, it works in latest flufl.e

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Le Thu, 25 Apr 2013 12:46:43 +0200, Xavier Morel a écrit : > On 2013-04-25, at 11:25 , Antoine Pitrou wrote: > > > > Besides, I would consider a RFC more authoritative than a > > Wikipedia definition. > > > Base encoding of data is used in many situations to

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Le Thu, 25 Apr 2013 12:05:01 +0200, Lennart Regebro a écrit : > > The Wikipedia page does talk about *text* and *characters* for > > the result of base64 encoding. > > So are saying that you want the Python implementation of base64 > encoding to take 8-bit binary data in bytes format and return a

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Le Thu, 25 Apr 2013 09:55:26 -0400, Tres Seaver a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/25/2013 01:43 AM, Antoine Pitrou wrote: > > On Thu, 25 Apr 2013 04:19:36 +0200 Lennart Regebro > > wrote: > >> On Thu, Apr 25, 2013 at 3:54 AM

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

Le Thu, 25 Apr 2013 15:34:45 +0200, Lennart Regebro a écrit : > > I don't agree that there is a significant difference between those > wordings in this context. The end result is the same: Things intended > to be handled/seen as textual should be unicode strings, things > intended for data exchan

Re: [Python-Dev] NoneType(None) raises exception

On Thu, 25 Apr 2013 16:09:41 -0700 Ethan Furman wrote: > We just fixed NoneType() to return None instead of raising an exception. > > Another use-case for calling NoneType is working with ORMs: > > result = [] > for field in row: > type = get_type(field) # returns int, bool, str, None

[Python-Dev] Generator finalization and reference cycles

Hello, I have proposed a new generator finalization scheme in http://bugs.python.org/issue17807: it removes the tp_del from generator objects, instead electing to cleanup the generator (equivalent of calling close()) in the frame's tp_clean function. This way, generators with a try / finally bloc

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sun, 28 Apr 2013 13:02:11 -0700 Guido van Rossum wrote: > > > - for the above two, how should they be included/excluded? > > IMO Everything should be enumerated except > (a) things with a __get__() method (i.e. descriptors) > (b) __dunder__ names I think it would be nice to define regular

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Mon, 29 Apr 2013 08:28:34 +1000 Nick Coghlan wrote: > On 29 Apr 2013 07:32, "Antoine Pitrou" wrote: > > > > On Sun, 28 Apr 2013 13:02:11 -0700 > > Guido van Rossum wrote: > > > > > > > - for the above two, how should they be inc

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sun, 28 Apr 2013 17:29:35 -0700 Ethan Furman wrote: > > Not only is this inconsistent with the rest of Python*, but it's going to be > a PITA for data storage/retrieval: > > datastore = dbf.Table('storage.dbf', 'event_name C(50); date D; season > SEASON') > > def retrieve_record(

Re: [Python-Dev] Enums and data retrieval

Le Mon, 29 Apr 2013 00:13:53 -0700, Ethan Furman a écrit : > [starting new thread to not pollute the summary thread] > > On 04/28/2013 11:54 PM, Antoine Pitrou wrote:> On Sun, 28 Apr 2013 > 17:29:35 -0700 > > Ethan Furman wrote: > >> > >> Not only is th

Re: [Python-Dev] Destructors and Closing of File Objects

Le Mon, 29 Apr 2013 16:42:38 +0200, Armin Rigo a écrit : > Hi Nikolaus, > > On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath > wrote: > > It's indeed very informative, but it doesn't fully address the > > question because of the _pyio module which certainly can't use any > > custom C code. Does th

Re: [Python-Dev] PEP 428: stat caching undesirable?

Hi, On Wed, 01 May 2013 09:32:28 +0200 Pieter Nagel wrote: > Hi all, > > I write as a python lover for over 13 years who's always wanted > something like PEP 428 in Python. > > I am concerned about the caching of stat() results as currently defined > in the PEP. This means that all behaviour

Re: [Python-Dev] Enum: subclassing?

On Wed, 01 May 2013 10:21:30 -0700 Ethan Furman wrote: > We may not want to /completely/ disallow subclassing. Consider: > > --> class StrEnum(str, Enum): > ...'''string enums for Business Basic variable names''' > ... > --> class Vendors(StrEnum): > EnumError: subclassing not allowed I don

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:05:53 -0700 Eli Bendersky wrote: > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > > On Wed, 01 May 2013 10:21:30 -0700 > > > Ethan Furman wrote: > > >> We may not

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:43:22 -0700 Eli Bendersky wrote: > On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou wrote: > > > On Wed, 1 May 2013 13:05:53 -0700 > > Eli Bendersky wrote: > > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > > > >

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:57:11 -0700 Eli Bendersky wrote: > > I still don't understand what you mean, sorry. Like, this: > > class MyEmptyEnum(Enum): > pass > > Why would you want to subclass MyEmptyEnum ? > > Or do you mean this: > > class IntEnum(int, Enum): > pass > > Now I can have: >

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 14:04:11 -0700 Eli Bendersky wrote: > > You mean this? > > class BehaviorMixin: > # bla bla > > class MyBehavingIntEnum(int, BehaviorMixin, Enum): > foo = 1 > bar = 2 Yes, but without the need for multiple inheritance and separate mixins ;-) Especially if the behaviour

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson wrote: > 2013/5/2 Ethan Furman : > > In order for the Enum convenience function to be pickleable, we have this > > line of code in the metaclass: > > > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > > > This works fine f

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky wrote: > > Two things that were suggested in private: > > > > 1) ask users to pass the module name to the convenience function > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > > class "name"). Guido doesn't like it :-) > >

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 13:33:21 -0700 Eli Bendersky wrote: > On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou wrote: > > > On Thu, 2 May 2013 13:15:00 -0700 > > Eli Bendersky wrote: > > > > Two things that were suggested in private: > > > > > >

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 13:48:24 -0700 Eli Bendersky wrote: > On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw wrote: > > > On May 02, 2013, at 10:18 PM, Georg Brandl wrote: > > > > >5) accept that convenience-created enums have restrictions such as no > > >picklability and point them out in the docs? >

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 13:52:29 -0700 Eli Bendersky wrote: > > Back to my question from before, though - do we have a real technical > limitation of having something like inspect.what_module_am_i_now_in() > that's supposed to work for all Python code? I already gave an answer (e.g. the debugger case

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 14:16:34 -0700 Barry Warsaw wrote: > On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote: > > >On Thu, 2 May 2013 13:48:24 -0700 > >> The problem with (5) is this: you use some library that exports an > >> enumeration, and you want to use pickling.

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, 2 May 2013 14:15:40 -0700 Eli Bendersky wrote: > > Sorry, but I do find the argument "let's not have a convenience syntax > because enums created with such syntax won't pickle properly from within a > debugger" not convincing enough :-) Eli, it would be nice if you stopped with this clai

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Le Fri, 3 May 2013 09:14:22 +1000, Nick Coghlan a écrit : > > > > The other issue is your proposal to have a class-based convenience > > syntax > akin to (correct me if I got this wrong): > > > > class Animal(Enum): > > __values__ = 'cat dog' > > I would suggest moving the field names into the

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Le Thu, 2 May 2013 14:57:35 -0700, Eli Bendersky a écrit : > > class Animal(Enum): > __values__ = 'cat dog' > > This is obviously a matter of preference (and hence bikeshedding), > but this still looks better to me: > > Animal = Enum('Animal', 'cat dog') > > It has two advantages: > > 1. Sh

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Le Fri, 03 May 2013 19:40:21 +1000, Steven D'Aprano a écrit : > 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 > >> cla

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sat, 04 May 2013 11:15:17 +1200 Greg Ewing wrote: > Eli Bendersky wrote: > > I'm just curious what it is about enums that sets everyone on a "let's > > make things safer" path. Python is about duck typing, it's absolutely > > "unsafe" in the static typing sense, in the most fundamental ways

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On Sat, 04 May 2013 11:41:27 +1000 Steven D'Aprano wrote: > > > 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 of .pyzw? > > I've had Linux systems whic

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sat, 4 May 2013 16:42:08 +1000 Nick Coghlan wrote: > On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote: > > Am 04.05.2013 01:22, schrieb Antoine Pitrou: > >> On Sat, 04 May 2013 11:15:17 +1200 > >> Greg Ewing wrote: > >>> Eli Bendersky wrote: > >

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sat, 04 May 2013 06:37:23 -0700 Ethan Furman wrote: > > +1. An enum is basically a bidirectional mapping between some raw > values and some "nice" instances, so it deserves a well-defined lookup > operation in each direction. > >> > >> As I see it, there are 3 possible ways

Re: [Python-Dev] PEP 435 - requesting pronouncement

On Sat, 4 May 2013 15:04:49 -0700 Eli Bendersky wrote: > Hello pydev, > > PEP 435 is ready for final review. A lot of the feedback from the last few > weeks of discussions has been incorporated. I still would like to see Nick's class-based API preferred over the functional API: class Season(

Re: [Python-Dev] PEP 435 - requesting pronouncement

On Sun, 05 May 2013 20:59:03 +1000 Steven D'Aprano wrote: > 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 sum

Re: [Python-Dev] PEP 435 - requesting pronouncement

On Sun, 5 May 2013 07:09:14 -0700 Eli Bendersky wrote: > On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou wrote: > > > On Sat, 4 May 2013 15:04:49 -0700 > > Eli Bendersky wrote: > > > Hello pydev, > > > > > > PEP 435 is ready for final review

Re: [Python-Dev] PEP 435 - requesting pronouncement

On Sun, 5 May 2013 15:27:36 -0700 Eli Bendersky wrote: > > As for pickling enums created with the functional API, I don't think we now > provide less than the pickle module dictates in the general sense. The > pickle docs say: Next time, please try reading the message(s) you are replying to befo

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

Le Mon, 6 May 2013 23:18:54 +1000, Nick Coghlan a écrit : > > IIRC, Jython just delays calculating the object id() until it is > called, and lives with it potentially being incredibly expensive to > calculate. Is there some way PyPy can run with a model where "is" is > defined in terms of values

Re: [Python-Dev] cpython: Issue #11816: multiple improvements to the dis module

On Mon, 6 May 2013 15:59:49 +0200 (CEST) nick.coghlan wrote: > http://hg.python.org/cpython/rev/f65b867ce817 > changeset: 83644:f65b867ce817 > user:Nick Coghlan > date:Mon May 06 23:59:20 2013 +1000 > summary: > Issue #11816: multiple improvements to the dis module > > * get

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, 06 May 2013 18:23:02 -0400 Terry Jan Reedy wrote: > > 'Item' is necessarily left vague for mutable sequences as bytearrays > also store values. The fact that Antoine's example 'works' for > bytearrays is an artifact of the caching, not a language-mandated > necessity. No, it isn't. You

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, 06 May 2013 22:50:55 -0400 Terry Jan Reedy wrote: > > > A bytearray or a array.array may indeed store values, but a list stores > > references to > > objects. > > I said exactly that in reference to CPython. As far as I know, the same > is true of lists in every other implementation up

Re: [Python-Dev] PEP 435: pickling enums created with the functional API

Le Wed, 8 May 2013 01:03:38 +1000, Nick Coghlan a écrit : > > What if there was a variant of the class statement that bound the > result of a function call rather than using the normal syntax: > > class Animal from enum.Enum(members="dog cat bear") Apparently you're trying hard to invent sy

Re: [Python-Dev] PEP 435: pickling enums created with the functional API

Le Tue, 7 May 2013 08:44:46 -0700, Eli Bendersky a écrit : > > > 4) Using _getframe(N) here seems like an overkill to me. > > > > It's not just overkill, it's fragile - it only works if you call the > > constructor directly. If you use a convenience function in a utility > > module, it will try t

Re: [Python-Dev] All 3.x stable buildbots are red

On Tue, 7 May 2013 09:34:45 +0200 Victor Stinner wrote: > http://buildbot.python.org/all/waterfall?category=3.x.stable > > x86 Windows Server 2003 [SB] 3.x: 3 tests failed, test___all__ test_gc > test_ssl > x86 Windows7 3.x: 3 tests failed, test___all__ test_gc test_ssl > x86 Gentoo Non-Debug 3.

[Python-Dev] Call for testing: generator finalization

Hello, In http://bugs.python.org/issue17807 I've committed a patch to allow generator finalization (execution of "finally" blocks) even when a generator is part of a reference cycle. If you have some workload which is known for problems with generator finalization (or otherwise makes a heavy use

Re: [Python-Dev] PEP 0 maintenance - deferring some currently open PEPs

Hello Nick, Le Fri, 10 May 2013 17:14:21 +1000, Nick Coghlan a écrit : > I'd like to mark a few PEPs that are not currently being actively > considered for 3.4 as Deferred: > > S 286 Enhanced Argument Tuplesvon > Löwis S 337 Logging Usage in the Standard >

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Fri, 10 May 2013 13:46:30 +0200, Christian Heimes a écrit : > > Hence I'm +1 on the general idea but -1 on something stat like. IMHO > os.scandir() should yield four objects: > > * name > * inode > * file type or DT_UNKNOWN > * stat_result or None > > stat_result shall only be returned w

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Fri, 10 May 2013 15:46:21 +0200, Christian Heimes a écrit : > Am 10.05.2013 14:16, schrieb Antoine Pitrou: > > But what if some systems return more than the file type and less > > than a full stat result? The general problem is POSIX's terrible > > inertia. I feel th

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Fri, 10 May 2013 23:53:37 +1000, Nick Coghlan a écrit : > On Fri, May 10, 2013 at 11:46 PM, Christian Heimes > wrote: > > Am 10.05.2013 14:16, schrieb Antoine Pitrou: > >> But what if some systems return more than the file type and less > >> than a full stat

Re: [Python-Dev] PEP 0 maintenance - deferring some currently open PEPs

On Fri, 10 May 2013 14:00:09 -0700 Larry Hastings wrote: > > I swear I posted a list like this a couple years ago. Now I can't find > it. Anyway it was completely ignored then, probably because I'm not > Nick Coghlan. Many people in the world suffer with this problem. Regards Antoine. __

Re: [Python-Dev] Tightening up the specification for locals()

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(): it is > > currently severely underspecified, and I'd like to mak

Re: [Python-Dev] Tightening up the specification for locals()

On Sun, 12 May 2013 23:22:39 +1000 Nick Coghlan wrote: > The exec case > corresponds to those two instances, depending on whether the single > namespace or dual namespace version is performed. I don't get the point. exec() *passes* a locals dictionary, but the compiled code itself isn't expected

Re: [Python-Dev] 2.7.5 baking

On Sun, 12 May 2013 13:24:45 +0200 Georg Brandl wrote: > Am 12.05.2013 06:03, schrieb Benjamin Peterson: > > The long anticipated "emergency" 2.7.5 release has now been tagged. It > > will be publicly announced as binaries arrive. > > > > Originally, I was just going to cherrypick regression fix

Re: [Python-Dev] Best practices for Enum

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

Re: [Python-Dev] weak refs in descriptors (http://bugs.python.org/issue17950)

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

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Tue, 14 May 2013 10:41:01 +1200, Ben Hoyt a écrit : > > 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,

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Tue, 14 May 2013 10:41:01 +1200, Ben Hoyt a écrit : > > If anyone can run benchmark.py on Linux / NFS or similar, that'd be > great. You'll probably have to lower DEPTH/NUM_DIRS/NUM_FILES first > and then move the "benchtree" to the network file system to run it > against that. On a locally r

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Tue, 14 May 2013 20:54:50 +1200, Ben Hoyt a écrit : > >> If anyone can run benchmark.py on Linux / NFS or similar, that'd be > >> great. You'll probably have to lower DEPTH/NUM_DIRS/NUM_FILES first > >> and then move the "benchtree" to the network file system to run it > >> against that. > > >

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Tue, 14 May 2013 21:10:08 +1200, Ben Hoyt a écrit : > > On a locally running VM: > > os.walk took 0.400s, scandir.walk took 0.120s -- 3.3x as fast > > > > Same VM accessed from the host through a local sshfs: > > os.walk took 2.261s, scandir.walk took 2.055s -- 1.1x as fast > > > > Same, but wi

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Le Tue, 14 May 2013 22:14:42 +1200, Ben Hoyt a écrit : > >> It should be no slower when it's all moved to C. > > > > The slowdown is too small to be interesting. The main point is that > > there was no speedup, though. > > True, and thanks for testing. > > I don't think that's a big issue, howev

Re: [Python-Dev] How to debug python crashes

Le Tue, 14 May 2013 14:32:27 +0200, Philippe Fremy a écrit : > Hi, > > I have a reproducable crash on Windows XP with Python 2.7 which I > would like to investigate. I have Visual Studio 2008 installed and I > downloaded the pdb files. However I could not find any instructions on > how to use the

Re: [Python-Dev] Mysterious Python pyc file corruption problems

On Thu, 16 May 2013 11:42:30 -0400 Barry Warsaw wrote: > On May 16, 2013, at 08:33 AM, Nick Coghlan wrote: > > >Personally, I would be suspicious of developmental web services doing > >auto-reloading while an installer is recompiling the world. I don't have > >enough context to be sure how plaus

[Python-Dev] HAVE_FSTAT?

Hello, Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused

Re: [Python-Dev] HAVE_FSTAT?

On Fri, 17 May 2013 09:15:29 -0500 Skip Montanaro wrote: > > Some pieces of code are still guarded by: > > #ifdef HAVE_FSTAT > > ... > > #endif > > Are there other guards for similarly common libc functions? I don't think so. Someone should take a look though :-) Regards Antoine. ___

Re: [Python-Dev] [RELEASED] Python 3.2.5 and Python 3.3.2

On Thu, 16 May 2013 13:24:36 +0200 Charles-François Natali wrote: > 2013/5/16 Serhiy Storchaka : > > 16.05.13 08:20, Georg Brandl написав(ла): > >> > >> On behalf of the Python development team, I am pleased to announce the > >> releases of Python 3.2.5 and 3.3.2. > >> > >> The releases fix a few

[Python-Dev] PEP 442: Safe object finalization

Hello, I would like to submit the following PEP for discussion and evaluation. Regards Antoine. PEP: 442 Title: Safe object finalization Version: $Revision$ Last-Modified: $Date$ Author: Antoine Pitrou Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2013-05-18 Python

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 21:05:48 +1000 Nick Coghlan wrote: > On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou wrote: > > Resurrection > > The process by which a finalizer creates a new reference to an > > object in a CI. This can happen as a quirky but supported &

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 22:51:35 +1000 Nick Coghlan wrote: > On Sat, May 18, 2013 at 9:46 PM, Antoine Pitrou wrote: > > On Sat, 18 May 2013 21:05:48 +1000 > > Nick Coghlan wrote: > >> On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou > >> wrote: > >> > R

Re: [Python-Dev] PEP 442: Safe object finalization

Hi Armin, On Sat, 18 May 2013 15:24:08 +0200 Armin Rigo wrote: > Hi Antoine, > > On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou wrote: > > Cyclic isolate (CI) > > A reference cycle in which no object is referenced from outside the > > cycle *and* whose ob

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 06:37:54 -0700 Eli Bendersky wrote: > Great PEP, I would really like to see this happen as it defines much saner > semantics for finalization than what we currently have. One small question > below: > > > This PEP proposes to turn CI disposal into the following sequence (new

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 14:56:38 +0100 Richard Oudkerk wrote: > On 18/05/2013 9:59am, Antoine Pitrou wrote: > > This PEP proposes to turn CI disposal into the following sequence (new > > steps are in bold): > > > > 1. Weakrefs to CI objects are cleared, and their callba

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 16:22:55 +0200 Armin Rigo wrote: > Hi Antoine, > > On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote: > >> How is this done? I don't see a clear way to determine it by looking > >> only at the objects in the CI, given that arbitrary

Re: [Python-Dev] PEP 442: Safe object finalization

On Sat, 18 May 2013 15:52:56 +0100 Richard Oudkerk wrote: > On 18/05/2013 3:18pm, Antoine Pitrou wrote: > > It works fine: > > > > $ ./python sbt.py > > <__main__.Node object at 0x7f3acbf8f400> <__main__.Node object at > > 0x7f3acbf8f878> > >

Re: [Python-Dev] HAVE_FSTAT?

On Sun, 19 May 2013 10:08:39 +0200 Charles-François Natali wrote: > 2013/5/17 Antoine Pitrou : > > > > Hello, > > > > Some pieces of code are still guarded by: > > #ifdef HAVE_FSTAT > > ... > > #endif > > > > I would expect all system

Re: [Python-Dev] Ordering keyword dicts

On Sat, 18 May 2013 22:47:35 -0700 Guido van Rossum wrote: > On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger > wrote: > > BTW, I'm +1 on the idea for ordering keyword-args. It makes > > it easier to debug if the arguments show-up in the order they > > were created. AFAICT, no purpose is ser

Re: [Python-Dev] HAVE_FSTAT?

rds Antoine. > — > Sent from Mailbox > > On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou > wrote: > > > On Sun, 19 May 2013 10:08:39 +0200 > > Charles-François Natali wrote: > >> 2013/5/17 Antoine Pitrou : > >> > > >> >

Re: [Python-Dev] HAVE_FSTAT?

On Mon, 20 May 2013 01:09:19 +1000 Nick Coghlan wrote: > On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou wrote: > > On Sun, 19 May 2013 07:47:14 -0700 (PDT) > > "Guido van Rossum" wrote: > >> Fake values would probably cause hard to debug problems. It's

Re: [Python-Dev] Why is documentation not inline?

On Sun, 19 May 2013 15:29:37 -0700 Demian Brecht wrote: > This is more out of curiosity than to spark change (although I > wouldn't argue against it): Does anyone know why it was decided to > document external to source files rather than inline? > > When rapidly digging through source, it would b

Re: [Python-Dev] [RELEASED] Python 2.7.5

On Sun, 19 May 2013 19:37:46 -0400 Pierre Rouleau wrote: > On that topic of bitness for 64-bit platforms, would it not be better for > CPython to be written such that it uses the same 64-bit strategy on all > 64-bit platforms, regardless of the OS? > > As it is now, Python running on 64-bit Wind

<    9   10   11   12   13   14   15   16   17   18   >