Another alternative I'd prefer to an ABI version bump: backporting the "C
runtime independence" aspects of the stable ABI to Python 2.7.
There are only a relatively small number of APIs that lead to the
requirement for consistent C runtimes, so allowing those to be excluded at
compile time would m
On 21 Nov 2013 10:33, "Antoine Pitrou" wrote:
>
> 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 wh
On Wed, Nov 20, 2013 at 5:36 PM, Christian Tismer wrote:
> Hey Barry,
>
>
> On 20.11.13 23:30, 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
On 20/11/2013 23:36, Christian Tismer wrote:
Hey Barry,
On 20.11.13 23:30, 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
On Nov 20, 2013, at 4:53 PM, Antoine Pitrou wrote:
>
> When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0
> on PyPI that will integrate the PEP's API.
Great, thanks!
Chris
> In the meantime, if you don't mind installing from VCS, you clone the
> Mercurial repo (https://bi
[Alexandre Vassalotti]
> Looking at the different options available to us:
>
> 1A. Mandatory framing
> (+) Allows the internal buffering layer of the Unpickler to rely
> on the presence of framing to simplify its implementation.
> (-) Forces all implementations of pickle to in
Yup. Agreed. Ship it!
On Wed, Nov 20, 2013 at 4:54 PM, Antoine Pitrou wrote:
> 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
> > > fix
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 PyPI) has a different API
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 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, Nov 20, 2013 at 1:39 PM, Giampaolo Rodola' wrote:
> Isn't this redundant?
>
> >>> Path.cwd()
> PosixPath('/home/antoine/pathlib')
>
> Probably this is just personal taste but I'd prefer the more explicit:
>
> >>> Path(os.getcwd())
> PosixPath('/home/antoine/pathlib')
>
> I understand all t
[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 Alexandre, which replaces
> PUT opcodes in protocol 4 and helps shrink the size
Hello,
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
- addition of the MEMOIZE opcode, courtesy of Alexandre, which replaces
PUT opcodes in protocol 4 and helps shrink the size of pickles
If ther
Yes Paul,
On 20.11.13 23:15, Paul Moore wrote:
On 20 November 2013 22:04, Christian Tismer wrote:
My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community
about the
validity of pep 404.
I don't want a python 2.7 that does not inst
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.
On 11/20/2013 5:30 PM, 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. This is considered an i
Hey Barry,
On 20.11.13 23:30, 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. This is conside
Hello,
I am trying to work on fixing issue 19494 (HTTPBasicAuthHandler
doesn't work with Github and other websites which require prior
Authorization header in the first request).
I have created this testing script calling GitHub v3 API using
new “authentication handlers” (they are subclasses
On Wed, Nov 20, 2013 at 12:52 PM, Christian Tismer wrote:
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
> I agree with this strategy in almost all consequences but this one:
>
> Many customers are forced to stick with Python 2.X beca
On 20/11/2013 22:01, Antoine Pitrou wrote:
pathlib imports many modules at startup, so for scripts for which
startup time is critical using os.path may still be the best option.
Will there be or is there a note to this effect in the docs?
--
Python is the second best programming language in
[Tim]
>> BTW, I'm not a web guy: in what way is HTTP chunked transfer mode
>> viewed as being flawed? Everything I ever read about it seemed to
>> think it was A Good Idea.
[Martin]
> It just didn't work for some time, see e.g.
>
> http://bugs.python.org/issue1486335
> http://bugs.python.org/iss
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. This is considered an improvement and not a bug fix,
>where I disa
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
> > arguments against approval, be
On 20 November 2013 22:04, Christian Tismer wrote:
> My question is not answered at all, sorry Joao!
> I did not ask a teacher for his opinion on Stackless, but the community
> about the
> validity of pep 404.
>
> I don't want a python 2.7 that does not install correctly, because people
> don't re
My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community
about the
validity of pep 404.
I don't want a python 2.7 that does not install correctly, because people
don't read instructions. And exactly that will happen if I submit a mo
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
> > arguments against approval, be
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
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind :-)).
>
Cong
On Tue, Nov 19, 2013 at 10: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 call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind
I'd say publishing a high profile installable code with a "python 2.8" name
would cause a lot of undesired confusion to start with.
I usually lecture on Python to present the language to college students and
I.T. workers - and explaining away the current versioning scheme (use
either 2.7 or 3.3) i
Howdy friends,
according to pep 404, there will never be an official Python 2.8.
The migration path is from 2.7 to 3.x.
I agree with this strategy in almost all consequences but this one:
Many customers are forced to stick with Python 2.X because of other
products, but they require a Python 2.X
Thanks Antoine!
I will stop pretending to myself that I can finish the PEP this week and
instead focus on getting the docs in the CPython repo bootstrapped.
I would also like to thank the many contributors to the design and
implementation. (I've tried to mention everyone in the PEP's
Acknowledgem
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
Am 20.11.13 17:04, schrieb Eric V. Smith:
> I think the confusion comes from the difference between what NTFS can do
> and what the Win32 (or whatever it's now called) layer allows you to do.
> Rumor has it that the old Posix subsystem allowed NTFS to create 2 files
> in the same directory that dif
On 2013-11-20, at 17:09 , Guido van Rossum wrote:
> On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>
> I'm also quite uneasy on the case insensitive comparison on Windows as the
> File system NTFS is case sensitive.
>
> No, it's case-preser
On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
>>
>
> No, it's case-preserving.
>
It's quite possible that you are both r
On 11/20/2013 09:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
>
> No, it's case-preserving.
>
>> """Current Windows file systems, like NTFS, are cas
A problem with chunked IIRC is that the frame headers are variable-length
(a CRLF followed by a hex number followed by some optional gunk followed by
CRLF) so you have to drop back into one-byte-at-a-time to read it. (Well, I
suppose you could read 5 bytes, which is the minimum: CR, LF, X, CR, LF,
Am 20.11.13 06:18, schrieb Tim Peters:
> BTW, I'm not a web guy: in what way is HTTP chunked transfer mode
> viewed as being flawed? Everything I ever read about it seemed to
> think it was A Good Idea.
It just didn't work for some time, see e.g.
http://bugs.python.org/issue1486335
http://bugs.
On Wed, Nov 20, 2013 at 4:49 AM, Antoine Pitrou wrote:
> 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
On 11/20/2013 04:25 AM, Garth Bushell wrote:
I'm also quite uneasy on the case insensitive comparison on Windows as the File
system NTFS is case sensitive.
No, it's case-preserving.
"""Current Windows file systems, like NTFS, are case-sensitive; that is a
readme.txt and a Readme.txt can ex
On 20 November 2013 23:38, Walter Dörwald wrote:
> On 20.11.13 02:28, Jim J. Jewett wrote:
>
>> [...]
>>
>> Instead of relying on introspection of .decodes_to and .encodes_to, it
>> would be useful to have charsetcodecs and tranformcodecs as entirely
>> different modules, with their own separate r
On 20.11.13 02:28, Jim J. Jewett wrote:
[...]
Instead of relying on introspection of .decodes_to and .encodes_to, it
would be useful to have charsetcodecs and tranformcodecs as entirely
different modules, with their own separate registries. I will even
note that the existing help(codecs) seems
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
I've noticed in pathlib.py the following error on line 39
if sys.getwindowsversion()[:2] >= (6, 0) and sys.version_info >= (3, 2):
it should be:-
if sys.getwindowsversion()[2:] >= (6, 0) and sys.version_info >= (3, 2):
I'm also quite uneasy on the case insensitive comparison on Windows as the
F
On Wed, Nov 20, 2013 at 11:03 PM, Steven D'Aprano wrote:
>> I *will* get confused over which
>> direction is encoding and which is decoding. (Removing .decode()
>> from the (unicode) str type in 3 does help a lot, if I have a Python 3
>> interpreter running to check against.)
>
> It took me a long
On Tue, Nov 19, 2013 at 05:28:48PM -0800, Jim J. Jewett wrote:
>
>
> (Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
>
> > Serhiy Storchaka wrote:
>
> > > If the transform() method will be added, I prefer to have only
> > > one transformation method and specify a direction by the
Am 20.11.2013 12:41, schrieb Victor Stinner:
> 2013/11/20 Victor Stinner :
>> It looks like dict, set and frozenset representation (repr(...))
>> now depends on the platform (probably 32 bit vs 64 bit), even if
>> PYTHONHASHSEED is set. I don't know if it's an issue or not.
>
> In Python 3.3, rep
2013/11/20 Victor Stinner :
> It looks like dict, set and frozenset representation (repr(...)) now
> depends on the platform (probably 32 bit vs 64 bit), even if
> PYTHONHASHSEED is set. I don't know if it's an issue or not.
In Python 3.3, repr(set("abcd")) with PYTHONHASHSEED=0 always give
"{'a',
2013/11/20 Christian Heimes :
> The PEP has landed in revision
> http://hg.python.org/cpython/rev/adb471b9cba1 . I don't expect any test
> failures as I have tested the PEP on a lot of platforms. The new code
> compiles and passes its tests on Linux, Windows, BSD, HUPX, Solaris with
> all supported
Am 20.11.2013 11:07, schrieb Nick Coghlan:
> Christian has indicated he now considers PEP 456, which adds an updated
> and configurable hash algorithm ready for pronouncement
> (http://www.python.org/dev/peps/pep-0456/)
>
> I am happy the PEP and the associated implementation represent a
> desirab
Christian has indicated he now considers PEP 456, which adds an updated and
configurable hash algorithm ready for pronouncement (
http://www.python.org/dev/peps/pep-0456/)
I am happy the PEP and the associated implementation represent a desirable
improvement to CPython, and approve of the proposal
On Tue, Nov 19, 2013 at 2:09 PM, Antoine Pitrou wrote:
>
> Well, I don't think it's a big deal to add a FRAME opcode if it doesn't
> change the current framing logic. I'd like to defer to Alexandre on this
> one, anyway.
Looking at the different options available to us:
1A. Mandatory framing
52 matches
Mail list logo
