Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Nick Coghlan 
On 22 Nov 2013 10:58, "Steve Dower"  wrote:
>
> Nick Coghlan wrote:
> > For 2.7.7, I think some combination of the two following ideas would be
worth
> > pursuing:
> > - a C runtime independent API flag (set by default on Windows when
building with
> > a compiler other than VS2008). This would largely be a backport of some
of the
> > stable ABI work from Python 3.
> > - getting Windows closer to the current Mac OS X situation by ensuring
that the
> > C runtime used directly affects the ABI flags and shared library names.
PyPI
> > would apply the Mac OS X guideline where extensions are expected to be
> > compatible with the python.org binaries.
>
> I don't really think either of these are necessary. With some changes to
Python's headers and some extra exports, it should be possible to
future-proof Python 2.7.7 against any new compilers, at least on Windows.
>
> What I have in mind is basically detecting the MSVC version in the
headers (there are preprocessor variables for this) and, if it isn't VC9,
substituting a different function for those that require FILE*. This
function/macro could call _get_osfhandle() and pass it to an API (built
into python27.dll) that calls _open_osfhandle() and forwards it to the
usual API.
>
> This should let any compiler be used for building extensions or hosting
python27.dll without affecting existing code or requiring changes to the
packages.
>
> > This would be the biggest change pushed through under the "make builds
work"
> > policy for the extended 2.7 lifecycle, but Microsoft's aggressive
approach to
> > deprecating old compilers and C runtimes means I think we don't have
much
> > choice.
>
> Ultimately, compilers are probably going to be deprecated more quickly
now that we're on a faster release cadence, which makes it more important
that Python 2.7 is prepared for an unknown future.
>
> > In the near term, if Stackless build to a different DLL name under
VS2010 and
> > make it clear to their users that extension compatibility issues are
possible
> > (or even likely) if they aren't rebuilt from source, then I think that
would be
> > compatible with the above proposal for a way forward.
> > Then we'd just need some volunteers to write and implement a PEP or two
:)
>
> I'm happy to work on a PEP and changes for what I described above, if
there's enough interest? I can also update distutils to detect and build
with any available compiler, though this may be more of a feature than we'd
want for 2.7 at this point.

That's part of what a PEP can help us decide, though, so if you're willing
to put one together, that would be great :)

Cheers,
Nick.

>
> Cheers,
> Steve
>
> > (Note, similar to the Mac OS X situation, I think we should do this
without
> > hosting any new interpreter variants on python.org - VS2010 and VS2013
source
> > builds would become separate build-from-source ecosystems for
extensions, using
> > sdists on PyPI as the default distribution mechanism)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Richard Tew 
Hi,

I've been following this thread and the specific issue of the strong
negative reaction to the name "Stackless Python 2.8", and I'm a bit
bothered by the whole experience.

Was there any concern about the name "Stackless Python 0.x" when
Christian released his original versions?  More importantly, has it
caused any real problems over the years?

https://mail.python.org/pipermail/python-announce-list/1999-July/000117.html

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, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.

https://mail.python.org/pipermail/python-dev/2013-November/130429.html
https://mail.python.org/pipermail/python-dev/2013-November/130466.html
https://mail.python.org/pipermail/python-dev/2013-November/130467.html
https://mail.python.org/pipermail/python-dev/2013-November/130495.html

We've been releasing a variant of Python with related version numbers
for over 14 years, under the name "Stackless Python x.x".  Now because
of a different version number, not only is there strong opposition to
us continuing to use this name, but people go so far as to talk about
trademarks as a way to prevent us using "Python" in there.

https://mail.python.org/pipermail/python-dev/2013-November/130435.html

We're not talking about releasing a Python 2.8 against anyone's wishes
here.  Or in _this specific case_, doing anything other than naming
something in a way we've been naming it for over a decade.  Yet it's
reached the point where people are alluding to ways to forcibly stop
us.

That there are people who would consider using the trademark to force
us to change the name we've been using without harm for 14 years,
worries me.  It's one thing to perhaps use it to stop someone scamming
Python users, and another to suggest using it as a weapon against us
for this?  Really?

Cheers,
Richard.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Martin v. Löwis 
Am 22.11.13 01:58, schrieb Steve Dower:

> I'm happy to work on a PEP and changes for what I described above, if
> there's enough interest? I can also update distutils to detect and
> build with any available compiler, though this may be more of a
> feature than we'd want for 2.7 at this point.

I don't think a PEP is necessary - Guido essentially pre-approved
changes needed to make Python 2.7 work with newer tools and operating
systems.

A patch for this would be appreciated - perhaps you would want
to put it into your sandbox on hg.python.org.

Regards,
Martin


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Nick Coghlan 
On 22 November 2013 19:00, Richard Tew  wrote:
> We're not talking about releasing a Python 2.8 against anyone's wishes
> here.  Or in _this specific case_, doing anything other than naming
> something in a way we've been naming it for over a decade.  Yet it's
> reached the point where people are alluding to ways to forcibly stop
> us.

Every previous case was a simple matter of "this is the Stackless
variant of Python X.Y". The difference in this case is that there is
*no* Python 2.8 (and a PEP stating explicitly that python-dev have no
intention of creating one) to create a variant, so this would have
meant the Stackless community taking the novel step of creating a new
feature release of Python 2.x, and hence taking up the burden of
defining the feature set of that release.

A few folks overreacted in their concern about the community confusion
such a move would inevitably create - *anything* called "Python 2.8"
is going to give the impression that we've changed our mind about 2.7
being the last feature release in the 2.x series, even if it has the
word Stackless in front of it.

We can almost certainly resolve the Windows ABI issue without the
Stackless community needing to take such a drastic step, though, so I
for one greatly appreciate Christian raising the question here and
giving us the opportunity to help out.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Chris Angelico 
On Fri, Nov 22, 2013 at 10:32 PM, Nick Coghlan  wrote:
> A few folks overreacted in their concern about the community confusion
> such a move would inevitably create - *anything* called "Python 2.8"
> is going to give the impression that we've changed our mind about 2.7
> being the last feature release in the 2.x series, even if it has the
> word Stackless in front of it.

>From what I understand of the discussion, the problem is only because
it's the specific value "2.8", which could plausibly be a Python
version number. Calling it "Stackless Python 10" wouldn't cause
confusion (don't remember who suggested that), as it's clearly not
part of the regular Python versioning system - you could say
"Stackless Python 10 is code compatible with Python 2.7" and there'd
be no confusion. But if, say, Red Hat release something called "Python
2.4.6-rhel", I would expect it to be entirely compatible with a
python.org Python 2.4 release, possibly with some additional bugfixes;
it says "2.4" in it, so I'm not going to go dig through its docs to
figure out what my code will run on. I certainly wouldn't expect it to
be "2.2 built with a new compiler", or "2.7 with additional libraries
added", or anything. It's all about how it reads at first glance.

In my personal opinion, I would very much like to see the 2.x line
*not* be supported indefinitely. Why are so many people still using
it? Because the impetus to shift is weaker than the inertia to stay.
How will that be changed? By strengthening the need to move on. If
anyone pledges to support a 2.x variant for the next couple of
decades, then python-list will have to deal with people not knowing
(and not saying) whether they're on 2.x or 3.x for probably another 30
years or more. I'd rather be able to stop warning people about input()
and non-Unicode strings and from __future__ import division.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 454 - tracemalloc - accepted

2013-11-22 Thread Stefan Krah 
Victor Stinner  wrote:
> 2013/11/21 Nick Coghlan :
> > Huzzah! Thanks to you both for getting this ready for inclusion :)
> 
> I now hope that someone will use it :-)

Congratulations!  I hope pyfailmalloc can go into 3.4, too.


Stefan Krah



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

2013-11-22 Thread anatoly techtonik 
On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson  wrote:
> 2013/11/15 anatoly techtonik :
>> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
>> wrote:
>>> 2013/11/12 anatoly techtonik :
 On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
 wrote:
> 2013/11/10 anatoly techtonik :
>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>
>> In Assign(expr* targets, expr value), why the first argument is a list?
>
> x = y = 42

 Thanks.

 Speaking of this ASDL. `expr* targets` means that multiple entities of
 `expr` under the name 'targets' can be passed to Assign statement.
 Assign uses them as left value. But `expr` definition contains things
 that can not be used as left side assignment targets:

 expr = BoolOp(boolop op, expr* values)
  | BinOp(expr left, operator op, expr right)
  ...
  | Str(string s) -- need to specify raw, unicode, etc?
  | Bytes(bytes s)
  | NameConstant(singleton value)
  | Ellipsis

  -- the following expression can appear in assignment context
  | Attribute(expr value, identifier attr, expr_context ctx)
  | Subscript(expr value, slice slice, expr_context ctx)
  | Starred(expr value, expr_context ctx)
  | Name(identifier id, expr_context ctx)
  | List(expr* elts, expr_context ctx)
  | Tuple(expr* elts, expr_context ctx)

 If I understand correctly, this is compiled into C struct definitions
 (Python-ast.c), and there is a code to traverse the structure, but
 where is code that validates that the structure is correct? Is it done
 on the first level - text file parsing, before ASDL is built? If so,
 then what is the role of this ADSL exactly that the first step is
 unable to solve?
>>>
>>> Only valid expression targets are allowed during AST construction. See
>>> set_expr_context in ast.c.
>>
>> Oh my. Now there is also CST in addition to AST. This stuff -
>> http://docs.python.org/devguide/ - badly needs diagrams about data
>> transformation toolchain from Python source code to machine
>> execution instructions. I'd like some pretty stuff, but raw blogdiag
>> hack will do the job http://blockdiag.com/en/blockdiag/index.html
>>
>> There is no set_expr_context in my copy of CPython code, which
>> seems to be some alpha of Python 3.4
>
> It's actually called set_context.

Ok. So what is the process?

 SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
--> AST --> BYTECODE

Is that right?

 Is it possible to fix ADSL to move `expr` that are allowed in Assign
 into `expr` subset? What effect will it achieve? I mean - will ADSL
 compiler complain about wrong stuff on the left side, or it will still
 be a role of some other component. Which one?
>>>
>>> I'm not sure what you mean by an `expr` subset.
>>
>> Transform this:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>  | Subscript(expr value, slice slice, expr_context ctx)
>>  | Starred(expr value, expr_context ctx)
>>  | Name(identifier id, expr_context ctx)
>>  | List(expr* elts, expr_context ctx)
>>  | Tuple(expr* elts, expr_context ctx)
>>
>> to this:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | expr_asgn
>>
>>  expr_asgn =
>>Attribute(expr value, identifier attr, expr_context ctx)
>>  | Subscript(expr value, slice slice, expr_context ctx)
>>  | Starred(expr value, expr_context ctx)
>>  | Name(identifier id, expr_context ctx)
>>  | List(expr* elts, expr_context ctx)
>>  | Tuple(expr* elts, expr_context ctx)
>
> I doubt ASDL will let you do that.

asdl.py  is plain broken - wrong number of arguments passed to
output function
asdl_c.py worked ok with fixed ASDL and generated - diff attached.
I don't know what to check further - on Windows without Visual Studio.
--
anatoly t.
--- C:/__py/_pydotorg/devinabox/cpython/Parser/Python-ast.c Fri Nov 22 
14:19:30 2013
+++ C:/__py/_pydotorg/devinabox/cpython/Parser/Python-ast.c-patched Fri Nov 
22 14:19:11 2013
@@ -161,10 +161,6 @@
 static PyTypeObject *Break_type;
 static PyTypeObject

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

2013-11-22 Thread Benjamin Peterson 
2013/11/22 anatoly techtonik :
> On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson  
> wrote:
>> 2013/11/15 anatoly techtonik :
>>> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
>>> wrote:
 2013/11/12 anatoly techtonik :
> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
> wrote:
>> 2013/11/10 anatoly techtonik :
>>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>>
>>> In Assign(expr* targets, expr value), why the first argument is a list?
>>
>> x = y = 42
>
> Thanks.
>
> Speaking of this ASDL. `expr* targets` means that multiple entities of
> `expr` under the name 'targets' can be passed to Assign statement.
> Assign uses them as left value. But `expr` definition contains things
> that can not be used as left side assignment targets:
>
> expr = BoolOp(boolop op, expr* values)
>  | BinOp(expr left, operator op, expr right)
>  ...
>  | Str(string s) -- need to specify raw, unicode, etc?
>  | Bytes(bytes s)
>  | NameConstant(singleton value)
>  | Ellipsis
>
>  -- the following expression can appear in assignment context
>  | Attribute(expr value, identifier attr, expr_context ctx)
>  | Subscript(expr value, slice slice, expr_context ctx)
>  | Starred(expr value, expr_context ctx)
>  | Name(identifier id, expr_context ctx)
>  | List(expr* elts, expr_context ctx)
>  | Tuple(expr* elts, expr_context ctx)
>
> If I understand correctly, this is compiled into C struct definitions
> (Python-ast.c), and there is a code to traverse the structure, but
> where is code that validates that the structure is correct? Is it done
> on the first level - text file parsing, before ASDL is built? If so,
> then what is the role of this ADSL exactly that the first step is
> unable to solve?

 Only valid expression targets are allowed during AST construction. See
 set_expr_context in ast.c.
>>>
>>> Oh my. Now there is also CST in addition to AST. This stuff -
>>> http://docs.python.org/devguide/ - badly needs diagrams about data
>>> transformation toolchain from Python source code to machine
>>> execution instructions. I'd like some pretty stuff, but raw blogdiag
>>> hack will do the job http://blockdiag.com/en/blockdiag/index.html
>>>
>>> There is no set_expr_context in my copy of CPython code, which
>>> seems to be some alpha of Python 3.4
>>
>> It's actually called set_context.
>
> Ok. So what is the process?
>
>  SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
> --> AST --> BYTECODE
>
> Is that right?

I don't know what sentence stream is, but otherwise looks right.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Martin v. Löwis 
Am 22.11.13 10:00, schrieb Richard Tew:
> That there are people who would consider using the trademark to force
> us to change the name we've been using without harm for 14 years,
> worries me.  It's one thing to perhaps use it to stop someone scamming
> Python users, and another to suggest using it as a weapon against us
> for this?  Really?

Unfortunately, Christian's original question was unclear. If his plan
had been to release "Python 2.8" (as his original question suggested),
then he would have faced quite some opposition (and, in a sense,
releasing a "python28.dll" is quite close to that).

IMO, calling it "Stackless Python 2.8" is fine, and I also believe that
this complies with the current trademark policy. The objective of this
policy is to give Python companies equal choices in naming their
products, i.e. nobody would be allowed to call something "Python"
without further qualification (except for the traditional CPython
release).

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

2013-11-22 Thread anatoly techtonik 
On Fri, Nov 22, 2013 at 3:29 PM, Benjamin Peterson  wrote:
> 2013/11/22 anatoly techtonik :
>> On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson  
>> wrote:
>>> 2013/11/15 anatoly techtonik :
 On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
 wrote:
> 2013/11/12 anatoly techtonik :
>> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
>> wrote:
>>> 2013/11/10 anatoly techtonik :
 http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl

 In Assign(expr* targets, expr value), why the first argument is a list?
>>>
>>> x = y = 42
>>
>> Thanks.
>>
>> Speaking of this ASDL. `expr* targets` means that multiple entities of
>> `expr` under the name 'targets' can be passed to Assign statement.
>> Assign uses them as left value. But `expr` definition contains things
>> that can not be used as left side assignment targets:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>  | Subscript(expr value, slice slice, expr_context ctx)
>>  | Starred(expr value, expr_context ctx)
>>  | Name(identifier id, expr_context ctx)
>>  | List(expr* elts, expr_context ctx)
>>  | Tuple(expr* elts, expr_context ctx)
>>
>> If I understand correctly, this is compiled into C struct definitions
>> (Python-ast.c), and there is a code to traverse the structure, but
>> where is code that validates that the structure is correct? Is it done
>> on the first level - text file parsing, before ASDL is built? If so,
>> then what is the role of this ADSL exactly that the first step is
>> unable to solve?
>
> Only valid expression targets are allowed during AST construction. See
> set_expr_context in ast.c.

 Oh my. Now there is also CST in addition to AST. This stuff -
 http://docs.python.org/devguide/ - badly needs diagrams about data
 transformation toolchain from Python source code to machine
 execution instructions. I'd like some pretty stuff, but raw blogdiag
 hack will do the job http://blockdiag.com/en/blockdiag/index.html

 There is no set_expr_context in my copy of CPython code, which
 seems to be some alpha of Python 3.4
>>>
>>> It's actually called set_context.
>>
>> Ok. So what is the process?
>>
>>  SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
>> --> AST --> BYTECODE
>>
>> Is that right?
>
> I don't know what sentence stream is, but otherwise looks right.

I mean that when you have TOKENS, you need to validate that their
order is valid and throw errors to console if it is not. Like every sentence
should have certain word order to make sense, you won't be able to
construct CST from tokens that are placed in wrong order. Right?

Or is CST itself a tree of tokens, which position is validated when the
tree is transformed to AST?


FWIW, I've modified my astdump project to make it easy to explore
Python AST and experiment with it. This dataset shows how to create
coverage for AST transformations (visitors)
https://bitbucket.org/techtonik/astdump/src/tip/dataset/?at=default
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

2013-11-22 Thread Brett Cannon 
On Fri, Nov 22, 2013 at 7:29 AM, Benjamin Peterson wrote:

> 2013/11/22 anatoly techtonik :
> > On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson 
> wrote:
> >> 2013/11/15 anatoly techtonik :
> >>> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson <
> [email protected]> wrote:
>  2013/11/12 anatoly techtonik :
> > On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson <
> [email protected]> wrote:
> >> 2013/11/10 anatoly techtonik :
> >>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
> >>>
> >>> In Assign(expr* targets, expr value), why the first argument is a
> list?
> >>
> >> x = y = 42
> >
> > Thanks.
> >
> > Speaking of this ASDL. `expr* targets` means that multiple entities
> of
> > `expr` under the name 'targets' can be passed to Assign statement.
> > Assign uses them as left value. But `expr` definition contains things
> > that can not be used as left side assignment targets:
> >
> > expr = BoolOp(boolop op, expr* values)
> >  | BinOp(expr left, operator op, expr right)
> >  ...
> >  | Str(string s) -- need to specify raw, unicode, etc?
> >  | Bytes(bytes s)
> >  | NameConstant(singleton value)
> >  | Ellipsis
> >
> >  -- the following expression can appear in assignment context
> >  | Attribute(expr value, identifier attr, expr_context ctx)
> >  | Subscript(expr value, slice slice, expr_context ctx)
> >  | Starred(expr value, expr_context ctx)
> >  | Name(identifier id, expr_context ctx)
> >  | List(expr* elts, expr_context ctx)
> >  | Tuple(expr* elts, expr_context ctx)
> >
> > If I understand correctly, this is compiled into C struct definitions
> > (Python-ast.c), and there is a code to traverse the structure, but
> > where is code that validates that the structure is correct? Is it
> done
> > on the first level - text file parsing, before ASDL is built? If so,
> > then what is the role of this ADSL exactly that the first step is
> > unable to solve?
> 
>  Only valid expression targets are allowed during AST construction. See
>  set_expr_context in ast.c.
> >>>
> >>> Oh my. Now there is also CST in addition to AST. This stuff -
> >>> http://docs.python.org/devguide/ - badly needs diagrams about data
> >>> transformation toolchain from Python source code to machine
> >>> execution instructions. I'd like some pretty stuff, but raw blogdiag
> >>> hack will do the job http://blockdiag.com/en/blockdiag/index.html
> >>>
> >>> There is no set_expr_context in my copy of CPython code, which
> >>> seems to be some alpha of Python 3.4
> >>
> >> It's actually called set_context.
> >
> > Ok. So what is the process?
> >
> >  SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
> > --> AST --> BYTECODE
> >
> > Is that right?
>
> I don't know what sentence stream is, but otherwise looks right.


If you want more of an overview:
http://pyvideo.org/video/2331/from-source-to-code-how-cpythons-compiler-works
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Ethan Furman 

On 11/22/2013 01:00 AM, Richard Tew wrote:


[snip]

Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.


Because there is no CPython 2.8 to mirror, and we've said there will not be one.

It certainly didn't help that this was presented one week before the feature freeze deadline for 3.4 and Christian 
stated [1] his "2.8" release was going to happen in one week unless we talked him out of it.




We're not talking about releasing a Python 2.8 against anyone's wishes
here.


Having "Python 2.8" in the name is going to be a PR nightmare.  Other names 
have been suggested.



Or in _this specific case_, doing anything other than naming
something in a way we've been naming it for over a decade.


When has Stackless created a version that didn't mirror the CPython version?  If you haven't, then you are doing 
something different.




That there are people who would consider using the trademark to force
us to change the name we've been using without harm for 14 years,
worries me.


This concern came about because of the misapprehension that the name would be "Python 
2.8" with no "Stackless" in front.

--
~Ethan~

[1] https://mail.python.org/pipermail/python-dev/2013-November/130437.html

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Antoine Pitrou 
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, suddenly, the chance that we may release a "Stackless Python
> 2.8", is a concern.

It is, as long as there is "Python 2.8" in it: it will breed confusion
amongst the 99% of non-experts our community is composed of.

To be clear: I don't think anyone would go after you for doing so
(perhaps Barry will play a bass solo? :-)), but it would still be a
shame IMHO.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Barry Warsaw 
On Nov 22, 2013, at 03:55 PM, Antoine Pitrou wrote:

>(perhaps Barry will play a bass solo? :-))

Now, now, we don't want to give Chris incentive, do we? :)

-Barry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Buildbot categories

2013-11-22 Thread Eric Snow 
Is there a listing of buildbot categories (3.x.stable, custom-stable,
etc.)?  The best I could find was http://python.org/dev/buildbot/.  I
couldn't find it at http://buildbot.python.org/ or in the devguide,
both places where I expected to find such a list.  Thanks!

-eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 451 (ModuleSpec) has landed

2013-11-22 Thread Eric Snow 
The bulk of PEP 451 (all but the "fluffy" parts as Brett called them
) is now committed to default.  We are tracking the remaining
items as dependencies of http://bugs.python.org/issue18864.

http://hg.python.org/cpython/rev/07229c6104b1
changeset:   87347:07229c6104b1
user:Eric Snow 
date:Fri Nov 22 09:05:39 2013 -0700
summary:   Implement PEP 451 (ModuleSpec).

-eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 451 (ModuleSpec) has landed

2013-11-22 Thread Eric Snow 
On Fri, Nov 22, 2013 at 9:36 AM, Eric Snow  wrote:
> The bulk of PEP 451 (all but the "fluffy" parts as Brett called them
> ) is now committed to default.

I'm looking into buildbot failures (on Windows of course).

-eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 428 (pathlib) now committed

2013-11-22 Thread Antoine Pitrou 

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.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Christian Tismer 

On 22/11/13 13:47, "Martin v. Löwis" wrote:

Am 22.11.13 10:00, schrieb Richard Tew:

That there are people who would consider using the trademark to force
us to change the name we've been using without harm for 14 years,
worries me.  It's one thing to perhaps use it to stop someone scamming
Python users, and another to suggest using it as a weapon against us
for this?  Really?

Unfortunately, Christian's original question was unclear. If his plan
had been to release "Python 2.8" (as his original question suggested),
then he would have faced quite some opposition (and, in a sense,
releasing a "python28.dll" is quite close to that).


The discussion is over, but I cannot let this comment go through without
citing my original question, again:


My question
---

I have created a very clean Python 2.7.6+ based CPython with the 
Stackless
additions, that compiles with VS 2010, using the adapted project 
structure
of Python 3.3.X, and I want to publish that on the Stackless website 
as the
official "Stackless Python 2.8". If you consider Stackless as official 
;-) .


Can it be that these sentences have morphed into something different
when going out to the mailing list? Or maybe there is a filter in the 
brains?

If one removes the word "Stackless" everywhere, the above text reads
still almost syntactic correctly, but changes it's meaning a lot.

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 428 (pathlib) now committed

2013-11-22 Thread Victor Stinner 
2013/11/22 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
> platform-specific issues I'm unaware of.

A PEP wouldn't be successful if it doesn't break any buildbot. PEP 451
was successful, as yours :-D
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1000

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

2013-11-22 Thread Eli Bendersky 
On Fri, Nov 22, 2013 at 3:21 AM, anatoly techtonik wrote:

> On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson 
> wrote:
> > 2013/11/15 anatoly techtonik :
> >> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson 
> wrote:
> >>> 2013/11/12 anatoly techtonik :
>  On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson <
> [email protected]> wrote:
> > 2013/11/10 anatoly techtonik :
> >> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
> >>
> >> In Assign(expr* targets, expr value), why the first argument is a
> list?
> >
> > x = y = 42
> 
>  Thanks.
> 
>  Speaking of this ASDL. `expr* targets` means that multiple entities of
>  `expr` under the name 'targets' can be passed to Assign statement.
>  Assign uses them as left value. But `expr` definition contains things
>  that can not be used as left side assignment targets:
> 
>  expr = BoolOp(boolop op, expr* values)
>   | BinOp(expr left, operator op, expr right)
>   ...
>   | Str(string s) -- need to specify raw, unicode, etc?
>   | Bytes(bytes s)
>   | NameConstant(singleton value)
>   | Ellipsis
> 
>   -- the following expression can appear in assignment context
>   | Attribute(expr value, identifier attr, expr_context ctx)
>   | Subscript(expr value, slice slice, expr_context ctx)
>   | Starred(expr value, expr_context ctx)
>   | Name(identifier id, expr_context ctx)
>   | List(expr* elts, expr_context ctx)
>   | Tuple(expr* elts, expr_context ctx)
> 
>  If I understand correctly, this is compiled into C struct definitions
>  (Python-ast.c), and there is a code to traverse the structure, but
>  where is code that validates that the structure is correct? Is it done
>  on the first level - text file parsing, before ASDL is built? If so,
>  then what is the role of this ADSL exactly that the first step is
>  unable to solve?
> >>>
> >>> Only valid expression targets are allowed during AST construction. See
> >>> set_expr_context in ast.c.
> >>
> >> Oh my. Now there is also CST in addition to AST. This stuff -
> >> http://docs.python.org/devguide/ - badly needs diagrams about data
> >> transformation toolchain from Python source code to machine
> >> execution instructions. I'd like some pretty stuff, but raw blogdiag
> >> hack will do the job http://blockdiag.com/en/blockdiag/index.html
> >>
> >> There is no set_expr_context in my copy of CPython code, which
> >> seems to be some alpha of Python 3.4
> >
> > It's actually called set_context.
>
> Ok. So what is the process?
>
>  SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
> --> AST --> BYTECODE
>
> Is that right?
>
>  Is it possible to fix ADSL to move `expr` that are allowed in Assign
>  into `expr` subset? What effect will it achieve? I mean - will ADSL
>  compiler complain about wrong stuff on the left side, or it will still
>  be a role of some other component. Which one?
> >>>
> >>> I'm not sure what you mean by an `expr` subset.
> >>
> >> Transform this:
> >>
> >> expr = BoolOp(boolop op, expr* values)
> >>  | BinOp(expr left, operator op, expr right)
> >>  ...
> >>  | Str(string s) -- need to specify raw, unicode, etc?
> >>  | Bytes(bytes s)
> >>  | NameConstant(singleton value)
> >>  | Ellipsis
> >>
> >>  -- the following expression can appear in assignment context
> >>  | Attribute(expr value, identifier attr, expr_context ctx)
> >>  | Subscript(expr value, slice slice, expr_context ctx)
> >>  | Starred(expr value, expr_context ctx)
> >>  | Name(identifier id, expr_context ctx)
> >>  | List(expr* elts, expr_context ctx)
> >>  | Tuple(expr* elts, expr_context ctx)
> >>
> >> to this:
> >>
> >> expr = BoolOp(boolop op, expr* values)
> >>  | BinOp(expr left, operator op, expr right)
> >>  ...
> >>  | Str(string s) -- need to specify raw, unicode, etc?
> >>  | Bytes(bytes s)
> >>  | NameConstant(singleton value)
> >>  | Ellipsis
> >>
> >>  -- the following expression can appear in assignment context
> >>  | expr_asgn
> >>
> >>  expr_asgn =
> >>Attribute(expr value, identifier attr, expr_context ctx)
> >>  | Subscript(expr value, slice slice, expr_context ctx)
> >>  | Starred(expr value, expr_context ctx)
> >>  | Name(identifier id, expr_context ctx)
> >>  | List(expr* elts, expr_context ctx)
> >>  | Tuple(expr* elts, expr_context ctx)
> >
> > I doubt ASDL will let you do that.
>
> asdl.py  is plain broken - wrong number of arguments passed to
> output function
> asdl_c.py worked ok with fixed ASDL and generated - diff attached.
> I don't know what to check further - on Windo

[Python-Dev] Summary of Python tracker Issues

2013-11-22 Thread Python tracker 

ACTIVITY SUMMARY (2013-11-15 - 2013-11-22)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4280 (+15)
  closed 27206 (+87)
  total  31486 (+102)

Open issues with patches: 1972 


Issues opened (81)
==

#17134: Use Windows' certificate store for CA certs
http://bugs.python.org/issue17134  reopened by haypo

#19613: test_nntplib: sporadic failures, test_article_head_body()
http://bugs.python.org/issue19613  opened by haypo

#19614: support.temp_cwd should use support.rmtree
http://bugs.python.org/issue19614  opened by r.david.murray

#19615: "ImportError: dynamic module does not define init function" wh
http://bugs.python.org/issue19615  opened by ecatmur

#19616: Fix test.test_importlib.util.test_both() to set __module__
http://bugs.python.org/issue19616  opened by brett.cannon

#19618: test_sysconfig_module fails on Ubuntu 12.04
http://bugs.python.org/issue19618  opened by berker.peksag

#19619: Blacklist base64, hex, ... codecs from bytes.decode() and str.
http://bugs.python.org/issue19619  opened by haypo

#19620: tokenize documentation contains typos (argment instead of argu
http://bugs.python.org/issue19620  opened by cjwelborn

#19622: Default buffering for input and output pipes in subprocess mod
http://bugs.python.org/issue19622  opened by vadmium

#19623: Support for writing aifc to unseekable file
http://bugs.python.org/issue19623  opened by serhiy.storchaka

#19624: Switch constants in the errno module to IntEnum
http://bugs.python.org/issue19624  opened by serhiy.storchaka

#19626: test_email and Lib/email/_policybase.py failures with -OO
http://bugs.python.org/issue19626  opened by ezio.melotti

#19627: python open built-in function - "updating" is not defined
http://bugs.python.org/issue19627  opened by Bulwersator

#19628: maxlevels -1 on compileall for unlimited recursion
http://bugs.python.org/issue19628  opened by Sworddragon

#19629: support.rmtree fails on symlinks under Windows
http://bugs.python.org/issue19629  opened by pitrou

#19630: marshal.dump cannot write to temporary file
http://bugs.python.org/issue19630  opened by lm1

#19631: "exec" BNF in simple statements
http://bugs.python.org/issue19631  opened by grubert

#19632: doc build warning
http://bugs.python.org/issue19632  opened by pitrou

#19635: asyncio should not depend on concurrent.futures, it is not alw
http://bugs.python.org/issue19635  opened by haypo

#19636: Fix usage of MAX_PATH in posixmodule.c
http://bugs.python.org/issue19636  opened by haypo

#19638: dtoa: conversion from '__int64' to 'int', possible loss of dat
http://bugs.python.org/issue19638  opened by christian.heimes

#19639: Improve re match objects display
http://bugs.python.org/issue19639  opened by Claudiu.Popa

#19640: Drop _source attribute of namedtuple
http://bugs.python.org/issue19640  opened by haypo

#19641: Add audioop.byteswap()
http://bugs.python.org/issue19641  opened by serhiy.storchaka

#19642: shutil to support equivalent of: rm -f /dir/*
http://bugs.python.org/issue19642  opened by ivan.radic

#19643: shutil rmtree fails on readonly files in Windows
http://bugs.python.org/issue19643  opened by ivan.radic

#19645: decouple unittest assertions from the TestCase class
http://bugs.python.org/issue19645  opened by Gregory.Salvan

#19648: Empty tests in pickletester need to be implemented or removed
http://bugs.python.org/issue19648  opened by zach.ware

#19650: test_multiprocessing_spawn.test_mymanager_context() crashed wi
http://bugs.python.org/issue19650  opened by haypo

#19652: test_asyncio: test_subprocess_send_signal() hangs on buildbot 
http://bugs.python.org/issue19652  opened by haypo

#19654: test_tkinter sporadic failures on "x86 Tiger 3.x" buildbot
http://bugs.python.org/issue19654  opened by haypo

#19655: Replace the ASDL parser carried with CPython
http://bugs.python.org/issue19655  opened by eli.bendersky

#19656: Add Py3k warning for non-ascii bytes literals
http://bugs.python.org/issue19656  opened by serhiy.storchaka

#19658: inspect.getsource weird case
http://bugs.python.org/issue19658  opened by Ronny.Pfannschmidt

#19659: Document Argument Clinic?
http://bugs.python.org/issue19659  opened by haypo

#19660: decorator syntax: allow testlist instead of just dotted_name
http://bugs.python.org/issue19660  opened by james

#19661: AIX: Python: RuntimeError "invalid slot offset when importing 
http://bugs.python.org/issue19661  opened by dellair.jie

#19662: smtpd.py should not decode utf-8
http://bugs.python.org/issue19662  opened by lpolzer

#19663: Not so correct error message when initializing defaultdict
http://bugs.python.org/issue19663  opened by vajrasky

#19665: test_logging fails with SMTPHandler timeout
http://bugs.python.org/issue19665  opened by canisdirus

#19666: Format string for ASCII unicode or bytes-like object as readon
http://bugs.python.org/issue19666

Re: [Python-Dev] PEP 428 (pathlib) now committed

2013-11-22 Thread anatoly techtonik 
It was too fast. I didn't had a chance to send the comments.
--
anatoly t.


On Fri, Nov 22, 2013 at 7:44 PM, Antoine Pitrou  wrote:
>
> 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.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Martin v. Löwis 
Am 22.11.13 17:54, schrieb Christian Tismer:
> The discussion is over, but I cannot let this comment go through without
> citing my original question, again:
> 
>> My question
>> ---
>>
>> I have created a very clean Python 2.7.6+ based CPython with the
>> Stackless
>> additions, that compiles with VS 2010, using the adapted project
>> structure
>> of Python 3.3.X, and I want to publish that on the Stackless website
>> as the
>> official "Stackless Python 2.8". If you consider Stackless as official
>> ;-) .
> 
> Can it be that these sentences have morphed into something different
> when going out to the mailing list? Or maybe there is a filter in the
> brains?
> If one removes the word "Stackless" everywhere, the above text reads
> still almost syntactic correctly, but changes it's meaning a lot.

Hmm. This isn't the original *question*. Instead, the question read

# Can I rely on PEP 404 that the "Python 2.8" namespace never will clash
# with CPython?

So while the word "Stackless" wasn't removed everywhere, it certainly
wasn't in the question.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 451 (ModuleSpec) has landed

2013-11-22 Thread Brett Cannon 
On Fri, Nov 22, 2013 at 11:37 AM, Eric Snow wrote:

> On Fri, Nov 22, 2013 at 9:36 AM, Eric Snow 
> wrote:
> > The bulk of PEP 451 (all but the "fluffy" parts as Brett called them
> > ) is now committed to default.
>
> I'm looking into buildbot failures (on Windows of course).


.. which have now been fixed.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] peps: 3156 has also been committed.

2013-11-22 Thread Antoine Pitrou 
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 is that AFAIK, Guido still has to
check the PEP conforms to the implementation. I don't know if that
warrants a different label.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Steve Dower 
Martin v. Löwis wrote:
> Am 22.11.13 01:58, schrieb Steve Dower:
> 
>> I'm happy to work on a PEP and changes for what I described above, if
>> there's enough interest? I can also update distutils to detect and
>> build with any available compiler, though this may be more of a
>> feature than we'd want for 2.7 at this point.
> 
> I don't think a PEP is necessary - Guido essentially pre-approved changes 
> needed
> to make Python 2.7 work with newer tools and operating systems.

I'd really want to update distutils.msvc9compiler to detect later versions as 
well, since that would make 'pip install' work properly for a large (majority?) 
of users for a large (majority?) of packages with extension modules. Some may 
consider this PEP-worthy (or at least worth arguing about), though I'm happy to 
just contribute a patch. (Not referring to my existing patch for this - I have 
a far more compatible approach in mind.)

There's probably also value in making the same changes to Python 3.4. The 
stable ABI is solving a different problem, though it also made it safer to 

I'm also getting in touch with my colleague who currently owns MSVCRT to figure 
out the full scope of what may happen once we start allowing mismatched 
versions in the same process. Hopefully there isn't much, but it will certainly 
be worth writing up somewhere - PEP or developer docs, doesn't really bother 
me. We may also want to fail builds that use functionality known to conflict - 
setlocale() comes to mind.
 
> A patch for this would be appreciated - perhaps you would want to put it into
> your sandbox on hg.python.org.

I don't have a sandbox - how can I get one?

Cheers,
Steve
 
> Regards,
> Martin


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 428 (pathlib) now committed

2013-11-22 Thread Antoine Pitrou 
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 out to be two platform-specific issues:

- test_glob() failure under POSIX case-insensitive filesystems (in
  other words, OS X :-)): http://bugs.python.org/issue19718

- test_touch_common() failure under the Windows buildbot:
  http://bugs.python.org/issue19715

I'd be glad to have help or insight from people experts with those
platforms on the issues above!

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Martin v. Löwis 
Am 22.11.13 19:10, schrieb Steve Dower:
> I'd really want to update distutils.msvc9compiler to detect later
> versions as well, since that would make 'pip install' work properly
> for a large (majority?) of users for a large (majority?) of packages
> with extension modules. Some may consider this PEP-worthy (or at
> least worth arguing about), though I'm happy to just contribute a
> patch. (Not referring to my existing patch for this - I have a far
> more compatible approach in mind.)

A PEP on 2.7 seems questionable - if this would really need a PEP,
it would be right out (IMO). A PEP would ask for community input,
weighing possibly different design choices.

Instead, I think this needs explicit RM approval, such as any other
borderline bugfix patch. I'd personally support it, including any
distutils change (assuming the changes "look" backwards-compatible) -
but it still would be for Benjamin to rule about it.

> There's probably also value in making the same changes to Python 3.4.

Perhaps. However, Python 3.4 is likely being replaced before VS 2010
ends its life, and people will be more quick to forward-port to 3.5.

> I'm also getting in touch with my colleague who currently owns MSVCRT
> to figure out the full scope of what may happen once we start
> allowing mismatched versions in the same process. 

There used to be an MSDN article about it, but I think it was
incomplete. It mentioned (IIRC) a) locale, b) malloc, c) struct FILE.
Not sure whether it mentioned CRT file handles, and I'm fairly
sure that it didn't mention errno. I also don't think that timezone
issues were mentioned (although there used to be a separate article
about CRT timezones).

So if you can get somebody to compile a complete list, publishing it
as a KB article would certainly be appreciated beyond the Python
project.

>> A patch for this would be appreciated - perhaps you would want to
>> put it into your sandbox on hg.python.org.
> 
> I don't have a sandbox - how can I get one?

You are not a Python committer yet, are you? If you are, go to
hg.python.org/cpython, and invoke the server-side clone. If you
are not - does your company agree if you would become one?

In any case, patches or a clone on bitbucket would work just
as well.

Regards,
Martin


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Ethan Furman 

[Redirecting to Python Dev]

On 11/22/2013 10:25 AM, Richard Tew wrote:

On Sat, Nov 23, 2013 at 3:16 AM, Ethan Furman  wrote:

On 11/22/2013 01:00 AM, Richard Tew wrote:

Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.


Because there is no CPython 2.8 to mirror, and we've said there will not be
one.

It certainly didn't help that this was presented one week before the feature
freeze deadline for 3.4 and Christian stated [1] his "2.8" release was going
to happen in one week unless we talked him out of it.



We're not talking about releasing a Python 2.8 against anyone's wishes
here.


Having "Python 2.8" in the name is going to be a PR nightmare.  Other names
have been suggested.


But how is it going to be a PR nightmare?  You and others can say it,
but is it reasonable to do so?


Apparently some of us think so.  ;)  There isn't supposed to be a Python 2.8.  If you create one, people will find it. 
There are other distributions that package and present Python x.y, so it would be reasonable to think that a Stackless 
Python 2.8 meant a regular Python 2.8.0




No-one has ever mistaken us for Python.  We're not, and never will be
high enough in the search results.  Our web site is not, and has never
been misrepresentative in a way where people could assume it is the
proper Python web site.  In our history of releasing versions with
matching numbers, no-one has yet mistaken us.


I suspect you would find many more hits if you were the only ones to have a Python 2.8.  See above for why that would be 
confusing.




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.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Antoine Pitrou 
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" or something.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add note to asyncore/asynchat recommending asyncio for new code.

2013-11-22 Thread Antoine Pitrou 
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 new code.
> 
> files:
>   Doc/library/asynchat.rst |  3 +++
>   Doc/library/asyncore.rst |  3 +++
>   2 files changed, 6 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/Doc/library/asynchat.rst b/Doc/library/asynchat.rst
> --- a/Doc/library/asynchat.rst
> +++ b/Doc/library/asynchat.rst
> @@ -10,6 +10,9 @@
>  
>  --
>  
> +Note: This module exists for backwards compatibility only.  For new code we
> +recommend using :module:`asyncio`.
> +

Notes should use the ".. note::" syntax.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Wording changes to pathlib docs.

2013-11-22 Thread Antoine Pitrou 
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-controversial change: joinpath() was described as:
> 
>   "Calling this method is equivalent to indexing the path with each of
>   the *other* arguments in turn."
> 
> 'Indexing' is an odd word to use, because you can't subscript Path or
> PurePath objects, so I changed it to "combining".

You're right, "indexing" dates back to when pathlib used subscripting
to combine paths together (e.g. you would write my_path['Lib']['test']
or my_path['Lib/test'] to access the 'Lib/test' subpath of my_path), but
now pathlib uses the '/' operator.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Steve Dower 
> Martin v. Löwis wrote:
> Am 22.11.13 19:10, schrieb Steve Dower:
>> I'd really want to update distutils.msvc9compiler to detect later
>> versions as well, since that would make 'pip install' work properly
>> for a large (majority?) of users for a large (majority?) of packages
>> with extension modules. Some may consider this PEP-worthy (or at least
>> worth arguing about), though I'm happy to just contribute a patch.
>> (Not referring to my existing patch for this - I have a far more
>> compatible approach in mind.)
> 
> A PEP on 2.7 seems questionable - if this would really need a PEP, it would be
> right out (IMO). A PEP would ask for community input, weighing possibly
> different design choices.

Good point. Let's keep this as a patch :)

> Instead, I think this needs explicit RM approval, such as any other borderline
> bugfix patch. I'd personally support it, including any distutils change
> (assuming the changes "look" backwards-compatible) - but it still would be for
> Benjamin to rule about it.
> 
>> There's probably also value in making the same changes to Python 3.4.
> 
> Perhaps. However, Python 3.4 is likely being replaced before VS 2010 ends its
> life, and people will be more quick to forward-port to 3.5.

True, though people will still need to match VC versions precisely. I guess we 
can look at the changes to 2.7 and see how easily they can be ported.

>> I'm also getting in touch with my colleague who currently owns MSVCRT
>> to figure out the full scope of what may happen once we start allowing
>> mismatched versions in the same process.
> 
> There used to be an MSDN article about it, but I think it was incomplete. It
> mentioned (IIRC) a) locale, b) malloc, c) struct FILE.
> Not sure whether it mentioned CRT file handles, and I'm fairly sure that it
> didn't mention errno. I also don't think that timezone issues were mentioned
> (although there used to be a separate article about CRT timezones).

That's basically the complete list. All the other concerns relate to mixing C++ 
and C, which doesn't apply here.

The advice I've been given on FILE* is that there's probably no way to make it 
work correctly due to its internal buffering. Unfortunately, there are more 
places where this leaks through than just the APIs using them - extensions that 
call os.dup(fd), PyNumber_AsSsize_t() and pass the result to _fdopen() (for 
example, numpy) are simply going to break with mismatched fd's and there's no 
way to detect it at compile time. It's hard to tell how wide-ranging this sort 
of issue is going to be, but it certainly has the potential to break badly...

> So if you can get somebody to compile a complete list, publishing it as a KB
> article would certainly be appreciated beyond the Python project.
> 
>>> A patch for this would be appreciated - perhaps you would want to put
>>> it into your sandbox on hg.python.org.
>>
>> I don't have a sandbox - how can I get one?
> 
> You are not a Python committer yet, are you? If you are, go to
> hg.python.org/cpython, and invoke the server-side clone. If you are not - does
> your company agree if you would become one?

Not yet, though I've signed a contributor agreement already. And I have 
explicit permission to make contributions along these lines. It seems I can 
make a sandbox clone without any authentication, which is very generous :), but 
I can't push yet.

Cheers,
Steve

> In any case, patches or a clone on bitbucket would work just as well.
> 
> Regards,
> Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Change Shtull-Trauring's name in Misc/ACKS

2013-11-22 Thread TaeWong 
Due to Shtull-Trauring's marriage, his name is now changed to Turner-Trauring.

Please accept the suggestion to change his name in Misc/ACKS.___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 0404 and VS 2010

2013-11-22 Thread Greg Ewing 

Ethan Furman wrote:

[Redirecting to Python Dev]

On 11/22/2013 10:25 AM, Richard Tew 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.


Maybe imaginary version numbers could be used?

Python 2.8j has a nice air of unreality about it. :-)

--
Greg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com