Frankly, this kind of inept discussion, where a bunch of folks get hung
up about an extremely minor design decision (who cares whether "assret"
is being special-cased or not? in the actual world, not the fantasy
world of righteous indignation and armchair architects?), is amongst
the reasons why I
> These leaks have been here a while. Anyone know the cause?
>
> On Tue, 20 Oct 2015 at 01:47 wrote:
>
>> results for d7e490db8d54 on branch "default"
>>
>>
>> test_capi leaked [5411, 5411, 5411] references, sum=16233
>> test_capi leaked [1421, 1423,
Le 21/10/2015 17:32, Raymond Hettinger a écrit :
>
> Thanks for hunting this down. I had seen the automated reference leak posts
> but didn't suspect that a pure python class would have caused the leak.
Yes, it's a bit baffling at first.
> I'm re-opening
> https://mail.python.org/pipermail/
Hi,
If you want to make startup time faster for a broad range of applications,
please consider adding a lazy import facility in the stdlib.
I recently tried to write a lazy import mechanism using import hooks
(to make it portable from 2.6 to 3.5), it seems nearly impossible to do
so (or, at least
Brett Cannon python.org> writes:
>
>
> A lazy importer was added in Python 3.5 and it was not possible
> without the module spec refactoring.
Wow... Thank you, I didn't know about that.
Now for the next question: how am I supposed to use it?
The following documentation leaves me absolutely c
Demur Rumed gmail.com> writes:
> I've personally benchmarked this fork with positive results.
I'm skeptical of claims like this. What did you benchmark exactly, and with
which results?
I don't think changing the opcode encoding per se will bring any large
benefit...
Regards
Antoine.
_
I think the provisional status can be safely lifted now. Even though
pathlib hasn't seen that much use, there have been enough reports and
discussion since its acception that I think the API has proven it's sane
for general use.
(as for importlib, pathlib might have too many dependencies for san
Brett Cannon python.org> writes:
>
> :) I figured. I was close myself until I decided to be the "not inheriting
from str is a sane decision" camp because people weren't understanding where
the design decision probably came from,
hence http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str
Nick Coghlan gmail.com> writes:
>
> sys.path, for example.
>
> That's why I'd actually prefer the implicit conversion protocol to be
> the more explicitly named "__fspath__", with suitable "__fspath__ =
> path" assignments added to DirEntry and pathlib.
That was my preference as well.
> Howeve
Ethan Furman stoneleaf.us> writes:
> >
> > Not sure about os.path.*. The purpose of os.path module is manipulating
> > string paths. From the perspective of pathlib it can look lower level.
>
> The point is that a function that receives a "path" object (whether str
> or Path) shouldn't have to c
Le 07/04/2016 16:40, Eric Snow a écrit :
>
> On Apr 6, 2016 11:11 PM, "Raymond Hettinger"
> mailto:raymond.hettin...@gmail.com>> wrote:
>> Having worked through the API when it is first released, I find it to
> be highly forgettable (i.e. I have to re-read the docs each time I've
> revisited it).
Ethan Furman stoneleaf.us> writes:
>
> That's a decent point.
>
> So the plausible choices are, I think:
>
> - __fspath__ # File System Path -- possible confusion with Path
This would have my preference.
Regards
Antoine.
___
Python-Dev mailing l
Ethan Furman stoneleaf.us> writes:
> > I also think the more explicit name helps answer some of the type
> > signature questions that have arisen:
> >
> > 1. Does os.fspathname return rich Path objects? No, it returns names
> > as str objects
> > 2. Will file descriptors pass through os.fspa
Ethan Furman stoneleaf.us> writes:
>
> On 04/11/2016 07:56 AM, Antoine Pitrou wrote:
>
> >> 2) pathlib.Path accepts bytes --
> >
> > Does it? Or are you proposing such a change?
>
> It used to (I posted a couple examples from 3.5.0). I finally rebuilt
Brett Cannon python.org> writes:
> In the spirit of Python 3 I feel like bytes might not be needed in practice,
> but something like this with defaults of False will allow people to easily
> test all the various options.
>
>
>
> https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869a
Victor Stinner gmail.com> writes:
>
> Hi,
>
> 2016-04-14 22:42 GMT+02:00 Armin Rigo tunes.org>:
> > Hi Victor,
> >
> > On 14 April 2016 at 17:19, Victor Stinner
gmail.com> wrote:
> >> Each time a dictionary is created, the global
> >> version is incremented and the dictionary version is initia
On Fri, 18 Oct 2013 12:53:55 -0400
Brett Cannon wrote:
> importlib.machinery.FileFinder does a stat call to check if a path is a
> file if the package check failed. Now I'm willing to bet that the check is
> rather redundant as the file extension should be a dead give-away that
> something in a di
On Sat, 19 Oct 2013 21:41:17 +1000
Nick Coghlan wrote:
>
> Having noticed the discrepancy, I feel like it should be explicitly
> recorded somewhere in the language reference, I'm just not sure where.
Since it's a quirk, I don't think it should be mentioned in the
language reference. Also, see ht
On Sat, 19 Oct 2013 14:25:28 +0200 (CEST)
christian.heimes wrote:
>
> - .. note:: A fast implementation of *pbkdf2_hmac* is only available with
> - OpenSSL 1.0 and newer. The Python implementation uses an inline
> - version of :mod:`hmac` and is about three times slower. Contrary to
On Sat, 19 Oct 2013 15:36:02 +0200
Christian Heimes wrote:
> Am 19.10.2013 14:54, schrieb Antoine Pitrou:
> > On Sat, 19 Oct 2013 14:25:28 +0200 (CEST)
> > christian.heimes wrote:
> >>
> >> - .. note:: A fast implementation of *pbkdf2_hmac* is only available
On Sat, 19 Oct 2013 18:05:35 +0200
Christian Heimes wrote:
> Am 19.10.2013 16:59, schrieb Antoine Pitrou:
> > But that's a fringe situation. Any normal build of Python should be
> > compiled with OpenSSL support (and any decent binary build is). I think
> > the mention
On Sat, 19 Oct 2013 20:04:05 +0200
Victor Stinner wrote:
> Does Python officially support opsenssl < 1.0? Which OS uses such old
> version?
We try to support any reasonably modern POSIX-compliant system, e.g.
less than 10 years old.
Of course, we only "officially support" those platforms which ha
Le Mon, 21 Oct 2013 20:46:39 +1000,
Nick Coghlan a écrit :
> On 21 Oct 2013 12:44, "Raymond Hettinger"
> wrote:
> >
> > Two of the new context managers in contextlib are now wrapped in
> pass-through factory functions. The intent is to make the help() look
> cleaner. This practice does have dow
Le Mon, 21 Oct 2013 23:12:40 +1000,
Nick Coghlan a écrit :
> On 21 Oct 2013 22:10, "Antoine Pitrou" wrote:
> >
> > Le Mon, 21 Oct 2013 20:46:39 +1000,
> > Nick Coghlan a écrit :
> > > On 21 Oct 2013 12:44, "Raymond Hettinger"
> > >
Hello,
I've just discovered there is a little-known feature in site.py: if a
$PREFIX/lib/site-python exists (e.g. /usr/lib/site-python), it is added
to sys.path in addition to the versioned site-packages. But only under
Unix ("if os.sep == '/'").
Has anyone seen that feature in the real world? D
Le Tue, 22 Oct 2013 10:54:03 +0200,
Victor Stinner a écrit :
> Hi,
>
> Would it be possible to use os.pipe() on all OSes except AIX?
>
> Pipes and socket pairs may have minor differences, but some
> applications may rely on these minor differences. For example, is the
> buffer size the same? Fo
Le Wed, 23 Oct 2013 13:53:40 +0200,
Victor Stinner a écrit :
> "For the record, pipe I/O seems a little faster than socket I/O under
> Linux"
>
> In and old (2006) email on LKML (Linux kernel), I read:
> "as far as I know pipe() is now much faster than socketpair(),
> because pipe() uses the zer
Le Thu, 24 Oct 2013 00:38:02 +0200,
Christian Heimes a écrit :
> Am 23.10.2013 23:37, schrieb Charles-François Natali:
> > Hi,
> >
> > What's the current status of pathlib? Is it targeted for 3.4?
> >
> > It would be a really nice addition, and AFAICT it has already been
> > maturing a while on
On Mon, 28 Oct 2013 16:13:36 -0400
Benjamin Peterson wrote:
> 2013/10/28 Victor Stinner :
> > Hi,
> >
> > While working on a fix, I got an assertion error during Python
> > finalization because Python tried to import the "io" module whereas
> > the module was just unloaded. Python tried to import
Le Tue, 29 Oct 2013 10:38:23 +0100,
Victor Stinner a écrit :
> 2013/10/29 Georg Brandl :
> > Am 29.10.2013 01:19, schrieb victor.stinner:
> >> http://hg.python.org/cpython/rev/4ef4578db38a
> >> changeset: 86715:4ef4578db38a
> >> user:Victor Stinner
> >> date:Tue Oct 29 01:19:37
On Wed, 30 Oct 2013 16:34:33 +
Nigel Small wrote:
> It strikes me that there could be an alternative approach to some of the
> use cases discussed here. Instead of a new type of dictionary, the
> case-insensitivity problem could be solved with something akin to a *
> CaseInsensitiveString* cla
Hi Raymond,
On Wed, 30 Oct 2013 01:12:03 -0600
Raymond Hettinger wrote:
>
> On Oct 28, 2013, at 1:16 PM, Victor Stinner wrote:
>
> > so what is the
> > status of the PEP 455 (TransformDict)?
>
>
> I'm giving a thorough evaluation of the proposal
> and am devoting chunks of time each weekend
over again.
Regards
Antoine.
>
> If not, we should probably find someone at Upfront Systems to check
> the configuration.
>
> > Victor
> >
> > 2013/10/12 Antoine Pitrou :
> >>
> >> Opened issue at http://psf.upfronthosting.co.za/round
On lun., 2013-11-04 at 20:54 +0100, Victor Stinner wrote:
> 2013/11/4 M.-A. Lemburg :
> > Some things to try on the box:
> >
> > * ping6 2001:888:2000:d::a2 (that's python.org)
>
> $ ping6 -c 4 2001:888:2000:d::a2
[...]
On the box, not on your home machine!
Regards
Antoine.
__
Le 06/11/2013 06:41, Nick Coghlan a écrit :
The behaviour of mutating builtin containers while iterating over them
is formally undefined beyond "it won't segfault" (one of the few such
undefined behaviours in Python). The associated exceptions are thus
strictly "best effort given other constrain
Le 06/11/2013 21:39, Skip Montanaro a écrit :
-assert 1 <= month <= 12, month
+assert 1 <= month <= 12, 'month must be in 1..12'
In addition to Brett's comment, you might as well include the
offending value in your AssertionError message. For example, a value
of 0 probably tells you som
Le 07/11/2013 19:13, Christian Heimes a écrit :
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5.
Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to ar
Le 07/11/2013 22:42, Christian Heimes a écrit :
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
quite young.
It's available since 3.3
3.2 actually, while many code bases are still 2.x-compatible.
There's
Le 08/11/2013 17:39, Christian Heimes a écrit :
Am 08.11.2013 08:42, schrieb Antoine Pitrou:
3.2 actually, while many code bases are still 2.x-compatible.
There's no need to make migration more annoying right now.
There is also no need to hinder and delay future improvements for the
sake
On Wed, 13 Nov 2013 23:33:02 +0100 (CET)
christian.heimes wrote:
>
>
> +Small string optimization
> +=
> +
> +Hash functions like SipHash24 have a costly initialization and finalization
> +code that can dominate speed of the algorithm for very short strings. On the
> +o
On Fri, 15 Nov 2013 09:03:37 +1000
Nick Coghlan 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 attribute.
>
> This is completely the wrong approach. There's zero justification
On Fri, 15 Nov 2013 21:28:35 +1100
Steven D'Aprano wrote:
>
> One benefit is:
>
> import codecs
> codec = get_name_of_compression_codec()
> result = codecs.encode(data, codec)
That's a good point.
> If encoding/decoding is intended to be completely generic (even if 99%
> of the uses will be w
On Fri, 15 Nov 2013 21:45:31 +1000
Nick Coghlan wrote:
>
> The reason I'm now putting some effort into better documenting the
> status quo for codec handling in Python 3 and filing off some of the
> rough edges (rather than proposing adding any new APIs to Python 3.x)
> is because the users I car
On Fri, 15 Nov 2013 23:50:23 +1000
Nick Coghlan wrote:
>
> My perspective is that, in current Python, that *is* the right thing
> for people to do, and any hypothetical new API proposed for Python 3.5
> would do nothing to change what's right for Python 3.4 code (or Python
> 2/3 compatible code).
On Sat, 16 Nov 2013 00:46:15 +1000
Nick Coghlan wrote:
> On 16 November 2013 00:04, Antoine Pitrou wrote:
> >> Rather than the more useful:
> >>
> >> >>> b"abcdef".decode("hex")
> >> Traceback (most recent call last):
>
On Sat, 16 Nov 2013 19:44:51 +1000
Nick Coghlan wrote:
>
> Aye, that was my conclusion (hence my proposal on issue 7475 back in April).
>
> Can I take that observation as a +1 for restoring the aliases as well?
I see no harm in restoring the aliases personally, so +1 from me.
Regards
Antoine.
On Sat, 16 Nov 2013 17:34:15 +0200
Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
> > On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
> >> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
> >>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
On Sat, 16 Nov 2013 11:16:48 -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* existed.
Hello,
Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
the PEP 3154 implementation - pickle protocol 4.
I think it would be good to get the PEP and the implementation accepted
for 3.4. As far as I can say, this has been a low-controvery proposal,
and it brings fairly obvi
Hello,
In a (private) discussion about PEP 428 and pathlib, Guido proposed
that maybe NTPath should be renamed to WindowsPath, since the name is
more likely to stay relevant in the middle term. What do you think?
Regards
Antoine.
___
Python-Dev mail
On Sun, 17 Nov 2013 18:04:43 +1100
Steven D'Aprano 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 docstrings may be beneficial on memory-constrained
>
On Sun, 17 Nov 2013 21:27:24 +1100
Steven D'Aprano wrote:
> 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 wrote:
> > > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou
On Mon, 18 Nov 2013 07:48:27 -0800
Guido van Rossum wrote:
> On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka wrote:
>
> > 18.11.13 07:53, Tim Peters написав(ла):
> >
> > - Some easy sanity checking due to the tiny redundancy (if the byte
> >> immediately following the current frame is not a FR
On Sun, 17 Nov 2013 23:53:09 -0600
Tim Peters wrote:
>
> But I wonder why it isn't done with a new framing opcode instead (say,
> FRAME followed by 8-byte count). I suppose that would be like the
> "prefetch" idea, except that framing opcodes would be mandatory
> (instead of optional) in proto 4
On Mon, 18 Nov 2013 23:24:36 +0530
Avichal Dayal wrote:
> Hello,
>
> I'm Avichal Dayal and I'm new to this community rather the whole open
> source world.
>
> I've been "lurking" around for a while, reading bugs, code and asking
> relevant doubts on the core-mentorship mailing list.
>
> Now I i
On Mon, 18 Nov 2013 17:14:21 +0100
Antoine Pitrou wrote:
> On Sun, 17 Nov 2013 23:53:09 -0600
> Tim Peters wrote:
> >
> > But I wonder why it isn't done with a new framing opcode instead (say,
> > FRAME followed by 8-byte count). I suppose that would be like th
On Mon, 18 Nov 2013 16:02:31 -0600
Tim Peters wrote:
> [Guido]
> >> Clearly the framing is the weakest point of the PEP (== elicits the most
> >> bikeshedding). I am also unsure about the value of framing when pickles are
> >> written to strings.
>
> [Antoine]
> > It hasn't much value in that cas
On Mon, 18 Nov 2013 16:18:21 -0600
Tim Peters wrote:
>
> But it has a different kind of advantage: PREFETCH was optional. As
> Guido said, it's annoying to bloat the size of small pickles (which
> may, although individually small, occur in great numbers) by 8 bytes
> each. There's really no po
On Mon, 18 Nov 2013 16:25:07 -0600
Tim Peters wrote:
>
> [Antoine]
> > Are very small pickles that size-sensitive? I have the impression that
> > if 8 bytes vs. e.g. 15 bytes makes a difference for your application,
> > you'd be better off with a hand-made format.
>
> The difference between 8 an
Ok, how about merging the two sub-threads :-)
On Mon, 18 Nov 2013 16:44:59 -0600
Tim Peters wrote:
> [Antoine]
> > You can't know how much space the pickle will take until the pickling
> > ends, though, which makes it difficult to decide whether you want to
> > emit a PREFETCH opcode or not.
>
On Mon, 18 Nov 2013 16:44:59 -0600
Tim Peters wrote:
> [Tim]
> >> But it has a different kind of advantage: PREFETCH was optional. As
> >> Guido said, it's annoying to bloat the size of small pickles (which
> >> may, although individually small, occur in great numbers) by 8 bytes
> >> each. The
On Mon, 18 Nov 2013 18:50:01 -0600
Tim Peters wrote:
> [Antoine]
> > Yet another possibility: keep framing but use a variable-length
> > encoding for the frame size:
> >
> > - first byte: bits 7-5: N (= frame size bytes length - 1)
> > - first byte: bits 4-0: first 5 bits of frame size
> > - reman
On Mon, 18 Nov 2013 16:48:05 -0800
Guido van Rossum wrote:
>
> Food for thought: maybe we should have variable-encoding lengths for all
> opcodes, rather than the current cumbersome scheme?
Well, it's not that cumbersome... If you look at CPU encodings, they
also tend to have different opcodes f
On Tue, 19 Nov 2013 19:51:10 +0100
Antoine Pitrou wrote:
> On Mon, 18 Nov 2013 16:48:05 -0800
> Guido van Rossum wrote:
> >
> > Food for thought: maybe we should have variable-encoding lengths for all
> > opcodes, rather than the current cumbersome scheme?
>
>
On Tue, 19 Nov 2013 10:52:58 -0800
Guido van Rossum wrote:
> So why is framing different?
Because it doesn't use opcodes, so it can't use different opcodes to
differentiate between different frame size widths :-)
Regards
Antoine.
___
Python-Dev mailin
On Tue, 19 Nov 2013 11:05:45 -0800
Guido van Rossum wrote:
> So using an opcode for framing is out? (Sorry, I've lost track of the
> back-and-forth.)
It doesn't seem to bring anything, and it makes the overhead worse for
tiny pickles (since it will be two bytes at least, instead of one byte
with
On Tue, 19 Nov 2013 13:22:52 -0600
Tim Peters wrote:
> [Guido]
> > So using an opcode for framing is out? (Sorry, I've lost track of the
> > back-and-forth.)
>
> It was never in ;-) I'd *prefer* one, but not enough to try to block
> the PEP. As is, framing is done at a "lower level" than opcode
On Tue, 19 Nov 2013 21:25:34 +0100
"Martin v. Löwis" wrote:
> Am 19.11.13 20:59, schrieb Antoine Pitrou:
> > That's integrated to the built-in buffering. It's not really an
> > additional constraint: the frame sizes simply dictate how buffering
> > happe
Hello,
Guido has told me that he was ready to approve PEP 428 (pathlib) in its
latest amended form. Here is the last call for any comments or
arguments against approval, before Guido marks the PEP accepted (or
changes his mind :-)).
Regards
Antoine.
__
On Tue, 19 Nov 2013 15:17:06 -0600
Tim Peters wrote:
>
> > Note some drawbacks of frame opcodes:
> > - the decoder has to sanity check the frame opcodes (what if a frame
> > opcode is encountered when already inside a frame?)
> > - a pickle-mutating function such as pickletools.optimize() may n
On Tue, 19 Nov 2013 15:41:51 -0600
Tim Peters wrote:
> [Tim]
> >> ...
> >> But if some _other_ implementation of unpickling didn't give a hoot
> >> about framing, having an explicit opcode means that implementation
> >> could ignore the whole scheme very easily: just implement the FRAME
> >> opco
On Tue, 19 Nov 2013 17:02:15 -0500
Brett Cannon wrote:
> On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last ca
On Tue, 19 Nov 2013 16:06:22 -0600
Tim Peters wrote:
> [Antoine]
> >>> Ahah, ok, I see where you're going. But how many other implementations
> >>> of unpickling are there?
>
> [Tim]
> >> That's something you should have researched when writing the PEP ;-)
> >> How many implementations of Python
On Tue, 19 Nov 2013 23:05:07 +0100
"Martin v. Löwis" wrote:
> Am 19.11.13 21:28, schrieb Antoine Pitrou:
>
> > Well, unless you propose a patch before Saturday, I will happily ignore
> > your proposal.
>
> See
>
> http://bugs.python.org/file32709/framing
On Wed, 20 Nov 2013 00:56:13 +0100
"Martin v. Löwis" wrote:
> AFAICT, the real driving force is the desire to not read-ahead
> more than the pickle is long. This is what complicates the code.
> The easiest (and most space-efficient) solution to that problem
> would be to prefix the entire pickle w
On Wed, 20 Nov 2013 12:25:20 +
Garth Bushell wrote:
>
> I'm also quite uneasy on the case insensitive comparison on Windows as the
> File system NTFS is case sensitive.
>
> """Current Windows file systems, like NTFS, are case-sensitive; that is a
> readme.txt and a Readme.txt can exist in th
Hello,
I have decided to mark PEP 3156 accepted. This reflects the fact that
the implementation is now in the stdlib tree, and its API has been
pretty much validated during all previous discussions (mostly on the
tulip mailing-list).
I cannot stress enough that the main preoccupation right now s
On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou wrote:
>
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > ar
On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou wrote:
>
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > ar
On Wed, 20 Nov 2013 17:30:44 -0500
Barry Warsaw wrote:
> On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
>
> >Many customers are forced to stick with Python 2.X because of other products,
> >but they require a Python 2.X version which can be compiled using Visual
> >Studio 2010 or better.
there's no further opposition, I'd like to mark this PEP accepted
(or let someone else do it) in 24 hours, so that the implementation can
be integrated before Sunday.
Regards
Antoine.
On Sat, 16 Nov 2013 19:15:26 +0100
Antoine Pitrou wrote:
>
> Hello,
>
> Alexandre Vassalot
On Wed, 20 Nov 2013 14:43:26 -0800
Chris Barker wrote:
>
> By the way, for us dinosaurs is this going to exactly match the
> pathlib implementation that can be used with py2?
pathlib up to 0.8 (on PyPI) has a different API - since there were so
many changes done as part of the release process.
On Wed, 20 Nov 2013 18:45:53 -0600
Tim Peters wrote:
> [Antoine]
> > I have made two last-minute changes to the PEP:
> >
> > - addition of the FRAME opcode, as discussed with Tim, and keeping a
> > fixed 8-byte frame size
>
> Cool!
>
>
> > - addition of the MEMOIZE opcode, courtesy of Alexand
On Thu, 21 Nov 2013 01:51:59 +0100
Antoine Pitrou wrote:
> On Wed, 20 Nov 2013 14:43:26 -0800
> Chris Barker wrote:
> >
> > By the way, for us dinosaurs is this going to exactly match the
> > pathlib implementation that can be used with py2?
>
> pathlib up to 0.8
On Thu, 21 Nov 2013 09:19:27 +
Kristján Valur Jónsson wrote:
>
> For reasons of work and others, I never got round to creating that branch but
> recently Stackless development has picked up the pace to the point where we
> feel it necessary to break with strict 2.7 conformance.
Why is that?
On Thu, 21 Nov 2013 12:36:48 +
Kristján Valur Jónsson wrote:
> Yes, we have stackless 3.3
> But there is desire to have a 2.X version, with added fixes from 3.x, e.g.
> certain improvements in the
> standard library etc.
> It's the old argument: moving to 3.x is not an option for some users,
On Thu, 21 Nov 2013 18:43:37 -0500
Barry Warsaw wrote:
> On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote:
>
> >As usual, 'I am not a lawyer', but if Christian wants to push forward with
> >using 'Python 2.8', I suggest that he consult the PSF Trademark Committee and
> >lawyer first.
>
> Just to
On Fri, 22 Nov 2013 09:17:14 +1000
Nick Coghlan wrote:
>
> Skipping saving _source under -OO would probably be a good thing, but
> otherwise it's a public API with the usual backwards compatibility
> guarantees.
I think skipping saving _source under -OO should be a bugfix. It's
terribly weird an
On Fri, 22 Nov 2013 22:00:54 +1300
Richard Tew wrote:
>
> Was there any concern about the dozens of "Stackless Python 2.x" and
> "Stackless Python 3.x" versions that I have released over the years
> being a cause for confusion? Or more importantly, any actual problems
> experienced?
>
> Yet, su
Hello,
I've pushed pathlib to the repository. I'm hopeful there won't be
new buildbot failures because of it, but still, there may be some
platform-specific issues I'm unaware of.
I hope our Release Manager is doing ok :-)
Regards
Antoine.
___
Pyth
On Fri, 22 Nov 2013 18:35:20 +0100 (CET)
barry.warsaw wrote:
> http://hg.python.org/peps/rev/706fe4b8b148
> changeset: 5315:706fe4b8b148
> user:Barry Warsaw
> date:Fri Nov 22 12:35:10 2013 -0500
> summary:
> 3156 has also been committed.
The reason I haven't set "final" here
On Fri, 22 Nov 2013 17:44:55 +0100
Antoine Pitrou wrote:
>
> I've pushed pathlib to the repository. I'm hopeful there won't be
> new buildbot failures because of it, but still, there may be some
> platform-specific issues I'm unaware of.
Actually, there turn
On Fri, 22 Nov 2013 10:59:31 -0800
Ethan Furman wrote:
>
> > Yet, we're told we should adopt wacky version numbers like 10, or
> > rename our project from Stackless Python.
>
> Sometimes we have to do wacky stuff to avoid unnecessary confusion.
Or it can be "Stackless Python 2.7 Extended Life"
On Fri, 22 Nov 2013 21:02:14 +0100 (CET)
guido.van.rossum wrote:
> http://hg.python.org/cpython/rev/db6ae01a5f7f
> changeset: 87364:db6ae01a5f7f
> user:Guido van Rossum
> date:Fri Nov 22 11:57:35 2013 -0800
> summary:
> Add note to asyncore/asynchat recommending asyncio for ne
On Fri, 22 Nov 2013 21:45:17 +0100 (CET)
andrew.kuchling wrote:
> http://hg.python.org/cpython/rev/cce14bc9b675
> changeset: 87371:cce14bc9b675
> user:Andrew Kuchling
> date:Fri Nov 22 15:45:02 2013 -0500
> summary:
> Wording changes to pathlib docs.
>
> Only possibly-controv
On Sat, 23 Nov 2013 15:32:58 +0200
Serhiy Storchaka wrote:
> 22.11.13 18:44, Antoine Pitrou написав(ла):
> > I've pushed pathlib to the repository. I'm hopeful there won't be
> > new buildbot failures because of it, but still, there may be some
> > pla
Hello,
I've now pushed Alexandre's implementation, and the PEP is marked final.
Regards
Antoine.
On Sat, 16 Nov 2013 19:15:26 +0100
Antoine Pitrou wrote:
>
> Hello,
>
> Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> the PEP 3154 impleme
On Sun, 24 Nov 2013 05:58:24 +0100 (CET)
alexandre.vassalotti wrote:
> http://hg.python.org/cpython/rev/a68c303eb8dc
> changeset: 87486:a68c303eb8dc
> user:Alexandre Vassalotti
> date:Sat Nov 23 20:58:24 2013 -0800
> summary:
> Disable annoying tests which doesn't work optimiz
On Sun, 24 Nov 2013 11:47:42 -0500
Barry Warsaw wrote:
> On Nov 23, 2013, at 11:01 PM, Gregory P. Smith wrote:
>
> >http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l
>
> Cool thanks. Antoine, do you still want or need my buildbot, or can I take it
> off-line? (FWIW, because
Hello,
On Mon, 25 Nov 2013 11:00:09 +1300
Ben Hoyt wrote:
>
> 1) Someone on reddit.com/r/Python asked "Is the import going to be
> 'pathlib'? I thought the renaming going on of std lib things with the
> transition to Python 3 sought to remove the spurious usage of
> appending 'lib' to libs?" I
501 - 600 of 4909 matches
Mail list logo
