[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Brian Curtin]

I was using points in a more generic sense, making your "contribution
activity overview" look nicer—I wasn't sure if "points" was an actual thing
or not, so maybe I'm speaking out of turn. Mine shows 70% of my actions are
code review, then issues, commits, and PRs are 10% each.

On Mon, Jan 31, 2022 at 9:40 AM Guido van Rossum  wrote:

> Where does it say that a review gives you points? The GitHub blog post I
> saw about the subject only mentions commits.
>
> On Mon, Jan 31, 2022 at 8:16 AM Brian Curtin  wrote:
>
>> On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann  wrote:
>>
>>> On 1/30/22 04:45, Inada Naoki wrote:
>>> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel <
>>> iritkatr...@googlemail.com> wrote:
>>>
>>> > Some people may do "approval without review" to make their "Profile"
>>> > page richer, because GitHub counts it as a contribution.
>>> > Creating spam issues or pull requests can be reported as spam very
>>> > easily. But "approve without review" is hard to be reported as spam.
>>> > So approving random issue is the most easy way to earn contributions
>>> > without reported as spam.
>>>
>>> Whnever there are metrics, some will find a way to game the system to
>>> make theirs look better - this certainly isn't limited to github, or to
>>> tech, or in any way a recent thing.
>>>
>>
>> Certainly true, and I think this is more of a social problem than a
>> technical one. If people are giving out review approvals to get more
>> points, you (where 'you' is a person with some privileges on the repo) can
>> click "dismiss review" and get rid of the noise, at least within that PR.
>> Maybe they still get points for the review, I'm not sure. Taking away the
>> ability for non-core contributors to offer official review approvals to
>> stop people like that only harms the people actually trying to do good work.
>>
>> Gaming the system doesn't end up working well in the end anyway. The
>> first time the gamers try to get a job interview and can't explain how
>> they'd do a code review—something GitHub says they've done hundreds or
>> thousands of times—the whole thing will fail.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3Q7GEGI7JOCAEA7VNK7NVDSX2I43LFWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Brian Curtin]

On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann  wrote:

> On 1/30/22 04:45, Inada Naoki wrote:
> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel 
> wrote:
>
> > Some people may do "approval without review" to make their "Profile"
> > page richer, because GitHub counts it as a contribution.
> > Creating spam issues or pull requests can be reported as spam very
> > easily. But "approve without review" is hard to be reported as spam.
> > So approving random issue is the most easy way to earn contributions
> > without reported as spam.
>
> Whnever there are metrics, some will find a way to game the system to
> make theirs look better - this certainly isn't limited to github, or to
> tech, or in any way a recent thing.
>

Certainly true, and I think this is more of a social problem than a
technical one. If people are giving out review approvals to get more
points, you (where 'you' is a person with some privileges on the repo) can
click "dismiss review" and get rid of the noise, at least within that PR.
Maybe they still get points for the review, I'm not sure. Taking away the
ability for non-core contributors to offer official review approvals to
stop people like that only harms the people actually trying to do good work.

Gaming the system doesn't end up working well in the end anyway. The first
time the gamers try to get a job interview and can't explain how they'd do
a code review—something GitHub says they've done hundreds or thousands of
times—the whole thing will fail.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stale PR

[Brian Curtin]

Before looking at the code, my first question would be about the
description: "I kinda ran out of time, i suspect more testing is due."

If you were out of time then it's probably not done and maybe lacks the
tests you initially thought it did, so did you find the time and/or is the
PR done?

On Tue, Jul 6, 2021 at 10:07 AM Yair Frid  wrote:

> Hello, a few months ago i created this PR:
> https://github.com/python/cpython/pull/24181
> Which has since gone stale, I would really like it to be reviewed before i
> continue fixing other issues as i do not want to have to deal with a
> backlog of PRs
> Thanks in advance, Yair.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TYZH5DQJUBRMEPAR5N2I5VDGHNG7Y6SU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PQSY3JH7VVAWUMFAODZ3KAIXQFPP4VVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Brian Curtin]

On Tue, Jun 29, 2021 at 10:38 AM  wrote:

> I just stumbled upon the following issue and subsequent pull request. It
> is a very small bugfix. There is currently a bug in Python and this pull
> request fixes it. It's not a new feature or an enhancement, it is a bugfix!
> Yet, it doesn't get reviewed, nor merged. And this has been going on since
> March 2017. Why not just merge this? It's not like it's huge or obstructing
> or obfuscating the current code base? There's always time to write an
> improvement or a complete rewrite of this module feature later for an
> upcoming minor release. But if there is currently a bug in Python and the
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819


For starters, the PR is closed in favor of another issue that has reviews
and a discussion, but even the smallest change like that requires a lot out
of a reviewer. Looking at that change, I don't personally know that it's
correct, so I'd have to take the time to figure out that it's correct. It
includes no tests, so I certainly don't trust that it's correct, so it
looks incomplete to me.

Time is irrelevant here—there's no need to rush things because a change
appears small. What if that one line change is even more wrong than before?
I have merge access and if I just said "ah it's a small PR and it's been
open for a while, I'll just merge it for them," any change to Python has
the possibility to affect a huge amount of people.

When I got the shutil.which feature merged, the PR had been open for I
believe 11 years and it was mostly complete in the initial patch outside of
a few small issues, and the change itself wasn't a lot of code. To just
have merged it because it was open for 11 years would have been the wrong
thing to do. It needed to cover some things it didn't initially cover, it
needed tests and documentation, and it wasn't merged until it was completed
and properly reviewed.

If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>

"Only a review is required" is vastly understating the value of code
reviews. Almost anybody can write a one line fix, but is it the right fix?
Does it cover all of the cases it needs to? Is adding "manager_owned=False"
correct or should something else actually be done? Who knows and is
available to understand the impacts of this change?

So does this mean the review process is flawed? I would say no, the _review
process_ is maybe working as expected—the linked PR was incomplete and
wasn't merged, another PR has come up, and there's discussion on it
including a comment about tests and one about familiarizing with the code.
The process of finding humans who are willing and able to do this
work—currently for free—is possibly broken, possibly working as expected,
and overall is a significantly harder problem to fix than most anything
involved with open source software.

I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
>

The good thing is that you paid nothing for this, so being disappointed is
something you can fix. If you would like more value out of it or to speed
up the process, you can provide your own reviews. Reviewing code is
immensely valuable and helps so many people—the core developers, the users,
and yourself. Alternatively, paying people to do the reviews is also
possible.

___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5PYTF4BEKS3H2AZX6ZQXKIQM5SYTOH7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council reply regarding conduct (was Re: Steering Council update for February)

[Brian Herman]

Maybe we can change the discussion to something more productive like the
python module system or anything else?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NIV227PNKJSZ5VVGUGPVBBFU7YTTLPGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Brian Curtin]

On Tue, Mar 9, 2021 at 17:54 Chris Angelico  wrote:

> On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw
>  wrote:
> >
> > > Does 'master' confuse people?
> >
> > There's a general movement to replace language from common programming
> practises that derive from, or are associated with, the dehumanization of
> people. Such as master and slave, as well as whitelist and blacklist.
> >
>
> Is that *actually* the origin of the term in this context, or is it
> the "master", the pristine, the original from which copies are made?
> There's no "slave" branch anywhere in the git repository.
>
> I detest these changes that create churn and don't actually solve any
> problems. They allow people to feel good about themselves for having
> "made a change", while actually making no useful change whatsoever
> (are disadvantaged people's lives going to be improved by this
> rename?). What next? Are we going to crack down on any courses that
> proclaim to help you to "master the Python language"? Does that, too,
> have to be renamed?


What an unfortunate response, but feel free to find something else to do
after the change has been made.

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MH573FZ7NH4THZAF2LXHINIXFFRAFYAN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

David Mertz wrote:
> On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman brianfcole...@gmail.com
> wrote:
> > Basically, I
> > agree matching/destructuring is a powerful idea.  But I also
> > wonder how much genuinely better it is than a library that does not
> > require
> > a language change.  For example, I could create a library to allow this:
> > m = Matcher(arbitrary_expression)
> >  if m.case("StringNode(s)"):
> > process_string(m.val.s)
> >  elif m.case("[a, 5, 6, b]"):
> > process_two_free_vars(m.val.a, m.val.b)
> > What you are proposing here is very similar in effect to executing pattern
> > matching statements using eval. What is the advantage of implementing the
> > pattern matching functionality in a library if the user interface for that
> > functionality has the same pitfalls as eval?
> > I don't understand the similarity with eval that you are
> suggesting.
> My hypothetical library would store the value passed as initializer to
> Matcher, and provide a method .case().  That method would need
> to do
> some moderately complicated parsing of the pattern passed into it, but
> using parsing techniques, not any eval() call.  Btw. I modified my above
> strawman just slightly to what might be a bit better API.
> If there are any free variables in the pattern, they would be provided by
> the Matcher object.  For example, they could be attributes of the property
> m.val.  Or I suppose we could make them attributes of the Matcher object
> itself, e.g. m.a and m.b, but I think name conflicts with e.g.
> m.case.  Anyway, it's a strawman not an API design.
> If the pattern looked kinda like a class constructor (i.e. exactly the same
> as PEP 634 rules), the .case() method would do an isinstance()
> check
> before doing its other stuff.  If the pattern looks like a list, it would
> scan the freevars inside it and match the constant values.  And so on.
> The actual return value from .m.case(...) would be True or False (or at
> least something truthy or falsy).  However, it MIGHT create some new
> attributes (or keys, or something else) on the Matcher object if the
> pattern actually matched.
> I agree the above is slightly less readable than PEP 635 syntax, but it
> seems to have the entire power of the proposal without changing Python
> syntax.

Because syntax errors in the patterns passed to the `case` method are detected 
at runtime, rather than at compile time, it is necessary to ensure that you 
have code coverage of every call to a `case` method to be confident that there 
are no syntax errors in the patterns.

By comparison, if the pattern matching syntax is built into the language, the 
compiler will detect syntax errors in any and all patterns in `case` clauses. I 
think that this is a major advantage as compared to implementing pattern 
matching via a library.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Y4YU3QMQC6XYD6PAGFPGXNT6WZKDP7C4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

David Mertz wrote:
> On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman brianfcole...@gmail.com
> wrote:
> > Basically, I
> > agree matching/destructuring is a powerful idea.  But I also
> > wonder how much genuinely better it is than a library that does not
> > require
> > a language change.  For example, I could create a library to allow this:
> > m = Matcher(arbitrary_expression)
> >  if m.case("StringNode(s)"):
> > process_string(m.val.s)
> >  elif m.case("[a, 5, 6, b]"):
> > process_two_free_vars(m.val.a, m.val.b)
> > What you are proposing here is very similar in effect to executing pattern
> > matching statements using eval. What is the advantage of implementing the
> > pattern matching functionality in a library if the user interface for that
> > functionality has the same pitfalls as eval?
> > I don't understand the similarity with eval that you are
> suggesting.
> My hypothetical library would store the value passed as initializer to
> Matcher, and provide a method .case().  That method would need
> to do
> some moderately complicated parsing of the pattern passed into it, but
> using parsing techniques, not any eval() call.  Btw. I modified my above
> strawman just slightly to what might be a bit better API.
> If there are any free variables in the pattern, they would be provided by
> the Matcher object.  For example, they could be attributes of the property
> m.val.  Or I suppose we could make them attributes of the Matcher object
> itself, e.g. m.a and m.b, but I think name conflicts with e.g.
> m.case.  Anyway, it's a strawman not an API design.
> If the pattern looked kinda like a class constructor (i.e. exactly the same
> as PEP 634 rules), the .case() method would do an isinstance()
> check
> before doing its other stuff.  If the pattern looks like a list, it would
> scan the freevars inside it and match the constant values.  And so on.
> The actual return value from .m.case(...) would be True or False (or at
> least something truthy or falsy).  However, it MIGHT create some new
> attributes (or keys, or something else) on the Matcher object if the
> pattern actually matched.
> I agree the above is slightly less readable than PEP 635 syntax, but it
> seems to have the entire power of the proposal without changing Python
> syntax.

To be more precise, the similarity that I see to `eval` is that syntax errors 
in the patterns that are passed to the `case` method cannot be detected at 
compile time and instead will be detected at runtime. Building the syntax into 
the language gives the advantage of producing a syntax error at compile time. 
It also makes it easier for linters and type checkers to validate the pattern 
matching clauses if the syntax is built into the language.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JLWRMQW4OX7SXJWMORHMAIWFES6OYRR7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

David Mertz wrote:
> I have a little bit of skepticism about the pattern matching syntax, for
> similar reasons to those Larry expresses, and that Steve Dower mentioned on
> Discourse.
> Basically, I agree matching/destructuring is a powerful idea.  But I also
> wonder how much genuinely better it is than a library that does not require
> a language change.  For example, I could create a library to allow this:
> m = Matcher(arbitrary_expression)
> if m.case("StringNode(s)"):
> process_string(m.val)
> elif m.case("[a, 5, 6, b]"):
> process_two_free_vars(*m.values)
> elif m.case("PairNone(a, b)"):
> a, b = m.values
> process_pair(a, b)
> elif m.case("DictNode"):
> foo = {key, process_node(child_node) for key, child_node in
> m.values.items()}
> I don't disagree that the pattern mini-language looks nice as syntax.  But
> there's nothing about that mini-language that couldn't be put in a library
> (with the caveat that patterns would need to be quoted in some way).

What you are proposing here is very similar in effect to executing pattern 
matching statements using `eval`. What is the advantage of implementing the 
pattern matching functionality in a library if the user interface for that 
functionality has the same pitfalls as `eval`?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E4KVS77FVES6KEH3DQRJMQDZO7WAXWLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

Antoine Pitrou wrote:
> On Mon, 23 Nov 2020 16:15:12 -
> "Brian Coleman" brianfcole...@gmail.com
> wrote:
> > Furthermore, Python has a regular expression module
> > which implements it's own DSL for the purpose of matching string patterns. 
> > Regular
> > expressions, in a similar way to pattern matching,
> >   allow string patterns to be expressed in a concise and declarative manner.
> > Uh, without regular expressions, a lot of functions would be massively
> more complicated and annoying to write.
> However, your example shows that pattern matching barely makes
> common code shorter (admittedly, on this _one_ example, but that's the
> one you chose ;-)).
> While I agree that regular expressions are far less Pythonic than the
> proposed variant of pattern matching, they also have a tremendously
> better cost/benefit ratio, IMHO.
> Regards
> Antoine.

In my opinion, the object oriented solution to this problem is to use the 
visitor pattern. The solution using the visitor pattern is almost twice the 
length of the other solutions. Pattern matching is certainly no worse than the 
solution using a chain of `isinstance` checks in this case. 

However as the patterns to be checked against a candidate object become more 
complex, I believe that the pattern matching solution will retain the same 
level of elegance and obviousness that it possesses in this example, whereas 
the solution involving a chain of comparisons will quickly degrade in terms of 
obviousness.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UNESWNNQGXOI4W24H3HMD6UPDQQDUF2X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

Larry Hastings wrote:
> On 11/23/20 8:15 AM, Brian Coleman wrote:
> > def process(root_node: Node):
> >  def process_node(node: Node):
> >  if isinstance(node, StringNode):
> >  return node.value
> >  elif isinstance(node, NumberNode):
> >  return float(node.value)
> >  elif isinstance(node, ListNode):
> >  return [process_node(child_node) for child_node in 
> > node.children]
> >  elif isinstance(node, DictNode):
> >  return {key: process_node(child_node) for key, child_node in 
> > node.children}
> >  else:
> >  raise Exception('Unexpected node')
> > You don't need the "else".  And you can change all your "elif"s into 
> "if"s too.  Now your "isinstance" version is 35 lines. Shorter than the 
> pattern matching version, roughly the same speed, works in current 
> Python, eminently readable to anybody conversant in current Python.  A 
> very reasonable solution to the problem.
> There should be one--and preferably only one--obvious way to do it,
> //arry/

It was not my intention to suggest that the solution implemented in the 
shortest number of lines was superior.

I think that one of the advantages of the pattern matching implementation over 
the sequence of `isinstance` checks is that there is no need to worry about 
whether using `if`, `elif`or `else` is the best approach. There is a single 
elegant and natural way to express the solution with pattern matching.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7FCXBKZQ6PU7VAOB76GGFJJXFWEPXL7L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Advantages of pattern matching - a simple comparative analysis

[Brian Coleman]

Take as an example a function designed to process a tree of nodes similar to 
that which might be output by a JSON parser. There are 4 types of node:

- A node representing JSON strings
- A node representing JSON numbers
- A node representing JSON arrays
- A node representing JSON dictionaries

The function transforms a tree of nodes, beginning at the root node, and 
proceeding recursively through each child node in turn. The result is a Python 
object, with the following transformation applied to each node type:

- A JSON string `->` Python `str`
- A JSON number `->` Python `float`
- A JSON array `->` Python `list`
- A JSON dictionary `->` Python `dict`

I have implemented this function using 3 different approaches:

- The visitor pattern
- `isinstance` checks against the node type
- Pattern matching

Here is the implementation using the visitor pattern:

```
from typing import List, Tuple

class NodeVisitor:
def visit_string_node(self, node: StringNode):
pass

def visit_number_node(self, node: NumberNode):
pass

def visit_list_node(self, node: ListNode):
pass

def visit_dict_node(self, node: DictNode):
pass


class Node:
def visit(visitor: NodeVisitor):
raise NotImplementedError()


class StringNode(Node):
value: str

def visit(self, visitor: NodeVisitor):
visitor.visit_string_node(self)


class NumberNode(Node):
value: str

def visit(self, visitor: NodeVisitor):
visitor.visit_number_node(self)


class ListNode(Node):
children: List[Node]

def visit(self, visitor: NodeVisitor):
visitor.visit_list_node(self)


class DictNode(Node):
children: List[Tuple[str, Node]]

def visit(self, visitor: NodeVisitor):
visitor.visit_dict_node(self)


class Processor(NodeVisitor):
def process(root_node: Node):
return root_node.visit(self)

def visit_string_node(self, node: StringNode):
return node.value

def visit_number_node(self, node: NumberNode):
return float(node.value)

def visit_list_node(self, node: ListNode):
return [child_node.visit(self) for child_node in node.children]

def visit_dict_node(self, node: DictNode):
return {key: child_node.visit(self) for key, child_node in 
node.children}


def process(root_node: Node):
processor = Processor()
return processor.process(root_node)
```

Here is the implementation using `isinstance` checks against the node type:

```
from typing import List, Tuple

class Node:
pass


class StringNode(Node):
value: str


class NumberNode(Node):
value: str


class ListNode(Node):
children: List[Node]


class DictNode(Node):
children: List[Tuple[str, Node]]


def process(root_node: Node):
def process_node(node: Node):
if isinstance(node, StringNode):
return node.value
elif isinstance(node, NumberNode):
return float(node.value)
elif isinstance(node, ListNode):
return [process_node(child_node) for child_node in node.children]
elif isinstance(node, DictNode):
return {key: process_node(child_node) for key, child_node in 
node.children}
else:
raise Exception('Unexpected node')

return process_node(root_node)
```

Finally here is the implementation using pattern matching:

```
from typing import List, Tuple

class Node:
pass


class StringNode(Node):
value: str


class NumberNode(Node):
value: str


class ListNode(Node):
children: List[Node]


class DictNode(Node):
children: List[Tuple[str, Node]]


def process(root_node: Node):
def process_node(node: Node):
match node:
case StringNode(value=str_value):
return str_value
case NumberNode(value=number_value):
return float(number_value)
case ListNode(children=child_nodes):
return [process_node(child_node) for child_node in child_nodes]
case DictNode(children=child_nodes):
return {key: process_node(child_node) for key, child_node in 
child_nodes}
case _:
raise Exception('Unexpected node')

return process_node(root_node)
```

Here are the lengths of the different implementations:

- Pattern matching `->` 37 lines
- `isinstance` checks `->` 36 lines
- The visitor pattern `->` 69 lines

The visitor pattern implementation is by far the most verbose solution, 
weighing in at almost twice the length of the alternative implementations due 
to the large amount of boilerplate that is necessary to achieve double 
dispatch. The pattern matching and `isinstance` check implementations are very 
similar in length for this trivial example.

In each implementation, there are 2 operations performed on each node.

- Determine the type of the node
- Destructure the node to extract the desired data

The visitor pattern and `isinstance` check implementations separate these 2 

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Brian Coleman]

Greg Ewing wrote:
> On 23/11/20 7:49 am, Daniel Moisset wrote:
> > Look at the following (non-pattern-matching)
> > snippet:
> > event = datetime.date(x, month=y, day=z)
> > 
> > The only names that are treated as lvalues there are to the left
> of an '='. The rules are a lot simpler.
> One of the Zen lines says "If it's hard to explain, it's probably
> a bad idea." I think the proposed rules for match cases are
> objectively harder to explain than those for other expressions,
> because they're more complicated.

I don't believe that it is correct that `month` in `month=y` and `day` in 
`day=z` in the expression `event = datetime.date(x, month=y, day=z)` are 
lvalues. They are definitely not assignment targets in the same sense that 
`event` is an assignment target. `month` and `day` are used to bind the 
arguments `y` and `z` to the `month` and `day` arguments accepted by the `date` 
constructor. `event` can be accessed and rebound in the scope that invokes 
`datetime.date`. However, `month` and `day` are only bound to `y` and `z` in 
the scope of the body of the `datetime.date` constructor and are not accessible 
in the scope that invokes `datetime.date`. The behaviour is significantly 
different.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FDEVMYO3YCFZO3UYTP7D2G3HHKFP7EXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Brian Coleman]

Regarding the difficulty which some people have respecting class patterns and 
dictionary patterns, I would like to draw attention to a similar feature in 
JavaScript, object destructuring. JavaScript does not have pattern matching but 
object destructuring is closely related. Take the example of a function to 
compute the distance between two points.

```
function distance(p1, p2) {
  // This is an object destructuring assignment that extracts the x field of p1 
into x1 and the y field of p1 into y1
  const { x: x1, y: y1 } = p1;
  // This is an object destructuring assignment that extracts the x field of p2 
into x2 and the y field of p2 into y2
  const { x: x2, y: y2 } = p2;

  const dx = x2 - x1;
  const dy = y2 - y1;
  return Math.sqrt(dx*dx + dy*dy);
}

// An object literal is assigned to p1 here
const p1 = { x: 0, y: 0 };
// An object literal is assigned to p2 here
const p2 = { x: 1, y: 1 };
const d = distance(p1, p2);
```

Similarly to dictionary patterns in Python, object destructuring in JavaScript 
places the variable names that are the targets of the assignments in the same 
position where a value would be expected in an object literal. This feature has 
existed in JavaScript for several years now and I would like to draw attention 
to it as a counterpoint to the argument that pattern matching is not a good fit 
for languages that are not statically typed. Destructuring can also be found in 
Common Lisp, which is not statically typed. Pattern matching is also a core 
part of Erlang, which is not statically typed..

I would also like to draw attention to the fact that object destructuring was 
added to JavaScript years into it's development. I do not believe this to be a 
reasonable argument against adopting pattern matching in Python.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6XDXHVT3ZFOK66GVU5UWYGSHJX4UF2CW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion

[Brian Curtin]

Hey Team,

Has this workgroup started yet? If not, can I help get it going, or if so,
is there a mailing list or place where things are happening?

Brian Curtin

On Sun, Aug 9, 2020 at 12:58 Carol Willing  wrote:

> Hi folks,
>
> Thanks for the interest. I apologize for the delay in getting this
> workgroup started. I'm happy that there is strong interest in working on
> documentation and improving it for all users.
>
> I will do my best to get the workgroup charter drafted this week and then
> open an interest list for initial workgroup members.
>
> Luciano, I agree that rewriting asyncio docs and typing are helpful
> improvements and welcome your contributions to accessible and high quality
> docs.
>
> Warmly,
>
> Carol
>
> On Sun, Aug 9, 2020 at 9:21 AM Luciano Ramalho 
> wrote:
>
>> I am also interested in helping with making Python's documentation
>> more user friendly.
>>
>> Yuri Selivanov's rewrite of the asyncio documentation was brilliant.
>> We need more of that.
>>
>> My recent contribution to Python's doc doesn't compare with
>> Selivanov's awesome rewrite, but it involved reorganizing existing
>> documentation.
>>
>> The typing module chapter in the library reference is comprehensive,
>> and the top 1/3 of it has good narrative explanations to the core
>> concepts. But the remaining 2/3 of the content is in a single section
>> titled "Classes, functions, and decorators" that covers more than 70
>> objects, and there's no apparent ordering.
>>
>> With the help of Guido, I split that section in subsections, and
>> arranged the entries within the subsections by relevance to most
>> users—subjective, yes, but not too harmful if we made bad calls,
>> because now there are fewer entries per subsection.
>>
>> Before:
>> https://docs.python.org/3.8/library/typing.html
>>
>> After:
>> https://docs.python.org/3.10/library/typing.html
>>
>> Cheers,
>>
>> Luciano
>>
>> On Sun, Aug 9, 2020 at 12:43 PM Mats Wichmann  wrote:
>> >
>> > On 8/5/20 10:43 AM, Dominic Davis-Foster wrote:
>> > > Hi Carol,
>> > >
>> > > I was wondering if you've been able to set up the workgroup yet? I'd
>> certainly be interested in participating the there's an opportunity.
>> > >
>> > >
>> > > Stay safe
>> > >
>> > > Dom
>> >
>> > Indeed, I was wondering if there were any updates - I'm also interested
>> > in participating.
>> >
>> > -- mats
>> > ___
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/MRV5SQCC2GC6MLIUCSPJZL3AQCXVDUEG/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>>
>> --
>> Luciano Ramalho
>> |  Author of Fluent Python (O'Reilly, 2015)
>> | http://shop.oreilly.com/product/0636920032519.do
>> |  Technical Principal at ThoughtWorks
>> |  Twitter: @ramalhoorg
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/P6S4Q3H6VOXVJTXX4UCRRYDCIDLC2M4C/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZTIK4R7HNPV2HZJ6TJHONGCCYUOSL5CW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MCGGPWD5C66IG3ITL2SOROYW62CQTKBJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thank you Larry Hastings!

[Brian Ray]

Well done Larry! so long and thanks for all the Pythons.

-- 
Brian Ray
brian-ray.me
<https://brian-ray.me/?promo=email_sig_source=product_medium=email_sig_campaign=edit_panel_content=thumb>
ᐧ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QBNSLYLN534JDHIC26KKSKNKPGGT7MEG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 2.7.18, the end of an era

[Brian Curtin]

On Tue, Apr 21, 2020 at 7:31 AM Larry Hastings  wrote:

> On 4/20/20 8:06 AM, Benjamin Peterson wrote:
>
> I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...] 
> Over all those years, CPython's core developers and contributors sedulously 
> applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 
> branches diverged.
>
>
> I'm glad you're enjoying your new thesaurus!
>
I'm glad he was able to keep up the ebullience so long. He was jocund about
2.7.0rc2 around this time ten years ago.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JWYWGC7CO7FZP7KVGZO3VHLCTBRGCUWP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.10 or 4.0?

[Brian Skinn]

I've appreciated Anthony Sottile's flake8-2020 plugin 
(https://pypi.org/project/flake8-2020/), which adds checks for a variety of 
misuses of sys.version and sys.version_info that would lead to breakage on a 
Python 4.0, and/or 10.0, in addition to Python 3.10.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FHROEYFSPBWJQ2L7MX7I6G3NAG6WQBQJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Python 2 death march

[brian . skinn]

 it's getting better?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/C52ZRWV5XXYXS7VRDNH6I7IDIMO2A2PM/

[Python-Dev] Re: Inline links in Misc/NEWS entries

[brian . skinn]

Citing from the current (19 Aug 2019) version of this PR 
(https://github.com/python/devguide/pull/525/files#diff-50cb76bbe8ae3fcd4170dc6e8d9d6b3fR225-R226):

> Before using any Sphinx roles, ensure that a corresponding entry exists 
> within the documentation.

At the risk of crass self-promotion, the talk I gave last month at PyOhio 
(https://www.pyohio.org/2019/presentations/137) provides step-by-step 
instructions for how to find the information needed to craft a working Sphinx 
cross-reference, along with some of the tooling that's available.

Right now I have the slides up as a view-only share in my Google Drive 
(bit.ly/bskinn-pyohio2019-intersphinx). Perhaps it would be useful to link to 
them? Or, to host a PDF someplace more permanent, and link to that?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IK5XP7CPZDF2FSFG55JRKXHEXNTOMUTB/

[Python-Dev] Re: What to do about invalid escape sequences

[brian . skinn]

Nathaniel Smith wrote:
> Unfortunately, their solution isn't a pytest incantation, it's a
> separate 'compileall' invocation they run on their source tree. I'm
> not sure how you'd convert this into a pytest feature, because I don't
> think pytest always know which parts of your code are your code versus
> which parts are supporting libraries.
> -n

Ahh, did not appreciate this. :-( Nevermind, then!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VFFV7MJUZKMSD6FS3OONSEN5XLBOLT5R/

[Python-Dev] Re: What to do about invalid escape sequences

[brian . skinn]

Eric V. Smith wrote:
>  Hopefully the warnings in 3.9 would be more visible that what we saw in 
> 3.7, so that library authors can take notice and do something about it 
> before 3.10 rolls around.
> Eric

Apologies for the ~double-post on the thread, but: the SymPy team has figured 
out the right pytest incantation to expose these warnings. Given the extensive 
adoption of pytest, perhaps it would be good to combine (1) a FR on pytest to 
add a convenience flag enabling this mix of options with (2) an aggressive 
"marketing push", encouraging library maintainers to add it to their testing/CI.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S2464WJ3QCDE4CBM6AWITHMFCISA6O75/

[Python-Dev] Re: What to do about invalid escape sequences

[brian . skinn]

> This whole thread would be an excellent justification for following 3.9
> with 4.0. It's as near as we ever want to get to a breaking change, and a
> major version number would indicate the need to review. If increasing
> strictness of escape code interpretation in string literals is the only
> incompatibility there would surely be general delight.
> 
> Kind regards,
> Steve Holden

I rather doubt that allowing breaking changes into a Python 4.0 would end up 
with this as the only proposed incompatibility. Once word got out, a flood of 
incompat requests would probably get raised. I personally have a change I'd 
like made to doctest (https://bugs.python.org/issue36714), and I know of 
another in argparse (https://bugs.python.org/issue33109) that I'm personally 
neutral on but that others have stronger feelings about.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SEBJF7C7RRG3Q3MFD5D6CTOFZUX7DNSE/

[Python-Dev] Re: What to do about invalid escape sequences

[brian . skinn]

Steven D'Aprano wrote:

> Because our processes don't work the way we assumed, it turns out that 
> in practice we haven't given developers the deprecation period we 
> thought we had. Read Nathaniel's post, if you haven't already done so:
> https://mail.python.org/archives/list/python-dev@python.org/message/E7QCC74O...
> He makes a compelling case that while we might have had the promised 
> deprecation period by the letter of the law, in practice most developers 
> will have never seen it, and we will be breaking the spirit of the 
> promise if we continue with the unmodified plan.
> ...
> I'm sure that the affected devs will understand why it was their fault 
> they couldn't see the warnings, when even people from a first-class 
> library like SymPy took four iterations to do it right.
> > Currently it
> > requires some extra steps or flags, which are not well known. What
> > change are you proposing for 3.8 that will ensure that this actually
> > gets solved?
> > Absolutely nothing. I don't have to: we're an entire community, this 
> doesn't have to fall only on my shoulders. I'm not even the messenger: 
> that's Raymond. I'm just (partly) agreeing with him.
> Just because I don't have a solution for this problem doesn't mean the 
> problem doesn't exist.

As the SymPy team has figured out the right pytest incantation to expose these 
warnings, perhaps a feature request on pytest to encapsulate that mix of 
options into a single flag would be a good idea?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WOJQTOXMYKHLQO4KICEIZH3PDEMQLMBL/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[brian . skinn]

It seems to me that the desired behavior here is closest to 'str.replace()' out 
of all the options discussed, just with the constraint of being limited to 
either the start or the end of the string. (Thus the .lreplace() and 
.rreplace() option suggested by Glenn.)

The minimal change (which actually also is pretty general?) I think would be to 
add 'only_start' and 'only_end' keyword arguments to str.replace(), both 
defaulting to False. If, e.g., 'only_start' is passed True, each repetition of 
'old' at the start of 's' is replaced by 'new', with the number of replacements 
limited by the existing optional 'count'. Similar behavior for 'only_end'=True. 
 Probably best to raise a ValueError(?) if both 'only_start'=True and 
'only_end'=True?

Taking swapping a file extension as an example of a particular transformation 
of interest, it would be achieved with something like s.replace(".htm", 
".html", only_end=True).

-Brian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N3VNJHO467YT53ZVIAAGKEWOYISJ4VTY/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Brian Skinn]

It seems to me that the desired behavior is closest to 'str.replace()' out
of all the options, just with the constraint of being limited to either the
start or the end of the string. (Thus the .lreplace() and .rreplace()
option suggested by Glenn earlier in the thread.)

The minimal change (which actually also seems pretty general) seems to me
to be adding *only_start* and *only_end* keyword arguments to
str.replace(), both defaulting to False. If, e.g., *only_start* is passed
True, each repetition of *old* at the start of *str* is replaced by a copy
of *new*, with the number of replacements limited by the existing optional
*count*. Similar behavior for *only_end*=True.  Probably best to raise a
ValueError(?) if both *only_start*=True and *only_end*=True?

Taking swapping a file extension as an example of a particular
transformation of interest, it would be achieved with something like
s.replace(".htm", ".html", only_end=True).

-Brian


--
>
> Date: Tue, 2 Jul 2019 14:33:57 +1000
> From: Chris Angelico 
> Subject: [Python-Dev] Re: strip behavior provides inconsistent results
> with certain strings
> To: python-dev 
> Message-ID:
>  x64_vdym9jaj0z9n19te7dk+navvoxoih7...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Jul 2, 2019 at 2:28 PM Glenn Linderman 
> wrote:
> >
> >> A method could raise instead of returning the string as-is if the
> prefix is not really a prefix.  How often is this needed?  The most common
> end deletions are whitespace, which the current .strip handles correctly.
> >
> > raising wouldn't be helpful in most of the situations where I use this
> logic... it would require a more complex flow control than the  if
> startswith path in the current situation.
> >
> > Yes, I use strip more frequently, but if startswith: chop_prefix
> operation (and the other end too) happens an awful lot.
>
> If the method accepts a tuple of prefixes and will remove the first
> one found (or the longest, or whatever) and raises if none found, you
> could get the "chop only if present" behaviour by including an empty
> string as one of the possible prefixes.
>
> ChrisA
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SCZH4SYCM2Z2UXTKYMAIMHGRUKGKD2FU/

[Python-Dev] VxWorks and Python

[Kuhl, Brian]

Hi Python developers,
Victor suggested I post a little background to help the maintainers understand 
VxWorks a little better.
It can be found here
https://github.com/Wind-River/cpython/wiki/Python-on-VxWorks
If you'd like more detail in a particular area, please feel free to reply on or 
off list.

I'd also like to mention again, that Wind River is interested in setting up a 
short term consulting arrangement, with any core dev that's available.
To help accelerate Peixing's PRs acceptance
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+bpo-31904
and generally improve Cpython.

Wind River operates globally so don't let you location dissuade you.

Many thanks for all your help,

Brian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can I submit more support of standard library for VxWorks after 3.8.0 beta1?

[Kuhl, Brian]

Hi Victor,
I pinged our product manager and he’s open to the idea of setting up a 
consulting  arrangement with a core developer to help move things along.
At least in principal.
If anyone on the core team is interested, and reasonably unaligned with Wind 
River’s competitors, please contact me off list, Brian dot Kuhl at Wind River 
dot com.

Brian

From: Python-Dev 
[mailto:python-dev-bounces+brian.kuhl=windriver@python.org] On Behalf Of 
Victor Stinner
Sent: Tuesday, March 19, 2019 1:40 PM
To: Xin, Peixing 
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Can I submit more support of standard library for 
VxWorks after 3.8.0 beta1?

You have to find someone to review your PRs. It takes time. We are all 
volunteers. I looked and merged some VxWorks PRs.

Would it be possible to pay a core dev to do the reviews? That's an open 
question for core devs and for WindRiver.

Victor

Le mardi 19 mars 2019, Xin, Peixing 
mailto:peixing@windriver.com>> a écrit :
> Hi, Experts:
>
>
>
> Seeing from the Python 3.8.0 
> schedule(https://www.python.org/dev/peps/pep-0569/#schedule), new features 
> will not be allowed to submit after 3.8.0 beta1. For VxWorks RTOS platform 
> supporting CPython, we are using 
> bpo-31904(https://bugs.python.org/issue31904) for PRs to submit our codes. 
> Now I want to know whether we can add more standard library support for 
> VxWorks AFTER 3.8.0 beta1?
>
>
>
> 
>
>
>
> Thanks,
>
> Peixing
>
>

--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Testing cross-compiled python (windows arm32) from build bot

[Kuhl, Brian]

We (Wind River) are doing it for VxWorks, which is also cross-compiled, and has 
no concept of chroot you see in Linux. 
The trick is to insert a little switch from local to a remote shell between the 
build and the test run via ssh (or telnet).
Don't think we gotten anywhere near upstreaming that little change though?
CPython's buildbot is actually easier than most to open source test suites to 
adapt to cross compile, because everything is run in python after the build, so 
you only have to make one switch in context.

 Brian

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+brian.kuhl=windriver@python.org] On Behalf Of Matthias Klose
> Sent: Monday, March 18, 2019 5:32 PM
> To: Paul Monson ; python-dev@python.org
> Subject: Re: [Python-Dev] Testing cross-compiled python (windows arm32) from
> build bot
> 
> On 18.03.19 21:10, Paul Monson via Python-Dev wrote:
> > Hello,
> >
> > For windows arm32 I would like to be able run tests in the buildbot.
> > Windows arm32 programs built with MSVC are always cross-compiled.
> > This means I need to build cpython on x86/x64 and then deploy the build
> artifacts and run the tests on an ARM32 device.
> >
> > Is there any documentation or examples of how to do this?
> > If not, are there any recommendations for how to achieve this?
> 
> I'm not aware of any documentation. For arm-linux-gnueabihf I once had a
> setup with two chroots, the first one for cross-building python, and then the
> second one for running the tests using qemu.  Two separate chroots to make
> sure that I don't run any target code during the build.  The build location 
> bind
> mounted in both chroots to avoid the copy step.
> 
> Matthias
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-
> dev/brian.kuhl%40windriver.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] VxWorks and cpython?

[Kuhl, Brian]

Hi Victor,
I think we can come up with some sort of strategy that will work for everyone. 
I'll ask about the SSH access; and if that runs up against a corporate 
roadblock, I will explore some other alternative. 

Is there a good place to document "Python on VxWorks" ?
The changes to Python are not large, I've kept the pull request from last 
year's POC active. The changed files provide a good summary of the scope.
https://github.com/python/cpython/pull/4184/files
However, based on the POC we've gone back and improved VxWorks, so the some of 
the uglier bits, in libraries like submodule, won't be needed.
These will be in the next release of VxWorks. 

However we let automake and setup.py do much of the work for us, so where 
VxWorks  does not have support for something, it's not obvious.
A public document would go a long way to filling in those details, something 
much more detailed than  my glib "VxWorks is almost POSIX" in the pull request. 
 

Other challenges; 
* VxWorks is cross-compiled on both Linux and Windows. ( currently with clang 
and gcc)
* Supported on ARM,  PowerPC and Intel processors
* 32bit and 64bit builds 
* A constantly evolving set of reference boards (or BSPs)   
https://marketplace.windriver.com/index.php?bsp=list=platform=VxWorks:%207%20-%20Wind%20River%20Workbench%204.0

I don't think we need a buildbot for every board.  I'm thinking a 1/2 dozen to 
cover ARM, PPC and IA with both a 32bit and 64 bit build?
We have a bit of chicken and egg problem right now, a buildbot will always fail 
until there's some basic VxWorks support added. 

Do we set them up, and just let them fail, till enough PRs are accepted to make 
it build?

Brian

> -Original Message-
> From: Victor Stinner [mailto:vstin...@redhat.com]
> Sent: Wednesday, January 09, 2019 6:43 PM
> To: Christian Heimes
> Cc: Guido van Rossum; Kuhl, Brian; python-dev@python.org
> Subject: Re: [Python-Dev] VxWorks and cpython?
> 
> Le mer. 9 janv. 2019 à 18:16, Christian Heimes  a écrit 
> :
> > It's a PEP. The process and expectations for platform are explained in
> > PEP 11, https://www.python.org/dev/peps/pep-0011/
> 
> I also wrote some information in my website:
> https://pythondev.readthedocs.io/platforms.html
> 
> > If possible it would also be helpful to get SSH access to some VxWorks
> > machines for core devs. I know that Victor likes to dig into rare
> > corner cases and help to debug exotic platforms.
> 
> The best case to get a full support is to have one core developer responsible 
> of
> handling all bugs specific to the platform.
> 
> As a core developer, I'm never comfortable to merge a change specific to a
> platform if I'm not able to validate it manually myself. I trust no one, not 
> even
> myself (I know well that I do frequently mistakes!), so I prefer to always 
> double
> check changes before merging them ;-)
> 
> In the meanwhile, I would say that we can only offer "best effort"
> support. Fix reports bugs and do our best in our limited time.
> 
> Someone has to take the work done to port Python on VxWorks and write small
> pull requests. These PRs should be reviewed one by one to make sure that it's
> the correct way to fix an issue. Be prepared that it can take several months 
> even
> if all these changes look obvious to *you*. Core developers have limited time
> and many prefer to focus on the platforms that they are using, not worry about
> a platform they never heard about... I can have a look at such PRs.
> 
> It would also help to have a documentation somewhere about "Python on
> VxWorks". Pointers to VxWorks (general info, developers info), pointers to 
> your
> port, current status of the port, etc.
> 
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] FW: VxWorks and cpython?

[Kuhl, Brian]

From: Guido van Rossum [mailto:gu...@python.org]
Sent: Wednesday, January 09, 2019 11:52 AM
To: Kuhl, Brian
Cc: python-dev@python.org
Subject: Re: [Python-Dev] VxWorks and cpython?

Hi Brian,

I am glad that this is happening!

I don't think you need a PEP to motivate your request -- however you need to 
submit the upstream patches, work with the CPython buildbot managers (Victor?) 
to connect your buildbots, and work with reviewers (Serhiy?) to get your 
patches integrated in CPython. Hopefully the patches are small and focused -- 
we generally don't take patches that refactor large swaths of code. It's also 
better not to submit everything in a single giant patch (reviewers hate 
mega-patches). And the patch submitters need to be responsive when the code 
review comments are coming.

This is not a one-time effort -- your team will need to be "on call" to handle 
VxWorks issues for the foreseeable future (a minimum commitment of 5 years?), 
and your team members needs to be able to do this in their capacity as Wind 
River engineers, not as open source volunteers.

I believe there is a PEP with a list of supported operating systems that needs 
to be updated, but I don't recall which one it is -- hopefully you can track it 
down with a little Googling. (Or was it the devguide?)

Good luck,

--Guido

On Wed, Jan 9, 2019 at 8:42 AM Kuhl, Brian 
mailto:brian.k...@windriver.com>> wrote:
Hi Python Developers,
I’m Brian Kuhl, I’ve spent about  28 years working with embedded software. 
Since 2000 I’ve worked for Wind River. I’m currently a manager of documentation 
and customer training in our Ottawa, Canada office. Throughout my career I’ve 
had an interest in the use of open source software in embedded systems, have 
ported many libraries to Wind River’s flagship product the VxWorks RTOS.

The safe and secure embedded market where VxWorks is the leader is evolving, 
and devices that use to be made up of multiple processors running multiple 
operating systems are now being consolidated. Device security and IoT trends 
mean a device must be more configurable and updateable, and a better host for 
portable code. In this evolving space our  customers have asked us to add 
Python support to VxWorks.

Wind River would like cpython to officially support VxWorks.  I’ve been ask by 
my colleagues to volunteer as a maintainer for cpython in order to support this 
effort.  Wind River will also provide the needed buildbot clients required to 
verify continuing VxWorks support.

Myself and an intern were able to get the majority of Python tests suite 
passing with a POC last year.
An engineering group in Beijing  have taken that POC and are improving and 
cleaning up that effort now with the hopes of up-steaming their efforts.

My Chinese colleagues have suggested that the first step to gaining your 
support would be to summit a PEP detailing the changes?
If you agree, I will proceed with authoring a PEP.

Many thanks in advance for your responses,

Brian


P.S. I can be found on  github (and many other places) as kuhlenough.


___
Python-Dev mailing list
Python-Dev@python.org<mailto:Python-Dev@python.org>
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/guido%40python.org


--
--Guido van Rossum (python.org/~guido<http://python.org/~guido>)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] VxWorks and cpython?

[Kuhl, Brian]

Hi Python Developers,
I'm Brian Kuhl, I've spent about  28 years working with embedded software. 
Since 2000 I've worked for Wind River. I'm currently a manager of documentation 
and customer training in our Ottawa, Canada office. Throughout my career I've 
had an interest in the use of open source software in embedded systems, have 
ported many libraries to Wind River's flagship product the VxWorks RTOS.

The safe and secure embedded market where VxWorks is the leader is evolving, 
and devices that use to be made up of multiple processors running multiple 
operating systems are now being consolidated. Device security and IoT trends 
mean a device must be more configurable and updateable, and a better host for 
portable code. In this evolving space our  customers have asked us to add 
Python support to VxWorks.

Wind River would like cpython to officially support VxWorks.  I've been ask by 
my colleagues to volunteer as a maintainer for cpython in order to support this 
effort.  Wind River will also provide the needed buildbot clients required to 
verify continuing VxWorks support.

Myself and an intern were able to get the majority of Python tests suite 
passing with a POC last year.
An engineering group in Beijing  have taken that POC and are improving and 
cleaning up that effort now with the hopes of up-steaming their efforts.

My Chinese colleagues have suggested that the first step to gaining your 
support would be to summit a PEP detailing the changes?
If you agree, I will proceed with authoring a PEP.

Many thanks in advance for your responses,

Brian


P.S. I can be found on  github (and many other places) as kuhlenough.


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

Re: [Python-Dev] Helping with Documentation

[Brian Curtin]

On Mon, Oct 29, 2018 at 9:36 AM Kenneth Reitz  wrote:

> Hello all,
>
>
>
> I’d like to become a core contributor to Python, by contributing polish to
> its documentation (adding missing pieces, modernize it a bit in spots, add
> more usage examples (itertools), etc).
>
>
>
> Is anyone already working on this, and if so, can I join forces with you?
>

I don't know of any specific or active documentation focus right now (save
for translation, which is mostly what doc-sig has been about lately), but
giving the docs love has been on my todo list for quite a while now with
tiny efforts here or there. Your general idea sounds good enough to just go
for it and put up PRs.

Feel free to add me as a reviewer—@briancurtin—and I'll help get things
merged.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dealing with tone in an email

[Brian Curtin]

On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 03.05.2018 21:31, Brett Cannon wrote:
>
>
>
> On Thu, 3 May 2018 at 01:27 Paul Moore  wrote:
>
>> On 3 May 2018 at 03:26, Steven D'Aprano  wrote:
>>
>> >> Will all due respect, it's sometimes unpredictable what kind of wording
>> >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> >> there that doesn't exist in other cultures. To me, "not give a damn"
>> >> reads like a familiar version of "not care about something", but
>> >> apparently it can be offensive.
>> >
>> > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
>> > the point of ludicrousness to say that "no-one gives a damn" is an
>> > insult. This isn't 1939 when Clark Gable's famous line "Frankly my dear,
>> > I don't give a damn" was considered shocking. Its 2018 and to not give a
>> > damn is a more forceful way of saying that people don't care, that they
>> > are indifferent.
>>
>> Sigh. That's not what I was saying at all. I was trying to point out
>> that Antoine's claim that people should ignore the rhetoric and that
>> complaining about the attitude was unreasonable, was in itself unfair.
>> People have a right to point out that a mail like the OP's was badly
>> worded.
>>
>> > With respect to Paul, I literally cannot imagine why he thinks that
>> > *anyone*, not even the tkinter maintainers or developers themselves,
>> > ought to feel *offended* by Ivan's words.
>>
>> Personally, they didn't offend me. I don't pretend to know how others
>> might take them. But they *did* annoy me. I'm frankly sick of people
>> (not on this list) complaining that people who work on projects in
>> their own time, free of charge, "don't care enough" or "are ignoring
>> my requirement". We all do it, to an extent, and it's natural to get
>> frustrated, but the onus is on the person asking for help to be polite
>> and fair. And maybe this response was the one where I finally let that
>> frustration show through. I may read less email for a week or two,
>> just to get a break.
>>
>
> I had the same response as Paul: annoyed. And while Ivan thought he was
> using "emotional language to drive the point home that it's not some
> nitpick", it actually had the reverse effect on me and caused me not to
> care because I don't need to invite annoyance into my life when putting in
> my personal time into something.
>
> No one is saying people can't be upset and if you are ever upset there's
> something wrong; we're human beings after all. But those of us speaking up
> about the tone are saying that you can also wait until you're not so upset
> to write an email. This was never going to be resolved in an hour, so
> waiting an hour until you're in a better place to write an email that
> wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Let me express things right from the horse's mouth.
>
> The sole purpose of the tone was to not let the mesage be flat-out ignored.
> I had my neutral-toned, to-the-point messages to mailing lists flat-out
> ignored one too many times for reasons that I can only guess about.
> This time, the situation was too important to let that happen.
>
> Whatever anyone may think of this, it worked. I got my message through,
> and got the feedback on the topic that I needed to proceed in resolving the
> problem that caused it.
> I seriously doubt I could achieve that with a neutral-toned message just
> stating the facts: dry facts would not show ppl how this could be important
> ("ah, just another n00b struggling with Tkinter basics" or something).
>

As I said on the other thread, that doesn't make it any more acceptable as
over time it normalizes the behavior. If enough people want results—because
yes, sometimes things break, it's not fun, and sometimes things don't
receive response in the most timely fashion—they'll take that tone and
sometimes get what they want. Eventually it'll work enough that it becomes
more acceptable to behave that way, and eventually the people who are
willing to accept that type of behavior will be gone.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drop/deprecate Tkinter?

[Brian Curtin]

On Wed, May 2, 2018 at 5:37 PM Antoine Pitrou <solip...@pitrou.net> wrote:

> On Wed, 2 May 2018 23:28:22 +0200
> Antoine Pitrou <solip...@pitrou.net> wrote:
> > On Wed, 02 May 2018 21:24:07 +
> > Brian Curtin <br...@python.org> wrote:
> > > On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev <
> > > python-dev@python.org> wrote:
> > >
> > > > As https://bugs.python.org/issue33257 and
> > > > https://bugs.python.org/issue33316 showed, Tkinter is broken, for
> both
> > > > Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at
> > > > least, and no-one gives a damn.
> > > >
> > > > This seems to be a testament that very few people are actually
> > > > interested in or are using it.
> > > >
> > > > If that's so, there's no use keeping it in the standard library -- if
> > > > anything, because there's not enough incentive and/or resources to
> > > > support it. And to avoid screwing people (=me) up when they have the
> > > > foolishness to think they can rely on it in their projects --
> nowhere in
> > > > the docs it is said that the module is only partly functional.
> > >
> > >
> > > For the future, this is not how you communicate with the development
> > > mailing list of any open source software project. I would suggest
> reading
> > > https://www.python.org/psf/codeofconduct/ for some pointers on how
> people
> > > typically behave around here in particular.
> >
> > Perhaps it would be more constructive to address the OP's point than to
> > play speech police.
>
> To elaborate a bit: the OP, while angry, produced both a detailed
> analysis *and* a PR.  It's normal to be angry when an advertised
> feature doesn't work and it makes you lose hours of work (or, even,
> forces you to a wholesale redesign). Producing a detailed analysis and a
> PR is more than most people will ever do.
>

It may be normal to be angry when something doesn't work the way it should,
but analyzing and creating a PR aren't the gateway to normalizing this
behavior. Sending thousands of people this type of email isn't how it works.

To address their point: no, next topic.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drop/deprecate Tkinter?

[Brian Curtin]

On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> As https://bugs.python.org/issue33257 and
> https://bugs.python.org/issue33316 showed, Tkinter is broken, for both
> Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at
> least, and no-one gives a damn.
>
> This seems to be a testament that very few people are actually
> interested in or are using it.
>
> If that's so, there's no use keeping it in the standard library -- if
> anything, because there's not enough incentive and/or resources to
> support it. And to avoid screwing people (=me) up when they have the
> foolishness to think they can rely on it in their projects -- nowhere in
> the docs it is said that the module is only partly functional.


For the future, this is not how you communicate with the development
mailing list of any open source software project. I would suggest reading
https://www.python.org/psf/codeofconduct/ for some pointers on how people
typically behave around here in particular.

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Brian Curtin]

On Thu, Feb 1, 2018 at 4:19 AM, Oleg Sivokon <ol...@traiana.com> wrote:

>
> > so why shouldn’t the one with the most users?
>
> Because it makes compilation difficult, and cross-compilatin completely
> impossible?  Why is it difficult: a package maintainer needs to (1) buy MS
> Windows (2) create a special workflow for compiling on a different
> machine.  This is both costly and inconsistent with free-as-in-freedom...
> It makes cross-compilation impossible because libraries produced by any
> tool that can run on all target platforms are incompatible with Python
> binaries on MS Windows.
>
> Again, many languages (i.e. projects similar in size an purpose to
> CPython) took a different approach: they use GNU compilers to be able to
> compile cross-platform.  This is true for Ruby and Go at least.  I would
> need to investigate further, but I think these two examples should be
> enough.
>

They should be enough for *what*, though? You can tell people what everyone
else is doing, but the difference between that and what we have is
someone's time and effort.

> I’m likely biased because I work there and I’m the main intermediary with
> python-dev, but these days Microsoft is one of the strongest supporters of
> CPython. We employ the most core developers of any private company and we
> all are allowed work time to contribute, we provide full access to our
> development tools and platforms to all core developers and some prominent
> projects, we’ve made fixes, enhancements and releases or core products such
> as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY
> to support CPython development and users. As far as I know, ALL the Windows
> buildbots are running on Azure subscriptions that Microsoft provides
> (though managed by some awesome volunteers). You’ll see us at PyCon US
> under the biggest banner and we’ll have a booth filled with engineers and
> not recruiters. Crash reports from thousands of opted-in users come into
> our systems and have directly lead to both CPython and Windows bug fixes.
>
> Oh, so this is the real reason... well, corporate interests are hard to
> argue against.  But, this is an interesting statistic nevertheless.  Thanks
> for letting me know.


I think that's a mischaracterization of the situation. The MS toolchain was
chosen some time long before I (or Steve) got involved, and when I upgraded
us from VS2008 to VS2010 for 3.3 ~6 years ago I had several messages
similar to this thread. As much as Steve is unlikely to do the work to
initiate and maintain support of these other tools—whether due to his
employer's interests or his own—I too was unlikely to do work like this
thread is asking. In fact, the chances I would have done it were zero
because I was sitting on my couch upgrading our Visual Studio versions
because it let me do better stuff at my day job, though I was always open
to review patches that supported alternatives without major disruption.
However, they never came. I suspect the same could be said of Martin and
anyone else working in this area prior to that, because nothing has really
changed.

Like the previous times this sort of question has come up—and really, for
any question on this list—it ultimately turns into a matter of how much the
solution is wanted and how much effort people are willing to give to make
it happen. Historically, the former has had small amounts, and the latter
has had much smaller amounts. Without a change there I don't think one will
materialize in a released version of Python.

Brian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [edk2] Official port of Python on EDK2

[Richardson, Brian]

Thiebaud:

Thank you. I have started discussions within Intel for updating the UEFI 
CPython implementation to Python 3.x. The TianoCore community would appreciate 
contributions by people with Python experience to bring this code up to current 
standards.

Please review the contribution guidelines for TianoCore and let me know if you 
have any questions.
http://www.tianocore.org/contrib/ 

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thiebaud 
Weksteen
Sent: Wednesday, November 1, 2017 5:07 AM
To: python-dev@python.org
Cc: edk2-de...@lists.01.org
Subject: [edk2] Official port of Python on EDK2

Hi,

UEFI has become the standard for firmware (BIOS) interface. Intel has provided 
an open source implementation under the name EDK2 (part of the TianoCore 
initiative) [1] for some time. This implementation has evolved significantly 
and now provides the functionalities of a small OS with a standard library 
similar to POSIX.

In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2].
This port then evolved to 2.7.2 which is still defined as the reference port 
[3]. In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 [4]. 
Since then, both implementations have diverged from upstream and know 
vulnerabilities have not been fixed.

I would like to bring support for edk2 in the official Python repository to 
remediate this situation, that is officially support
edk2 as a platform. Technically, there would be three main aspects for the 
on-boarding work:

1) Fix headers and source to resolve definition conflicts, similarly to ABS 
definition in [5];
2) Add the edk2module.c [6] to handle platform-specific functionalities, 
similarly to the posixmodule.c;
3) Add the build configuration file [7] and necessary modifications within 
Python to handle the edk2 toolchain;

This work would target the master branch (that is Python 3). I would be 
interested in hearing your thoughts on this idea.

Thanks,
Thiebaud

[1] https://github.com/tianocore/edk2
[2] 
https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] 
https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf
___
edk2-devel mailing list
edk2-de...@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reorganize Python categories (Core, Library, ...)?

[Brian Curtin]

On Wed, Oct 4, 2017 at 5:52 AM, Victor Stinner 
wrote:

> Hi,
>
> Python uses a few categories to group bugs (on bugs.python.org) and
> NEWS entries (in the Python changelog). List used by the blurb tool:
>
> #.. section: Security
> #.. section: Core and Builtins
> #.. section: Library
> #.. section: Documentation
> #.. section: Tests
> #.. section: Build
> #.. section: Windows
> #.. section: macOS
> #.. section: IDLE
> #.. section: Tools/Demos
> #.. section: C API
>
> My problem is that almost all changes go into "Library" category. When
> I read long changelogs, it's sometimes hard to identify quickly the
> context (ex: impacted modules) of a change.
>
> It's also hard to find open bugs of a specific module on
> bugs.python.org, since almost all bugs are in the very generic
> "Library" category. Using full text returns "false positives".
>
> I would prefer to see more specific categories like:
>
> * Buildbots: only issues specific to buildbots
>

I would expect anything listed under buildbot to be about infrastructure
changes related to the running of build machines.

I think what you're getting at are the bugs that appear on build machines
that weren't otherwise caught during the development of a recent change. In
the end those are still just bugs in code, so I'm not sure I would group
them at such a high level. Wouldn't this be a better use of the priority
field?
___
Python-Dev mailing list
Python-Dev@python.org
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 553: Built-in debug()

[Brian Curtin]

On Wed, Sep 6, 2017 at 10:46 AM, Guido van Rossum  wrote:

> IIRC they indeed insinuate debug() into the builtins. My suggestion is
> also breakpoint().
>

I'm also a bigger fan of the `breakpoint` name. `debug` as a name is
already pretty widely used, plus breakpoint is more specific in naming
what's actually going to happen.

sys.breakpoint_hook() and sys.__breakpoint_hook__ seem reasonable
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Exact date of Python 2 EOL?

[Brian Curtin]

On Thu, Mar 23, 2017 at 12:19 PM, Barry Warsaw  wrote:
> On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote:
>
>>Can we pick an official date?
>
> Benjamin should pick the date and update PEP 373.

Not to start a bikeshed (calendarshed?), but how about 8 February
2020, or 2/8 as some in the US would write it?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Top python roles

[Brian Curtin]

There are a lot more than "guys" on this list, and it's for the development
of the Python language, not for recruiting.

Please take this elsewhere.

On Fri, Feb 3, 2017 at 20:10 Marta Daglow <mdag...@daglowconsulting.com>
wrote:

> Hi Guys,
>
>
>
> How are you guys?
>
>
>
> I’ve just gotten off the phone with a top engineering leader from a
> wonderful company in SF and they are looking for someone with python
> expertise.
>
>
>
> They are looking to hire many people in the range of $100 – 160K.
>
>
>
> Warm Regards,
>
>
>
> Marta
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brian%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I hope this won't be my last comment here ~ yet it may well be...

[Brian Curtin]

On Thursday, April 21, 2016, Burkhard Meier 
wrote:

> Please do allow me to share my humble experiences of being a software
> professional on a Windows platform.
>
> Almost 20 years.
>
> You know what; when I tried out 'sugar Linux' or Peppermint,,,the "admin'
> dude kicked me out 5 times in one sole eve,
>
> Maybe this is just *me*..
>
> You know what: I did have my time with this *open source community*...
>
> I was just asking a sincere question.
>
> C'mon
>
> This was rather very ridiculous.
>
>
>
As someone who spent many years as a Windows user and several years as a
contributor to the Windows build here, if you have constructive thoughts to
share on Python-on-Windows, please share them...but I can't decipher what
any of this message is actually about.

Additionally, you may want to try the python-list mailing list.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The next major Python version will be Python 8

[Brian Cain]

I bought it.  I will confess to being your first victim.  :)

On Thu, Mar 31, 2016 at 4:40 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Hi,
>
> Python 3 becomes more and more popular and is close to a dangerous point
> where it can become popular that Python 2. The PSF decided that it's
> time to elaborate a new secret plan to ensure that Python users suffer
> again with a new major release breaking all their legacy code.
>
> The PSF is happy to announce that the new Python release will be
> Python 8!
>
> Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
> it's also a mnemonic for PEP 8. By the way, each minor release will now
> multiply the version by 2. With Python 8 released in 2016 and one
> release every two years, we will beat Firefox 44 in 2022 (Python 64) and
> Windows 2003 in 2032 (Python 2048).
>
> A major release requires a major change to justify a version bump: the
> new killer feature is that it's no longer possible to import a module
> which does not respect the PEP 8. It ensures that all your code is pure.
> Example:
>
> $ python8 -c 'import keyword'
> Lib/keyword.py:16:1: E122 continuation line missing indentation or
> outdented
> Lib/keyword.py:16:1: E265 block comment should start with '# '
> Lib/keyword.py:50:1: E122 continuation line missing indentation or
> outdented
> (...)
> ImportError: no pep8, no glory
>
> Good news: since *no* module of the current standard library of Python 3
> respect the PEP 8, the standard library will be simplified to one
> unique module, which is new in Python 8: pep8. The standard library will
> move to the Python Cheeseshop (PyPI), to reply to an old and popular
> request.
>
>
> DON'T PANIC! You are still able to import your legacy code into
> Python 8, you just have to rename all your modules to add a "_noqa" suffix
> to the filename. For example, rename utils.py to utils_noqa.py. A side
> effect is that you have to update all imports. For example, replace
> "import django" with "import django_noqa". After a study of the PSF,
> it's a best option to split again the Python community and make sure
> that all users are angry.
>
>
> The plan is that in 10 years, at least 50% of the 77,000 packages on the
> Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
> the PSF will start to sponsor trolls to harass users of the legacy
> Python 3 to force them to migrate to Python 8.
>
>
> Python 8 is a work-in-progress (it's still an alpha version), the
> standard library was not removed yet. Hopefully, trying to import any
> module of the standard library fails.
>
> Don't hesitate to propose more ideas to make Python 8 more incompatible
> with Python 3!
>
> Note: The change is already effective in the default branch of Python:
> https://hg.python.org/cpython/rev/9aedec2dbc01
>
> Have fun,
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brian.cain%40gmail.com
>



-- 
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [ANNOUNCE] fuzzpy

[Brian Cain]

##

*---*
*fuzzpy: CPython fuzz tester is now available   *
*   *
*   Version 0.8 *
*https://bitbucket.org/ebadf/fuzzpy/*
*---*

I am pleased to announce the creation of a coverage-guided fuzz tester for
CPython.  It's a pretty small wrapper around LLVM's libFuzzer that enables
some powerful testing logic.  AFL (American Fuzzy Lop) is another popular
fuzzer lately -- libFuzzer is very similar in concept to AFL.  From what
I've read on list archives, Victor Stinner had previously done some good
fuzz testing on CPython using fusil.  This project should expand on that
concept.

I'd love to get feedback, suggestions, patches and anything else the list
can offer.


Q: What is fuzzpy for?
A: It's primarily for testing CPython itself, but could also be used for
individual python projects too.  Pure-python projects will be the simplest
to integrate at this point.  Also, interesting test cases output by fuzzpy
may end up being useful in testing others such as pypy, pyston, etc.

Q: What is a fuzz tester?
A: It modifies inputs to a test case in order to find unique/rare failures.

Q: What does "coverage-guided" mean?
A: It means that libFuzzer is able to witness the specific code executed as
a result of a given test case.  It feeds this information back into an
engine to modify the test cases to optimize for coverage.

Q: How can I help?
A1: donate cycles: build the project and crank away on one of the existing
tests.  Relative to other common fuzzing, it's awfully slow, so consider
throwing as many cycles as you can afford to.
A2: contribute tests: write a ~10-line python script that exercises a
feature that you think could benefit from fuzz testing.
A3: if there's interest, I can accept cryptocoin donations to purchase
cycles on a cloud server.


##


-- 
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Benchmark results across all major Python implementations

[Brian Curtin]

On Monday, November 16, 2015, Brett Cannon > wrote:

>
>
> On Mon, 16 Nov 2015 at 12:24 Maciej Fijalkowski  wrote:
>
>> Hi Brett
>>
>> Any thoughts on improving the benchmark set (I think all of
>> {cpython,pypy,pyston} introduced new benchmarks to the set).
>>
>
> We should probably start a mailing list
>

There is/was a sp...@python.org list.


> "speed.python.org" becoming a thing is generally stopped on "noone
>> cares enough to set it up".
>>
>
> Oh, I know. I didn't say this could be considered wishful thinking since I
> know I have enough on my plate to prevent me from making it happen.
>

There was a grant given years ago to improve some of this stuff but I don't
believe the work ever saw the light of day.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Benchmark results across all major Python implementations

[Brian Curtin]

On Monday, November 16, 2015, Brett Cannon > wrote:

>
>
> On Mon, 16 Nov 2015 at 12:24 Maciej Fijalkowski  wrote:
>
>> Hi Brett
>>
>> Any thoughts on improving the benchmark set (I think all of
>> {cpython,pypy,pyston} introduced new benchmarks to the set).
>>
>
> We should probably start a mailing list
>

There is/was a sp...@python.org list.


> "speed.python.org" becoming a thing is generally stopped on "noone
>> cares enough to set it up".
>>
>
> Oh, I know. I didn't say this could be considered wishful thinking since I
> know I have enough on my plate to prevent me from making it happen.
>

There was a grant given years ago to improve some of this stuff but I don't
believe the work ever saw the light of day.
___
Python-Dev mailing list
Python-Dev@python.org
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 506 secrets module

[Brian Gladman]

> On Sat, Oct 17, 2015 at 03:26:46AM +1100, Steven D'Aprano wrote:

[snip]
> But significanly, only *one* of the commenters has claimed to have
> any significant experience in crypto work, and I will quote him:

I didn't specifically claim the experience you requested in responding
to your post on comp.lang.python because I thought that this was implied
in making a response.

In fact I have 30+ years of experience in implementing cryptographic
code (much involving random numbers) so there were at least two
respondents who could have made this claim.

For the record, I consider it desirable in code involving security to
exhibit the minimum functionality neccessary to get a job done. This is
because funtionality and security very often work against each other in
building secure systems.

I hence support your conclusion that the module should offer randbelow
alone.  I would oppose offering randomrange (or offering more than one
of them) since this will pretty well guarantee that, sooner or later,
someone will make a mistake in using the extra functionality and
possibly deploy an insecure application as a result.

   Brian Gladman
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 506 secrets module

[Brian Gladman]

> Guido van Rossum wrote:

> I'm fine with dropping the 3rd arg. But I find the argument to
> introduce a new spelling for 1-arg randrange() weak.

I should stress that my preference for randbelow over randrange was
based purely on their proposed functionality and not on their names.

I do however have a preference for a function of minimum required
functionality, i.e. one that allows only a single parameter (N) to
set the range 0 .. N-1.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Washington DC Python sprint report

[Brian Ray]

I would like to propose a mixed core-dev none-core-dev sprint to occur in
Chicago within the next couple months. ChiPy (http://chipy.org) can help
sponsor. I am going to share my thoughts on this with the group-organizers <
group-organiz...@python.org> list first in order to get some feedback. Post
found here:
https://mail.python.org/pipermail/group-organizers/2015-September/000441.htm


Regards,

Brian Ray
ChiPy organizer
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Washington DC Python sprint report

[Brian Ray]

meant:
https://mail.python.org/pipermail/group-organizers/2015-September/000441.html
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A quick word on top posting

[Brian Curtin]

On Monday, July 20, 2015, Emile van Sebille em...@fenx.com wrote:

 Your +infinity could have easily been top posted -- particularly when
 there's no in-line comments that require context.

 just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,

 Emile


 On 7/19/2015 2:16 PM, Mark Lawrence wrote:

 On 19/07/2015 22:06, Brett Cannon wrote:


 snip

  There is absolutely no reason we can't keep discussions cordial,
 friendly, and on-point on this list and prevent this sort of debacle
 from occurring again.


 +infinity


Empty replies like a fake vote should just not occur in general. That's not
usually an issue on this list, but I see many others plagued by such
responses and hope we never end up on that path (especially people +1'ing a
+1...). Remember that not only do we need to keep emails to the
characteristics Brett mentioned for the sake of having a healthy
discussion list, we should strive to keep the noise as close to zero as
possible as mails sent to this list reach *a lot* of people.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Brian Curtin]

On Thu, May 28, 2015 at 11:23 AM, Chris Barker chris.bar...@noaa.gov wrote:
 I'm confused:

 Doesn't py2exe (optionally) create a single file executable?

 And py2app on the Mac creates an application bundle, but that is
 more-or-less the equivalent on OS-X (you may not even be able to have a
 single file executable that can access the Window Manager, for instance)

 Depending on what extra packages you need, py2exe's single file doesn't
 always work, but last I tried, it worked for a fair bit (I think all of the
 stdlib).

 I don't know what PyInstaller or others create. And I have no idea if there
 is a linux option -- but it seems like the standard of practice for an
 application for linux is a bunch of files scattered over the system anyway
 :-)

 Yes, the resulting exe is pretty big, but it does try to include only those
 modules and packages that are used, and that kind of optimization could be
 improved in any case.

 So is something different being asked for here?

 Barry Warsaw wrote:
 I do think single-file executables are an important piece to Python's
 long-term competitiveness.

 Really? It seems to me that desktop development is dying. What are the
 critical use-cases for a single file executable?

Donald mentioned one earlier: command line utilities. I want a single
CLI I can deploy to my customers that doesn't make them have to
install Python or even know it's Python at all. My users write code in
all types of languages on all OSes, but I should be able to produce
one thing that they can all use. Donald himself initiated the CLI in
particular I'm talking about, but Go is picking up steam here as we
have other utilities that quickly solved the write one thing, every
user can run it immediately, no one knows/cares what it's written in

When I worked on Ubuntu One, I was the Windows guy responsible for
making sure the end-user experience was the same there as it was on
Ubuntu. On Ubuntu we were a part of the base install and didn't have
to worry about much. On Windows we had none of that, not even the C
runtime, so we had some pre-installer work to do, and then a bunch of
py2exe hacking to make everything play nicely and transparently.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Brian Curtin]

On Fri, Apr 3, 2015 at 7:25 AM, Paul Moore p.f.mo...@gmail.com wrote:
 On 3 April 2015 at 10:56, Larry Hastings la...@hastings.org wrote:
 My Windows development days are firmly behind me.  So I don't really have an
 opinion here.  So I put it to you, Windows Python developers: do you care
 about GnuPG signatures on Windows-specific files?  Or do you not care?

 I don't have a very strong security background, so take my views with
 a pinch of saly, but I see Authenticode as a way of being sure that
 what I *run* is OK. Whereas a GPG signature lets me check that the
 content of a file is as intended. So there are benefits to both, and I
 thing we should continue to provide GPG signatures. (Disclaimer: I've
 never in my life actually *checked* a GPG signature for a file...)

I haven't been on Windows in a bit, but this is my
understanding/expectation as well.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] version of freshly built 2.7 python

[Brian Curtin]

On Thu, Apr 2, 2015 at 10:19 PM, Ethan Furman et...@stoneleaf.us wrote:
 On 04/02, Alexander Walters wrote:
 On 4/2/2015 21:29, Ethan Furman wrote:

 I just built the latest version of Python 2.7 on my development machine -- 
 or so I thought.  When I invoke it, I get:

Python 2.7.6+ (2.7:1beb3e0507fa, Apr  2 2015, 17:57:53)

 Why am I not seeing 2.7.9?

 Are you building from mercurial or a source tarball?

 Mercurial:

   ethan@code:~/source/python/python2.7$ hg parent
   changeset:   90450:1beb3e0507fa
   branch:  2.7
   parent:  90434:b428b803f71f
   user:Zachary Ware zachary.w...@gmail.com
   date:Thu Apr 24 13:20:27 2014 -0500
   files:   Lib/test/test_itertools.py
   description:
   Issue #21346: Fix typos in test_itertools.  Patch by Brian Kearns.

That's almost a year old. Update it?
___
Python-Dev mailing list
Python-Dev@python.org
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 7

[Brian Curtin]

On Fri, Mar 20, 2015 at 10:02 PM, Neil Girdhar mistersh...@gmail.com wrote:
 The code reviews I got asked me to revert PEP 7 changes.  I can understand
 that, but then logically someone should go ahead and clean up the code.
 It's not high risk if you just check for whitespace equivalence of the
 source code and binary equivalence of the compiled code.  The value is for
 people who are new to the codebase.

There are a lot of areas of the C code that aren't explicitly or
directly tested, so yes, a lot of changes are high risk, especially in
bulk. While a one time change while checking binary equivalence would
do it, it's also a huge amount of churn just to follow a guideline.
Without an automated checker for the guidelines, if things get in they
just get in, and sometimes you can modify them while making
improvements to the code, but sometimes it depends on what exactly
you're doing as well. On top of this, we already disallow mass PEP 8
changes to avoid the churn there as well, and it took a good bit of
convincing for another semi-recent mass change (although I can't
remember the topic, but it was deemed safe enough to make).

Another common issue with mass code churn like this is that it affects
tooling, such as `hg blame`
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does pip upgrade to a random version?

[Brian Curtin]

On Wed, Feb 4, 2015 at 1:04 PM, Martin Thoma i...@martin-thoma.de wrote:
 Could somebody please have a look at the following SO question? It seems as
 if I might have found a bug in pip:
 http://stackoverflow.com/q/28282671/562769

 TL;DR of the SO question:
 I executed `$ sudo pip install hwrt --upgrade` mutiple times and got a -
 seemingly random - version of hwrt installed.

Try the pip mailing list: https://groups.google.com/forum/#!forum/pypa-dev
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] development

[Brian Curtin]

On Wednesday, January 28, 2015, Alan Armour aarm...@cipmail.org wrote:

 can you guys develop an audio kit that works around jackd or on windows
 directx? and tutorials to write synthesizers.  and drum machines like a
 tr-606 with triggers ( I want to trigger a drum synth like the March
 UDS(Soviet) Coolest drum synth EVER.


 Also, I think you should have a way to write assembler functions to really
 optimize speed and have a table and stuff for assembler learning for all
 cpus and stuff. even asm graphics and audio would be super useful in some
 instances.


That's not how this works.

If you would like to write all of that code and allow it to mature in the
wild while building a following around it and ensuring it is the best of
its kind and a general enough solution to be included in the Python
standard library, inclusion of that could be discussed in the future.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

[Brian Curtin]

On Tue, Jan 13, 2015 at 4:36 PM, Victor Stinner
victor.stin...@gmail.com wrote:
 2015-01-13 23:18 GMT+01:00 Steve Dower steve.do...@microsoft.com:
 Technically, Python 3.5 requires Visual Studio 2015

 For me, it's *very* difficult to find how to install Visual Studio.
 There are many different websites and web pages which mention Visual
 Studio with a lot of versions and flavors (Express, Community,
 Ultimate, etc.).

 Visual Studio 2015 was not released yet :-/

 My VM has only a disk of 40 GB. Only 12 GB are free. I already have VS
 2008 Express and VS 2010 Express installed. I understood that
 Ultimate includes a *lot* of things, not only a C compiler.

 I found a free Visual Studio which is in fact Visual Studio 2013
 Community and I read that it's not free.

 I sent an email to Brian Curtin to ask to renew my MSDN account. He
 didn't reply yet.

I saw that and will send it on, but it's still going to take some time
to process - usually a week or so.

In the meantime, the first result searching for Visual Studio 2015
came up with 
http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx,
which seems to give you VS2015. I haven't tried to run it since I'm
not on Windows at the moment, but it looks correct.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

[Brian Curtin]

On Tue, Jan 13, 2015 at 4:04 PM, Victor Stinner
victor.stin...@gmail.com wrote:
 Hi,

 To compile Python on Windows, there are a few information in the
 Developer Guide:
 https://docs.python.org/devguide/setup.html#windows-compiling

 Python 3.5 now requires Visual Studio 2010 *SP1*, or newer Visual Studio:
 http://bugs.python.org/issue22919#msg233637

 I found PCbuild\readme.txt which is not mentionned in the devguide :-/
 https://hg.python.org/cpython/file/56f717235c45/PCbuild/readme.txt
 (at least not on the Windows section of the setup page)

 I found some clues to build OpenSSL to be able to build the Python ssl
 module, but I still have issues.

 Is there a more complete documentation?

 I found how to install svn.exe, perl.exe and nasm.exe, but not how to
 install nmake.exe. I don't know the command to build OpenSSL.

For nmake, are you running this in a regular Command Prompt or in the
Visual Studio Command Prompt? The latter sets the right environment to
point you to some tools that VS installs, including nmake.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Brian Curtin]

On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro
skip.montan...@gmail.com wrote:

 On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa ma...@pacujo.net wrote:

 IMO, you should consider forking your library code for Python2 and
 Python3.


 I don't get the idea that Brett Cannon agrees with you:

 http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23

 While he doesn't explicitly say so, I got the distinct impression reading
 his recent blog post that he supports one source, not forked sources.

 In the absence to evidence to the contrary, I think of Brett as the most
 expert developer in the porting space.

I'm a few inches shorter than Brett, but having done several sizable
ports, dual-source has never even on the table. I would prefer the
run 2to3 at installation time option before maintaining two versions
(which I do not prefer at all in reality).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Brian Curtin]

On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano st...@pearwood.info wrote:
 On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:

 But I strongly believe that if we want to do the right thing for the
 long term, we should switch to GitHub.

 Encouraging a software, or social, monopoly is never the right thing for
 the long term.

 http://nedbatchelder.com/blog/201405/github_monoculture.html


 I promise you that once the pain of the switch is over you will feel
 much better about it. I am also convinced that we'll get more
 contributions this way.

 I'm sure that we'll get *more* contributions, but will they be *better*
 contributions?

 I know that there are people who think that mailing lists are old and
 passe, and that we should shift discussion to a social media site like
 Reddit. If we did, we'd probably get twenty times as many comments, and
 the average quality would probably plummet. More is not necessarily a
 good thing.

If we need to ensure that we're getting better contributions than we
are now, then we should be interviewing committers, rejecting
newcomers (or the opposite, multiplying core-mentors by 100), and
running this like a business. I've written some crappy code that got
committed, so I should probably be fired.

Enabling our community to be active contributors is an important
thing. Give them a means to level up and we'll all be better off from
it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [IPython-User] proper animation in notebook?

[Brian Blais]

On Sat, Oct 11, 2014 at 4:07 AM, Steve Holden st...@holdenweb.com wrote:
 I found the following code appeared to work without any issues:

 %matplotlib inline
 import numpy as np
 import matplotlib.pyplot as plt

 import sys
 import time
 from IPython.display import display, clear_output

 x=np.linspace(0,6,100)
 for t in np.linspace(0,20,100):
clear_output(wait=True)
f=plt.figure(figsize=(10,10))
plt.plot(np.sin(x)*np.sin(t),'-o')
plt.gca().set_ylim([-1,1])
display(f)
plt.close()

 Further queries should be sent to the python-dev list, as this one is being
 phased out.


Running this code makes a working animation, but watching the memory
usage of the python2.7 process it is clear there is a memory leak - it
starts around 150 M and climbs to 300 M.  Running for longer keeps
this going.  I think the figures are being generated, cleared in the
notebook, but still existing somehow in the background.  Is there a
way to determine if this is happening?  Is there a proper way to write
the animation to avoid this?

thanks!

Brian Blais

-

 bbl...@gmail.com
 http://web.bryant.edu/~bblais
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of C compilers for Python on Windows

[Brian Curtin]

On Thu, Oct 9, 2014 at 7:29 PM, Victor Stinner victor.stin...@gmail.com wrote:
 Hi,

 Windows is not the primary target of Python developers, probably
 because most of them work on Linux. Official Python binaries are
 currently built by Microsoft Visual Studio. Even if Python developers
 get free licenses thanks for Microsoft, I would prefer to use an open
 source compiler if it would be possible. So *anyone* can build Python
 from scatch. I don't like the requirement of having a license to build
 Python. The free version (Visual Studio Express) only supports 32-bit
 and doesn't support PGO build (Profile-Guided Optimizations, which are
 disabled if I remember correctly because of compiler bugs).

 I know that it's hard to replace Visual Studio. I don't want to do it
 right now, but I would like to discuss that with you.

Although I'm not very active around here much anymore, I was primarily
working on Windows things within the last few years.

While we have a lot of Windows users, we don't have a lot of Windows
contributors. The huge amount of churn necessary to make a change away
from VS, or the more likely move to make it possible to support both
VS and insert other compiler, seems like a large amount of work that
doesn't turn up much of a benefit. Especially for a platform with
constrained developer availability, working software trumps all, so I
don't expect that a project like this is going to see the regular
contributors shifting their focus away from improving Python as it is.

With that said, I do see the benefit of being able to build Python
with a free compiler. It would be great for us to be able to say it's
always built with free tools, but I'm not sure who's going to make
this happen...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Idea to support lazy loaded names.

[Brian Allen Vanderburg II]

I've got an idea for Python but don't know where to post it.  It seems
like this may be the right place.

When developing Python libraries (and any other language for that
matter), items are separated into modules for organization and other
purpose.  The following is an example fake framework to illustrate this:

  mini-framework/
__init__.py
app.py
  class BaseApplication
  class Application
  class ProxyApplication
config.py
  class Config
  class ConfigLoader
template.py
  class Template
  class TemplateCompiler
  class TemplateManager

In order to be used externally, one must reference the module:

  from miniframework.app import Application
  from miniframework.template import TemplateManager

This can be solved by importing these values directly in __init__.py.
However this requires fully loading those imported modules:

  __init__.py:
from .app import BaseApplication, Application, ProxyApplication
from .config import Config, ConfigLoader
from .template import Template, TemplateCompiler, TemplateManager
  
One idea I had was to support lazy imported names.  I've seen some
frameworks implement this in various means, and figured the idea is good
to be part Python.

The idea is that for a new module attribute to exist: __lazyload__.
During the access of any attribute for a module, the following would
happen:

  * If the named attribute already exists, use it
  * If the named attribute does not already exist:
* If a lazy load of the name has already been attempted, result in
  a NameError
* If a lazy load of the name has not yet been attempted:
   * Check the __lazyload__ module attribute for the name, perform
 the loading operation and assign the module attribute the
 value if found or result in a NameError
   * Even if not found, set a flag that lazy load has been
 attempted so it will not be attempted again for the same name

The __lazyload__ attribute is intended to be a dictionary.  The key of
the dictionary is the name of the attribute that would be set/tested
for in the module.  The value of the dictionary is a string that
represents either the module name to load or the module name and
attribute to load.  If the value starts with a dot, then it is treated
as a relative import relative to the module/package containing the
__lazyload__ value.

With this idea, the packages __init__.py file could look like this:

  __lazyload__ = {
'BaseApplication': '.app.BaseApplication',
'Application': '.app.Application',
...
  }
   
The end use of the package (and even the developer) can then perform an
import as follows:

  from miniframework import Application

instead of:

  from miniframework.app import Application

This allows the public api be be cleaner, while still being efficient
by not loading all modules in __init__.py until the value is actually
accessed.



Brian Allen Vanderburg II
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Brian Curtin]

On Tue, Sep 2, 2014 at 5:53 PM, Nick Coghlan ncogh...@gmail.com wrote:


 On 3 Sep 2014 08:15, Victor Stinner victor.stin...@gmail.com wrote:
 
  x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't
  have to this platform, I don't know how to fix it.

 Sorry, I haven't been a very good maintainer for that buildbot (the main
 reason it never graduated to the stable list). If you send me your public
 SSH key, I can add it (I think - if not, I can ask Luke to do it).
 Alternatively, CentOS 6 may exhibit the same problem.

 From a completely different perspective, does anyone have experience with
 using BuildBot with OpenStack hosted clients? We may be able to take
 advantage of the PSF's new(ish) Rackspace infrastructure to provide more
 stable test VMs.

Is this a Buildbot feature (as in Buildbot master spins up VMs fresh for a
test run, or something), or do you just want to spin up a bunch of VMs,
give access, and we configure them the same as we do today?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bluetooth 4.0 support in socket module

[Brian Curtin]

On Mon, Jul 14, 2014 at 10:30 AM, Skip Montanaro s...@pobox.com wrote:

 On Mon, Jul 14, 2014 at 8:57 AM, Tim Tisdall tisd...@gmail.com wrote:
  Is there some online documentation with guidelines on how to contribute?

 http://lmgtfy.com/?q=contribute+to+python


This response is unacceptable.

Tim: check out https://docs.python.org/devguide/ and perhaps look at the
core-mentorship[0] mailing list while coming up with your first
contributions. It's a good first step to getting some guidance on the
process and getting some eyes on your early patches.

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

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

[Brian Curtin]

On Wed, Jun 11, 2014 at 9:43 PM, Ethan Furman et...@stoneleaf.us wrote:
 On 06/11/2014 07:12 PM, Chris Angelico wrote:

 On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico ros...@gmail.com wrote:

 ISTM what you want is not shell=True, but a separate function that
 follows the system policy for translating a command name into a
 path-to-binary. That's something that, AFAIK, doesn't currently exist
 in the Python 2 stdlib, but Python 3 has shutil.which(). If there's a
 PyPI backport of that for Py2, you should be able to use that to
 figure out the command name, and then avoid shell=False.


 Huh. Next time, Chris, search the web before you post. Via a
 StackOverflow post, learned about distutils.spawn.find_executable().


 -- import sys
 -- sys.executable
 '/usr/bin/python'

For finding the Python executable, yes, but the discussion and example
are about a 2.x version of shutil.which
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
 On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower steve.do...@microsoft.com 
 wrote:
 Thoughts/comments/concerns?

 My only concern is support for elderly versions of Windows, in
 particular: XP.  I seem to recall the last let's update our MSVC
 version discussion dying off because of XP support.  Even though MS
 has abandoned it, I'm not sure whether we can yet.

 If that's a non-issue, or if we can actually drop XP support, I'm all for it.

Extended support ended in April of this year, so I think we should put
XP as unsupported for 3.5 in PEP 11 -
http://legacy.python.org/dev/peps/pep-0011/

I seem to remember that we were waiting for this anyway.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
 On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com wrote:
 Chris Angelico wrote:
 On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com 
 wrote:
 What this means for Python is that C extensions for Python 3.5 and later 
 can be built using any version of MSVC from 14.0 and later.

 Oh, if only this had been available for 2.7!! Actually... this means that 
 14.0 would be a good target for a compiler change for 2.7.x, if such a 
 change is ever acceptable.

 Maybe, but I doubt it will ever be acceptable :)

 Well, there were discussions. Since Python 2.7's support is far
 exceeding the Microsoft promise of support for the compiler it was
 built on, there's going to be a problem, one way or the other. I don't
 know how that's going to end up being resolved.

We're going to have to change it at some point, otherwise we're going
to have people in 2018 scrambling to find VS2008, which will be 35
versions too old by then. No matter what we do here, we're going to
have a tough PR situation, but we have to make something workable. I'd
rather cause a hassle than outright kill extensions.

I would probably prefer we aim for VS 14 for 3.5, and then explore
making the same change for the 2.7.x release that comes after 3.5.0
comes out. Lessons learned and all that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg m...@egenix.com wrote:
 On 06.06.2014 20:25, Brian Curtin wrote:
 On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
 On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com 
 wrote:
 Chris Angelico wrote:
 On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com 
 wrote:
 What this means for Python is that C extensions for Python 3.5 and later 
 can be built using any version of MSVC from 14.0 and later.

 Oh, if only this had been available for 2.7!! Actually... this means that 
 14.0 would be a good target for a compiler change for 2.7.x, if such a 
 change is ever acceptable.

 Maybe, but I doubt it will ever be acceptable :)

 Well, there were discussions. Since Python 2.7's support is far
 exceeding the Microsoft promise of support for the compiler it was
 built on, there's going to be a problem, one way or the other. I don't
 know how that's going to end up being resolved.

 We're going to have to change it at some point, otherwise we're going
 to have people in 2018 scrambling to find VS2008, which will be 35
 versions too old by then. No matter what we do here, we're going to
 have a tough PR situation, but we have to make something workable. I'd
 rather cause a hassle than outright kill extensions.

 I would probably prefer we aim for VS 14 for 3.5, and then explore
 making the same change for the 2.7.x release that comes after 3.5.0
 comes out. Lessons learned and all that.

 Are you sure that's an option ? Changing the compiler the stock
 Python from python.org is built with will most likely render
 existing Python extensions built for 2.7.x with x  (release that comes
 after 3.5.0) broken, so users and installation tools will end up
 having to pay close attention to the patch level version of Python
 they are using... which is something we wanted to avoid after
 we ran into this situation with 1.5.1 and 1.5.2 a few years ago.

None of the options are particularly good, but yes, I think that's an
option we have to consider. We're supporting 2.7.x for 6 more years on
a compiler that is already 6 years old. Something less than awesome
for everyone involved is going to have to happen to make that
possible.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 10:56 PM,  dw+python-...@hmmz.org wrote:
 On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:

 None of the options are particularly good, but yes, I think that's an
 option we have to consider. We're supporting 2.7.x for 6 more years on
 a compiler that is already 6 years old.

 Surely that is infinitely less desirable than simply bumping the minor
 version?

It's definitely not desirable, but simply bumping the minor version
is not A Thing.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft don...@stufft.io wrote:

 On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:

 On Fri, Jun 6, 2014 at 10:56 PM,  dw+python-...@hmmz.org wrote:
 On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:

 None of the options are particularly good, but yes, I think that's an
 option we have to consider. We're supporting 2.7.x for 6 more years on
 a compiler that is already 6 years old.

 Surely that is infinitely less desirable than simply bumping the minor
 version?

 It's definitely not desirable, but simply bumping the minor version
 is not A Thing.

 Why? I mean even if it’s the same thing as 2.7 just with an updated
 compiler that seems like a better answer than having to deal with
 2.7.whatever suddenly breaking all C exts.

Because then we have to maintain 2.8 at a time when no one even wants
to maintain 2.7?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Fri, Jun 6, 2014 at 11:42 PM,  dw+python-...@hmmz.org wrote:
 On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:

  Is it really any difference in maintenance if you just stop applying
  updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
  new compiler then there should be no functional difference between
  doing that and doing a 2.7.whatever except all of the tooling that
  relies on the compiler not to change in micro releases won’t
  suddenly break and freak out.

 If the only difference between 2.7 and 2.8 is the compiler used on
 Windows, what happens on Linux and other platforms? A Python 2.8 would
 have to be materially different from Python 2.7, not just binarily
 incompatible on one platform.

 Grrmph, that's fair. Perhaps a final alternative is simply continuing
 the 2.7 series with a stale compiler, as a kind of carrot on a stick to
 encourage users to upgrade? Gating 2.7 life on the natural decline of
 its supported compiler/related ecosystem seems somehow quite a gradual
 and natural demise.. :)

Adding features into 3.x is already not enough of a carrot on the
stick for many users. Intentionally leaving 2.7 on a dead compiler is
like beating them with the stick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Jun 6, 2014 6:01 PM, Sturla Molden sturla.mol...@gmail.com wrote:

 Brian Curtin br...@python.org wrote:

  Adding features into 3.x is already not enough of a carrot on the
  stick for many users. Intentionally leaving 2.7 on a dead compiler is
  like beating them with the stick.

 Those who want to build extensions on Windows will just use MinGW
 (currently GCC 2.8.2) instead.

Well we're certainly not going to assume such a thing. I know people do
that, but many don't (I never have).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Brian Curtin]

On Jun 6, 2014 6:33 PM, Sturla Molden sturla.mol...@gmail.com wrote:

 Brian Curtin br...@python.org wrote:

  Well we're certainly not going to assume such a thing. I know people do
  that, but many don't (I never have).

 If Python 2.7 users are left with a dead compiler on Windows, they will
 find a solution. For example, Enthought is already bundling their Python
 distribution with gcc 2.8.1 on Windows.

Again, not something I think we should depend on. A lot of people use
python.org installers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Download Counts (was: Language Summit notes)

[Brian Curtin]

On Fri, Apr 18, 2014 at 1:31 PM, Antoine Pitrou solip...@pitrou.net wrote:
 I don't think we have recent download numbers since the Website
 overhaul (do we?), but Python 3 isn't an experimental concept
 language anymore (it hasn't been since 3.3 or 3.2, I'd say).

Using the old logs, which are still good through 2013, I've found the following:

The first year of a release series (month of final release month + 12mos):
2.6.x - 10.3 Million
2.7.x - 10.26M
3.2.x - 5.84M
3.3.x - 13.1M

2013 downloads (out of 34.79M across all possible versions):
2.6.x - 1.9M
2.7.x - 14.3M
3.2.x - 1.03M
3.3.x - 13.85M

3.3 had a big first year of availability (Oct '12-'13), and throughout
2013 it represented 48% of those versions listed above.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Download Counts (was: Language Summit notes)

[Brian Curtin]

On May 28, 2014 12:49 PM, Brian Curtin br...@python.org wrote:

 On Fri, Apr 18, 2014 at 1:31 PM, Antoine Pitrou solip...@pitrou.net
wrote:
  I don't think we have recent download numbers since the Website
  overhaul (do we?), but Python 3 isn't an experimental concept
  language anymore (it hasn't been since 3.3 or 3.2, I'd say).

 Using the old logs, which are still good through 2013, I've found the
following:

 The first year of a release series (month of final release month + 12mos):
 2.6.x - 10.3 Million
 2.7.x - 10.26M
 3.2.x - 5.84M
 3.3.x - 13.1M

 2013 downloads (out of 34.79M across all possible versions):
 2.6.x - 1.9M
 2.7.x - 14.3M
 3.2.x - 1.03M
 3.3.x - 13.85M

 3.3 had a big first year of availability (Oct '12-'13), and throughout
 2013 it represented 48% of those versions listed above.

Sorry for not being explicit: these are download counts for Windows
installers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Download Counts (was: Language Summit notes)

[Brian Curtin]

On May 28, 2014 4:06 PM, Eli Bendersky eli...@gmail.com wrote:




 On Wed, May 28, 2014 at 11:10 AM, Guido van Rossum gu...@python.org
wrote:

 Is the Windows/Mac ratio still 70/30, with Linux in the single digits?


 Most Linux installs go through package managers which don't count here,
no?

I'll have to run something for the other non-Windows files, but the single
digit Linux downloads he meant are the tarballs. We'll (probably) never
know the true counts in the Linux world because of how pervasive Python is
within basically every distro, but that's also likely the case on Mac.

With Windows, since you must download Python it to use it, the numbers we
see are probably the most useful on their own. I'm giving a talk at PyCon
Russia that covers some of these numbers, so I'll probably try to dig up
more and turn it into a blog post.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Questions regarding Windows buildbots

[Brian Curtin]

On Mon, May 12, 2014 at 5:16 PM, Claudiu Popa pcmantic...@gmail.com wrote:
 Hello!

 I'm working on a patch for issue bugs.python.org/issue8579 (Add
 missing tests for FlushKey, LoadKey, and SaveKey in winreg). This
 issue requires the SeBackupPrivilege in order to use LoadKey and
 SaveKey. While acquiring the privilege
 isn't very complicated using ctypes, it fails with
 ERROR_NOT_ALL_ASSIGNED (1300) when the
 user has Administrative privileges, but it's not an Administrator,
 problem which can be eluded by
 running the script with elevated privileges. This leads me to a couple
 of questions:

 - should a Windows test be skipped if it can't acquire a certain privilege?

Yes. Check out any of the os.symlink tests - they're currently skipped
when the symlink privilege isn't held.

 - If we can acquire the privilege by elevating our process, does the
 Windows buildbots have UAC
  enabled and if so, how's the notification setting configured? For
 instance, elevating a process will
  trigger a new UAC window with the message Do you want to allow the
 following program from an unknown publisher to make  changes to this
 computer? on the recommended configuration, but this doesn't happen
 when the configuration is set to  Never notify.

That probably depends on how each machine is setup. If they happen to
get blocked on any individual slave, we'll just have to ask the owner
to change that setting.

Currently there are no Windows build slaves running as administrator.
I used to have one but the machine died and I never replaced it. I
also said a few months ago that I would get one setup again, but that
hasn't happened yet. I can get a new machine up and running but
probably not until next week as I'm at a conference.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tix version needed to build 2.7 Windows installer?

[Brian Curtin]

On Fri, May 9, 2014 at 12:00 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
 On Thu, May 8, 2014 at 4:20 PM, Zachary Ware
 zachary.ware+py...@gmail.com wrote:
 I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple
 of weeks ago (see http://bugs.python.org/issue21303), but hadn't
 gotten anything done with Tix yet.  It should just need python.mak
 updated to point to Tcl/Tk 8.5.15; it's on my list to get fixed as
 soon as I can.

 Tix for 2.7 is now
 http://svn.python.org/projects/external/tix-8.4.3.5.  You can build it
 with this monster of a command, run from tix-8.4.3.5\win:

 nmake -f python.mak DEBUG=0 MACHINE=IX86 COMPILERFLAGS=-DWINVER=0x0500
 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0
 INSTALL_DIR=..\..\tcltk all

 Use install instead of all after building to install it to
 ..\..\tcltk.  Set DEBUG and MACHINE as needed; DEBUG does not need to
 be set if you're building Release, but MACHINE always has to be set so
 that Tix uses the right build dir for Tk (IX86 for 32-bit, AMD64 for
 64-bit).

Awesome, thanks!

So I now have a fully working setup, at least for 32-bit, and have
backported the Path option from 3.3
(http://hg.python.org/cpython/rev/a9d34685ec47). I ran into an issue
with win32com getting a 64-bit installer built but didn't have time to
look into it yet.

If anyone wants to try a 2.7 installer with that Path option, here's a
copy: http://briancurtin.com/python-dev/python-2.7.msi (this is not
signed, it'll warn you about that).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tix version needed to build 2.7 Windows installer?

[Brian Curtin]

This is mostly a question for Martin, but perhaps someone else would also know.

I'm trying to build the 2.7 installers so I can backport the path
option from 3.3, but I can't seem to figure out which version of Tix
is necessary to have a complete build. So far any of them on
http://svn.python.org/projects/external don't appear to be configured
to work with the combination of tcl and tk that are used on 2.7, per
the buildbot external scripts. It's another issue that Tix isn't even
downloaded by the scripts, but I'll do it manually right now just to
get this going.

Any tips?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7.7. on Windows

[Brian Curtin]

On Mon, Apr 28, 2014 at 3:07 PM, Mike Miller python-...@mgmiller.net wrote:

 On 04/29/2014 05:12 AM, Steve Dower wrote:

 This would be an incredibly painful change that would surprise and hurt a
 lot of
 people.


 Hi, I think incredibly painful is overstating the case a bit. ;)  We're
 talking about an installer default, a setting that would still be changeable
 as it always has, that by definition only will affect brand new installs.


 Yes, it is possible for a non-admin user to install arbitrary packages
 into a
 place where an admin user may inadvertently run it, thereby providing
 escalation
 of privilege. On the other hand, that applies to a lot of development
 tools,
 especially since most users on Windows these days are actually limited
 administrators - ANYTHING they install could run when they elevate a
 certain
 process.


 None of Microsoft's Dev tools install to C:\, rather to ProgramFiles.  The
 fact that another security issue may exist is not a good justification for
 creating additional.


 On the other hand, Python from python.org is a tool that should only be
 installed by those who are prepared to manage it. On Windows it is easy
 enough
 to have a second, secured copy for your admin scripts and an unsecured
 copy for
 non-admin tasks.


 This sounds like the perspective of someone highly technical, forgetting
 that new users will be installing python as well and vastly outnumber us.
 Normal people need help to avoid security issues.

 Microsoft's guidelines on where to install software are clear, and don't
 make exceptions that tools should be installed to the root of the drive to
 bypass file system permissions, for convenience.


 I'm not sure what change you are proposing here... doesn't the installer
 already
 have an option to add to PATH? I'm sure I keep disabling it.


 No, it does not.  Unless it got slipped in when I wasn't looking.

 It should be an option though, I think everyone would agree.

The option to add the current install to your path was added 3.3.

 python.exe on my PATH because I have 10+ versions installed at any one
 time. I


 Remember, python-dev's are not the target users of this package, and are a
 rather minuscule fraction of the user base.

Knowing which Python you want on your path and that you want it on
your path at all is somewhat of an advanced usage. While beginners do
want to just open up cmd and type python and have it work, there are
better ways to accomplish that which don't involve system-wide path
manipulation or installation changes.

Several PC manufacturers have been known to use Python for various
system utilities, which is how Python sometimes ends up in the path on
your grandma's Dell*. Even for a beginner who just wants python to
work, we need to be careful to not wreck their entire system by
helping them get our fresh Python install to show up.

A more reasonable way to help beginners would be to create a shortcut
somewhere that starts up cmd with a modified path. They can do
whatever they want to do within that context without modifying their
entire system. If they learn that they later want their system-wide
path manipulated, they can do that within the installer or will known
how to do that themselves.

* watch Dave Beazley's PyCon 2014 talk for a good story involving one
of those manufacturer installed Pythons:
https://www.youtube.com/watch?v=RZ4Sn-Y7AP8
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7.7. on Windows

[Brian Curtin]

On Mon, Apr 28, 2014 at 7:04 PM, Steve Dower steve.do...@microsoft.com wrote:
 Mike Miller wrote:
 On 04/29/2014 05:12 AM, Steve Dower wrote:
 This would be an incredibly painful change that would surprise and
 hurt a lot of people.

 Hi, I think incredibly painful is overstating the case a bit. ;) We're 
 talking
 about an installer default, a setting that would still be changeable as it
 always has, that by definition only will affect brand new installs.

 Good point about it only affecting new installs, though that still 
 constitutes a lot of installs.

 Yes, it is possible for a non-admin user to install arbitrary packages
 into a place where an admin user may inadvertently run it, thereby
 providing escalation of privilege. On the other hand, that applies to
 a lot of development tools, especially since most users on Windows
 these days are actually limited administrators - ANYTHING they install
 could run when they elevate a certain process.

 None of Microsoft's Dev tools install to C:\, rather to ProgramFiles. The 
 fact
 that another security issue may exist is not a good justification for 
 creating
 additional.

 The fact that the mitigations are well known by the people who have to worry 
 about them is a good justification for not creating a compatibility issue. 
 It's easy for IT admins to install Python in a way that the files are 
 read-only, the .pyc and .pyo files are already there, and user site packages 
 will be used by default (I think that last one is easy?). The good IT admins 
 even know that they need to do this - perhaps we can help educate the bad 
 admins? (FWIW, if you have admin privileges on your own machine, YOU are the 
 IT admin. Are you a good one or a bad one?)

 On the other hand, Python from python.org is a tool that should only
 be installed by those who are prepared to manage it. On Windows it is
 easy enough to have a second, secured copy for your admin scripts and
 an unsecured copy for non-admin tasks.

 This sounds like the perspective of someone highly technical, forgetting that
 new users will be installing python as well and vastly outnumber us. Normal
 people need help to avoid security issues.

 One place where mitigations are added are the distributions (Canopy, 
 Anaconda, etc.). These packages redistribute Python and install to different 
 locations with different permissions (I'm not promising that they all do it 
 properly, but they have the opportunity to do so). The reference 
 implementation of CPython is typically not the best option for normal 
 people, who are much better served by one of these bundles.

 Microsoft's guidelines on where to install software are clear, and don't make
 exceptions that tools should be installed to the root of the drive to 
 bypass
 file system permissions, for convenience.

 I'm well aware of the guidelines, hence the practicality vs. purity comment. 
 I'm fairly certain that the installation to the root was originally about 
 ease of command-line access rather than bypassing permissions - the 
 permissions probably didn't exist for the first few versions of Python 
 (Python for DOS obviously didn't care... maybe it's always been about 
 backwards compatibility?)

 At this point, installing into the root is about not breaking everyone who 
 *knows* that Python installs into the root directory and always has.

 I'm not sure what change you are proposing here... doesn't the
 installer already have an option to add to PATH? I'm sure I keep disabling 
 it.

 No, it does not. Unless it got slipped in when I wasn't looking.

 It should be an option though, I think everyone would agree.

 Thanks Brett for pointing out that it arrived in Python 3. I'm sure it would 
 be an acceptable addition to 2.7.7, though you'd need to get it in before RC 
 and you'd also need to find someone who is keen and able to keep making 2.7 
 installers for Windows. Right now, we don't have anyone who is both.

If it's an acceptable change to the release manager (Benjamin?), and
if there's actually time before the RC (I don't know when it is
planned), I am willing to backport my 3.3 change to get this in the
2.7 installer.

However, I'm not currently setup to make release installers -- I think
I need a signing certificate or something like that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

[Brian Curtin]

On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy tjre...@udel.edu wrote:
 On 3/13/2014 7:34 AM, Stephen J. Turnbull wrote:

 Christian Heimes writes:

But I don't want it to sound like an advert... Suggestions?

 Not to worry.  It *can't* be an advert -- it's all true, and there are
 no irrelevant half-naked glistening bodies.  (Former newts in the pond
 don't count.)

 Seriously, while expect a clean build is not news for Python,


 It is for a Windows repository build. I just rebuilt: 3.3 gives lots of
 warning from multiple files; 3.4 none.


 Accompanied by an open invitation for reports to
 the contrary, that's hardly like a commercial.


 Now that no warnings is a serious goal for 3.4+, I will report them should
 they recur.

If we're at no warnings, and no warnings is a serious goal, warnings
should be errors.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

[Brian Curtin]

On Mon, Mar 10, 2014 at 8:55 AM, Victor Stinner
victor.stin...@gmail.com wrote:
 For example, I propose to release the next major Python version (3.5)
 with the version 4.0 but without removing anything.

People put a lot of weight behind version numbers, often much more
than they should. Jumping to 4.0 would be a PR nightmare and would
ultimately hurt this project as more people decide that switching to
another language will solve their problem better than jumping from 2.x
to 4.0. People already think 2.7 to 3.4 is enough of a burden.

Please do not do this.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Introduced with the Community and Looking forward to Contribute to the Project as part of Gsoc 2014

[Brian Curtin]

On Sun, Feb 9, 2014 at 10:34 AM, Nitika nitikaagarwa...@gmail.com wrote:
 I had got myself aware of the source to some extent and had forked on my 
 github account.

The python source isn't forked in your github. A Github mirror of the
Mercurial repository (hg.python.org) is available at
https://github.com/python/cpython
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: [python-tulip] Need help to finish asyncio documentation

[Brian Curtin]

On Sat, Feb 8, 2014 at 6:00 PM, MRAB pyt...@mrabarnett.plus.com wrote:
 On 2014-02-08 23:32, Guido van Rossum wrote:

 We could really use more help reviewing and finishing asyncio's docs!

 Some spelling mistakes:

 http://docs.python.org/dev/library/asyncio.html
 mimicks

 http://docs.python.org/dev/library/asyncio-task.html
 returing
 nummber

 http://docs.python.org/dev/library/asyncio-protocol.html
 correspondong

 http://docs.python.org/dev/library/asyncio-stream.html
 Sublclass

 http://docs.python.org/dev/library/asyncio-subprocess.html
 subproces
 signale

Fixed: http://hg.python.org/cpython/rev/3cfaeb788e00 - thanks!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brian Curtin]

On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 24/01/2014 17:19, Ram Rachum wrote:

 Hmm, on one hand I understand the need for the separation between
 python-dev and python-list, but on the other hand I don't think
 python-list is a good place to discuss Python, the language.

 I now looked at the 17 most recent python-list threads. Out of them:

   - 58% are about third-party packages.
   - 17% are off-topic (not even programming related)
   - 11% are 2-vs-3 discussions
   - 5% are job offers.
   - 5% (which is just one thread out of 17) is about Python the language.



 I'm extremely impressed by your knowledge of statistics, it must have taken
 you many man years of effort to analyse all 17 threads in such detail.


 So can you understand why someone would be reluctant to start a
 discussion in python-list about Python the language there? Especially if
 this is the same place where beginners might ask newbies questions about
 Python? (So not only are actual Python questions just 5% of the content,
 non-newbie questions are just a subset of that 5%.)

 it's full of people asking about third-party Python packages, or asking
 newbie questions.


 How terrible, fancy having the audacity to ask about third party packages or
 newbie questions on the *MAIN* Python mailing list.  There's yet another
 reason to bring back the death penalty in the UK.

Please adjust the tone of your messages if you are going to use this
mailing list.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brian Curtin]

On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 24/01/2014 22:44, Brian Curtin wrote:

 On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence breamore...@yahoo.co.uk
 wrote:

 On 24/01/2014 17:19, Ram Rachum wrote:


 Hmm, on one hand I understand the need for the separation between
 python-dev and python-list, but on the other hand I don't think
 python-list is a good place to discuss Python, the language.

 I now looked at the 17 most recent python-list threads. Out of them:

- 58% are about third-party packages.
- 17% are off-topic (not even programming related)
- 11% are 2-vs-3 discussions
- 5% are job offers.
- 5% (which is just one thread out of 17) is about Python the
 language.



 I'm extremely impressed by your knowledge of statistics, it must have
 taken
 you many man years of effort to analyse all 17 threads in such detail.


 So can you understand why someone would be reluctant to start a
 discussion in python-list about Python the language there? Especially if
 this is the same place where beginners might ask newbies questions about
 Python? (So not only are actual Python questions just 5% of the content,
 non-newbie questions are just a subset of that 5%.)

 it's full of people asking about third-party Python packages, or asking
 newbie questions.


 How terrible, fancy having the audacity to ask about third party packages
 or
 newbie questions on the *MAIN* Python mailing list.  There's yet another
 reason to bring back the death penalty in the UK.


 Please adjust the tone of your messages if you are going to use this
 mailing list.


 I'm sorry but I do not understand, please explain what is wrong with an
 extremely heavy dose of sarcasm.

There's a real discussion going on and you're just responding to throw
around sarcasm. People aren't going to come to this list if you're
just going to give them snarky replies. It's not helping.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

[Brian Curtin]

On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
gokoproj...@gmail.com wrote:
 On 1/22/14 8:16 AM, Nick Coghlan wrote:

 Which is exactly the way most non-web-specialists working inside the
 comfort of corporate and academic firewalls will react to a change that
 breaks their access to internal applications, where self-signed certs and
 improperly configured internal CAs are endemic (of course, that's assuming
 they're using HTTPS at all, which I admit is an optimistic assumption).

 The number of people who are using 3.4+ in these environments is probably
 very very low to be honest. I don't have a number to prove, but in that
 environment people are more likely to still be using 2.6+. I think a
 deprecation in 2.7+ would be nice, but forward we should just enable it by
 default.

 When requests changed property calls (e.g. requests.json) to callable
 instead of an attribute(from requests.json to requests.json()), I was
 shocked. I had to figure out by Googling it. I found out from github
 issue

 I think a hard fail is somehow necessary.

 Also, a lot of people overlook at deprecation warnings. They either don't
 care or don't see it. I see a lot of deprecation warnings in the older
 applications I write, but I can careless until it breaks. So as we moving
 forward, we can break it. For those stuck behind, deprecation is the right
 approach.

They're disabled by default, so a lot of people simply don't know they
exist because they also don't read the documentation.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.x vs 3.x survey results

[Brian Curtin]

On Sun, Jan 5, 2014 at 3:08 AM, Lennart Regebro rege...@gmail.com wrote:
 On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong
 gokoproj...@gmail.com wrote:
 I think it helps Luca and many others (including myself) if there is a
 reference of the difference between 2.7 and Python 3.3+.

 Not specifically for 2.7 and 3.3, no. This is a fairly complete list:

 http://python3porting.com/differences.html

 There are PEPs and books, but is there any such long list of references?

 If not, should we start investing in one? I know the basic one such as
 xrange and range, items vs iteritems, izip vs zip that sort of uniform
 syntax/library inclusion difference.

 If there is such reference available?

 I'm honestly despairing that people still don't know that there is a
 free book on the topic. I have no idea how to increase the knowledge
 on this point.

I think we collectively need better SEO, or something like that.
Python 3 would be in a better place if people actually knew the
current state of things, versus asking people on Hacker News.

I constantly see people claiming they are stuck on Python 2 until
NumPy, SciPy, and matplotlib are ported. Many of these people state
they would love to use Python 3 if it weren't for those projects.
However, those projects have all been ported -- and the first two have
been available for several years now.

The same goes for differences documents. I think 15 of us have written
such documents, most of which cross-reference the other documents.
Somehow very few people seem to know about any of them.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running the unit test as root/administrator

[Brian Curtin]

On Tue, Dec 3, 2013 at 8:14 PM, Ryan Gonzalez rym...@gmail.com wrote:

 Just don't run it on Windows...


Not helpful.

I'm in meetings/training/traveling all week, but I'll get another Windows
build slave up within the next few days. I used to have a spare desktop box
that ran a build slave as admin so it would exercise the os.symlink code,
but I moved, then the box died, etc.
___
Python-Dev mailing list
Python-Dev@python.org
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

[Brian Curtin]

On Wed, Nov 20, 2013 at 5:36 PM, Christian Tismer tis...@stackless.com 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 Visual
 Studio 2010 or better.  This is considered an improvement and not a bug
 fix,
 where I disagree.

 I'm not so sure about that.  Python 2.7 can still get patches to help
 extend
 its useful life by allowing it to be built with newer compiler suites.  I
 believe this has already been done for various Linux compilers.  I see no
 non-technical reason why Python 2.7 can't be taught how to build with VS
 2010
 or newer.  Details are subject to RM approval, IMHO.

 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
 ;-) .

 This compiler change is currently the only deviation from CPython 2.7,
 but we may support a few easy back-ports on customer demand. We don'd add
 any random stuff, of course.

 I think you're just going to confuse everyone if you call it Stackless
 Python
 2.8 and it will do more harm than good.


 Barry, that's a good thing! This way I have a chance to get my build in at
 all.
 And that's the question, after re-thinking:

 Where can I check my change in, if it is going to be accepted as a valid
 2.7 bug fix (concerning VS 2008 as a bug, that is is)?

If you do end up checking something in, I think it should be a
backport of the 3.x VS2010 work, rather than contributing your own
patch starting from 2.7. Otherwise any differences in the way you did
things could cause pain while merging changes between the branches.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NTPath or WindowsPath?

[Brian Curtin]

On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka storch...@gmail.com wrote:
 16.11.13 21:15, Antoine Pitrou написав(ла):

 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?


 What about nturl2path, os.name, sysconfig.get_scheme_names()?

What about them?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run

[Brian Curtin]

On Sun, Nov 3, 2013 at 8:54 PM, Terry Reedy tjre...@udel.edu wrote:
 On 11/3/2013 11:48 PM, terry.reedy wrote:

 http://hg.python.org/cpython/rev/cced7981ec4d
 changeset:   86908:cced7981ec4d
 branch:  2.7
 user:Terry Jan Reedy tjre...@udel.edu
 date:Sun Nov 03 23:37:54 2013 -0500
 summary:
Issue #X: Fix test_idle so that idlelib test cases are actually run
 under test.regrtest on 2.7.


 This message is the one included with the patch by Ned Daily. Because a
 message *was* included (not normal), hg import committed the patch
 immediately, without giving me a chance to edit the patch or message. As far
 as I know, there is no way I could have edited the message after the commit.
 If there was, let me know.

Besides what Zach mentions, most of the time you probably want to hg
import --no-commit patch, run it, test it, then commit it with
whatever message you want.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for marking limited API elements in C API docs

[Brian Curtin]

On Sat, Oct 12, 2013 at 3:17 PM, Serhiy Storchaka storch...@gmail.com wrote:
 12.10.13 22:56, Antoine Pitrou написав(ла):

 On Sat, 12 Oct 2013 21:19:16 +0200
 Georg Brandl g.bra...@gmx.net wrote:

 Am 12.10.2013 20:20, schrieb Serhiy Storchaka:

 12.10.13 21:04, Georg Brandl написав(ла):

 in light of the recent thread about PEPs not forming part of the docs,
 I've just pushed a change that allows to document C API elements
 not part of the limited API as such.  It is done like this:

 ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
  :notlimited:

 I have not yet begun adding these to the documents; if someone wants to
 help with this I am glad for volunteers.


 Why this is needed? The limited API is unstable and only developers of
 CPython can use it (but they can look in headers).


 Well, I may be reading PEP 384 wrongly, but the point is exactly to have
 a
 *stable* API for *non-core* developers to rely upon, so that they can
 build
 extensions that don't need to be recompiled for every version of Python.


 This is true.

 However, I find the proposed markup not very enlightening :-)
 I would prefer if limited APIs where marked with a :stableabi: tag.

 (limited API is really a bad synonym for stable ABI IMO)


 Why not limited private API should be documented at all besides sources?

Code is not documentation.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] when to fix cross-version bugs?

[Brian Curtin]

On Fri, Sep 6, 2013 at 9:51 AM, Ethan Furman et...@stoneleaf.us wrote:
 I recently committed a fix for unicodeobject.c so that the %d, %i, and %u
 format specifiers always output values (otherwise, in subclasses, the str()
 was used instead).

 Should this be fixed in 3.3 as well?

 What guidelines determine when a bug is fixed in previous versions?

If it's a bug in that version and the version is accepting bug fixes,
i.e., not in security mode, go for it. This includes crossing the 2/3
boundary if applicable.
___
Python-Dev mailing list
Python-Dev@python.org
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 8 modernisation

[Brian Curtin]

On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy tjre...@udel.edu wrote:
 On 8/1/2013 11:03 AM, Alexander Shorin wrote:

 ...and, if so, why lambda's?(: Without backward compatibility point I
 see that they are getting unofficially deprecated and their usage is
 dishonoured.


 Please stop both the top-posting and the FUD.

Top posting doesn't matter.

The end.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

[Brian Curtin]

On Thu, Aug 1, 2013 at 3:44 PM, Brian Curtin br...@python.org wrote:
 On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy tjre...@udel.edu wrote:
 On 8/1/2013 11:03 AM, Alexander Shorin wrote:

 ...and, if so, why lambda's?(: Without backward compatibility point I
 see that they are getting unofficially deprecated and their usage is
 dishonoured.


 Please stop both the top-posting and the FUD.

 Top posting doesn't matter.

 The end.

Actually, quick expansion on this before moving along: if you're going
to call someone out for top posting, you can't ignore the many high
profile people who do it every time and single out the newcomer.
That's why I said something.

Sorry for the OT.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com