Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7

[Skip Montanaro]

I can't see any reason to make a backwards-incompatible change to
Python 2 to only support Unicode. You're bound to break somebody's
setup. Wouldn't it be better to fix bugs as Serhiy has done?

Skip
___
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] Fix Unicode-disabled build of Python 2.7

[Skip Montanaro]

On Tue, Jun 24, 2014 at 6:15 PM, Nick Coghlan  wrote:
> Aye, in this case, I'm in the "officially deprecate the feature" camp.

Definitely preferable to the suggestion to remove the configure flag.

Skip
___
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

[Skip Montanaro]

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

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

Skip
___
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

[Skip Montanaro]

On Mon, Jul 14, 2014 at 10:53 AM, Brian Curtin  wrote:
>> > Is there some online documentation with guidelines on how to contribute?
>>
>> http://lmgtfy.com/?q=contribute+to+python
>
>
> This response is unacceptable.

Tim and I already discussed this offline. I admitted to being in a bit
of a snarky mood today, and he seems to have accepted my post in good
natured fashion. I should have at least added a smiley to my post. I
will refrain from attempts at unadorned levity in the future.

As penance, Tim or Brian, if you are are in or near Chicago, look me
up. I'd be happy to buy y'all a beer.

Skip
___
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 Job Board

[Skip Montanaro]

On Mon, Jul 14, 2014 at 11:59 AM, Brett Cannon  wrote:
> This is the wrong place to ask about this. It falls under the purview of the
> web site who you can email at webmaster@ or submit an issue at
> https://github.com/python/pythondotorg . But I know from PSF status reports
> that it's being actively rewritten and fixed to make it manageable for more
> than one person to run easily.

Agree with that. I originally skipped this post because I'm pretty
sure MAL who is heavily involved with the rewrite effort) still hangs
out here. I will modify Brett's admonition a bit though. A better
place to comment about the job board (and perhaps volunteer to help
with the current effort) is j...@python.org.

Skip
___
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] Reviving restricted mode?

[Skip Montanaro]

On Mon, Aug 11, 2014 at 12:42 PM, matsjoyce  wrote:
> There maybe some holes in my approach, but I can't find them.

There's the rub. Given time, I suspect someone will discover a hole or two.

Skip
___
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] pip enhancement

[Skip Montanaro]

On Wed, Aug 27, 2014 at 7:58 AM, Neal Becker  wrote:
> On systems where os-level packaging is available (e.g., fedora linux), it is 
> not
> unusual to want a newer python package installed than available from the 
> vendor.
> pip install --user can be used for this.

How? I have exactly this problem with nose. We actually get it bundled
(currently at ancient 1.1.2, trying to get to 1.3.4) with a bunch of
other open source software from an outside packaging company, and even
though I add the --user flag, it still complains that a version is
already installed. When I add the --upgrade flag it tries to uninstall
the global version.

Skip
___
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] pip enhancement

[Skip Montanaro]

On Wed, Aug 27, 2014 at 8:24 AM, Paul Moore  wrote:
> Do you mean something like "pip list --outdated"?

I was unaware of that command, as we were stuck at pip 1.2.1. I just
updated pip manually to 1.5.6. That is a very helpful command. It
would be even better if it understood --user so it could restrict it's
view to user-installed stuff.

Also, given that packages can be found in multiple places on a system, for me:

* the OpenSuSE system packages
* TWW-provided system-wide packages
* our own system-wide packages in /opt/local
* my private stuff in ~/.local

it would be great if there was a way for it to tell me where on my
system it found outdated package X. The --verbose flag tells me all
sorts of other stuff I'm not really interested in, but not the
installed location of the outdated package.

Skip
___
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] pip enhancement

[Skip Montanaro]

On Wed, Aug 27, 2014 at 9:04 AM, Ian Cordasco
 wrote:
> Also, isn't this discussion better suited for Distutils-SIG?

I started up a thread there. I'd post an archive link, but it hasn't
yet turned up in the distutils-sig archive.

Skip
___
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] https:bugs.python.org -- Untrusted Connection (Firefox)

[Skip Montanaro]

I got the same in Chrome on my Mac.

Skip
On Sep 1, 2014 8:00 PM, "John Wong"  wrote:

> As of today I still am getting untrusted cert thought I would re-ping to
> see if there is an ETA.
>
> On Thu, Aug 21, 2014 at 10:32 PM, Terry Reedy  wrote:
>
>> On 8/21/2014 7:25 PM, Nick Coghlan wrote:
>>
>>>
>>> On 22 Aug 2014 04:45, "Benjamin Peterson" >> > wrote:
>>>  >
>>>  > Perhaps some board members could comment, but I hope the PSF could
>>> just
>>>  > pay a few hundred a year for a proper certificate.
>>>
>>> That's exactly what we're doing - MAL reminded me we reached the same
>>> conclusion last time this came up, we'll just track it better this time
>>> to make sure it doesn't slip through the cracks again.
>>>
>>> (And yes, switching to forced HTTPS once this is addressed would also be
>>> a good idea - we'll add it to the list)
>>>
>>
>> I just switched from a 'low variety' short password of the sort almost
>> crackable with brute force (today, though not several years ago) to a
>> higher variety longer password. People with admin privileges on the tracker
>> might be reminded to recheck.  What was adequate 10 years ago is not so now.
>>
>> --
>> Terry Jan Reedy
>>
>>
>> ___
>> 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/gokoproject%40gmail.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/skip%40pobox.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] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation

[Skip Montanaro]

On Sat, Sep 6, 2014 at 7:27 AM, Antoine Pitrou  wrote:
> Why not advocate --user instead? It is simpler than messing around with 
> virtual
> environments and will suffice for most use cases.

I agree, however, --user needs to be more fully integrated into pip's
behavior. For example, if I execute

pip install --user SomePackage

today, when SomePackage is installed someplace outside ~/.local, pip
complains that SomePackage is already installed. If I then execute

pip install --user --upgrade SomePackage

it tries to remove the outdated more global version of SomePackage.

Skip
___
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] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation

[Skip Montanaro]

> If I then execute
>
> pip install --user --upgrade SomePackage
>
> it tries to remove the outdated more global version of SomePackage.

BTW, I believe this is a known issue:

https://github.com/pypa/pip/issues/1851
https://github.com/pypa/pip/issues/1122

Based on the comment in the second issue, it doesn't appear this will
be resolved until 1.7 at the earliest.

Skip
___
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] Fixing 2.7.x

[Skip Montanaro]

On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily  wrote:
> So 2.7.x is not "security only" and wouldn't reach that stage until 2020
> under current policy.

Apparently no other 2.x release qualifies as "security only" at this
point? I would have expected at least 2.6 to fall into that category.

Skip
___
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] performance delta with .py presence v.s. only pyc on python 2.7.x?

[Skip Montanaro]

On Tue, Oct 7, 2014 at 12:46 PM, John Smith  wrote:
> pyc-only install sees mediocre performance. (pyc's are built using
> compileall.py, then source .py's removed before packaging)

(Warning: it's been probably a decade since I looked at any of this
stuff, so treat this response as mere conjecture.)

I'd take a look at startup time and things like stat(2) calls in the
presence or absence of .py files. It's possible that it tries all
other possible file extensions before considering .pyc. If you have a
long sys.path, it would then run through all the other file extension
possibilities before trying the .pyc. OTOH, if the .py is present, it
might be found early in the search, then as an optimization, look for
a .pyc file it can use rather than compiling the .py file. How long is
sys.path?

Skip
___
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] Dinamically set __call__ method

[Skip Montanaro]

On Tue, Nov 4, 2014 at 10:52 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:

> $ cat testcall.py
> class A:
>

You are using old-style classes in Python 2.7 unless you explicitly inherit
from object. If I vary the class line to be "class A(object):" I get the
same behavior with 2.7 as you see with 3.4. My guess is this causes the
different behavior between versions. You might also find it useful to
"print A.__call__" and "print a.__call__" with different class statements.

Skip
___
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?

[Skip Montanaro]

> git-push(1) is over 650 lines and it's nearly
> impossible to dig out the most important
> bits.

I use git daily at work. I try to use it in the most simple way possible.
My frustration with the man pages got to the point where I basically use
Google to ask my questions, then bookmark the solutions I find (which often
turn out to be on stackoverflow).

Skip
___
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] datetime nanosecond support (ctd?)

[Skip Montanaro]

On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec  wrote:
> ...or keep using "%f" if acceptable...

That might be a problem. While it will probably work most of the time,
there are likely to be situations where the caller assumes it
generates a six-digit string. I did a little poking around. It seems
like "%N" isn't used.

Skip
___
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] datetime nanosecond support (ctd?)

[Skip Montanaro]

On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou  wrote:
> I think strftime / strptime support is a low-priority concern on this
> topic, and can probably be discussed independently of the core
> nanosecond support.

Might be low-priority, but with %f support as a template, supporting
something to specify nanoseconds should be pretty trivial. The hardest
question will be to convince ourselves that we aren't choosing a
format code which some other strftime/strptime implementation is
already using.

In addition, ISTR that one of the use cases was analysis of datetime
data generated by other applications which has nanosecond resolution.
Unless those values are stored as epoch seconds, you're going to need
to parse them. It's not clear to me why you'd give people only half
the solution they need.

Skip
___
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] datetime nanosecond support (ctd?)

[Skip Montanaro]

On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec  wrote:
> Agreed with Antoine, strftime/strptime are somewhat different concerns.
> Doesn't mean thay cannot be fixed at the same time but it's a bit a
> separate.

Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe
on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions
of a second (and %L specifically for milliseconds). Here's the bit from the
Ruby strftime doc:

%L - Millisecond of the second (000..999)
%N - Fractional seconds digits, default is 9 digits (nanosecond)
  %3N  millisecond (3 digits)
  %6N  microsecond (6 digits)
  %9N  nanosecond (9 digits)
  %12N picosecond (12 digits)

There's no obvious reason I can see to reinvent this particular wheel, at
least the %N spoke. The only question might be whether to modify Python's
existing %f format to accept a precision (defaulting to 6), or add %N in a
manner similar (or identical) to Ruby's semantics.

Skip
___
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

[Skip Montanaro]

On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa  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.

Skip
___
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

[Skip Montanaro]

On Tue, Dec 16, 2014 at 3:03 PM, Marko Rauhamaa  wrote:
>
> How about "run 3to2 at installation time?"


In theory, yes, but that's not a fork either.

Skip
___
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] How do I ensure that my code is being executed?

[Skip Montanaro]

On Tue, Jan 20, 2015 at 8:35 AM, Neil Girdhar  wrote:
>
> I get error:
>
> TypeError: init_builtin() takes exactly 1 argument (0 given)
>
> The only source file that can generate that error is 
> Modules/_ctypes/_ctypes.c, but when I make changes to that file such as:
>
> PyErr_Format(PyExc_TypeError,
>  "call takes exactly %d arguments XYZABC (%zd given)",
>  inargs_index, actual_args);
>
> I do not see any difference after make clean and a full rebuild.  How is this 
> possible?  I need to debug the arguments passed.

Neil,

I'm a little bit confused. Why are you modifying the Python
interpreter to see if your code (presumably not part of the Python
interpreter) is being executed? I will take a stab at your question
though, and suggest you aren't actually running the interpreter you
just built.

Can you provide some more context for your question?

One last thing. Are you working on Python itself
(python-dev@python.org is the right place to ask questions) or using
Python to develop an application (python-dev is not the right place,
try python-l...@python.org)?

Skip
___
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] Any grammar experts?

[Skip Montanaro]

On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou  wrote:
> I also think the multiple-starargs function calls are completely
> overboard:
>
>   f(**someargs, **someotherargs)
>
> (I might add I've never felt any need for those)

This makes sense to me, but I wonder how you resolve the case of
overlapping keys.

I will note that pylint complains about any use of *args or **kwds
(calling it "magic"), which seems a bit overboard to me. There's
nothing magic in the current implementation as far as I can see. I
wonder if it makes sense for pylint to allow simple use (basically,
the status quo) to fly by silently, but start to chirp when people use
the facility in all its baroque glory as enabled by the PEP.

Skip
___
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] Any grammar experts?

[Skip Montanaro]

On Mon, Jan 26, 2015 at 12:55 PM, Ethan Furman  wrote:
> So which is it?

Precisely...

S
___
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] Pydoc Replacement for Python's help()?

[Skip Montanaro]

On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton  wrote:
> Unfortunately, as I quickly found out,
> Python's built-in help function requires tkinter, which requires
> tcl/tk.

I'm a little confused. Are you using some sort of freeze system which
is deciding Tkinter is required? I use help() all the time from the
interpreter prompt and never get a GUI. IMO you should be able to
strip out the gui() function (or even just comment out the Tkinter
import).

Skip
___
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] Undefined reference to dlopen (was: Pydoc Replacement for Python's help()?)

[Skip Montanaro]

On Tue, Jan 27, 2015 at 6:31 AM, Cyd Haselton  wrote:
> Additionally it appears as though some modules were not built with the
> correct links to -lc -ldl, even though I added them as dependencies in
> Setup and setup.py, as well as in the appropriate env variables.
> Importing string, tokenize, operator, inspect...and probably others I
> haven't tested...throw the 'undefined reference to dlopen' error.

Is this another topic? If so, please start another thread. People
glancing at subjects
won't recognize that you're now tackling a different problem.

The modules you mention here (as well as pydoc) are all pure Python modules.
I don't think any of them would have directly triggered a dlopen error. Do you
have a traceback?

Skip
___
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] Pydoc Replacement for Python's help()?

[Skip Montanaro]

On Tue, Jan 27, 2015 at 6:46 AM, Cyd Haselton  wrote:
> A quick FYI: The decision to build 2.7.8 (instead of 3.x) on Android
> was made after reading this article:
> https://wiki.python.org/moin/Python2orPython3

What in that document convinced you to port to Python 2 instead of
Python 3? That page is intended for people deciding which version of
the language to use for their work. I would think as someone trying to
port to a new platform your criteria would be different. Also, note
that the above page was last updated in April 2014. Look at the info
for that page:

https://wiki.python.org/moin/Python2orPython3?action=info

and you'll see there was probably nothing of substance added to that
page in over a year.

Right at the very top of that page, I read:

Short version: Python 2.x is legacy, Python 3.x is the present and
future of the language

I would think that would be enough to convince you to use Python 3.x
as your starting point. I say this as someone who, in his day-to-day
work uses Python 2.7 exclusively, doesn't expect his employer to ever
convert to Python 3, and has never done much more with Python 3 than
build it. With all that, if I was going to attempt a port of Python to
a new platform, I would still choose to port Python 3.

Skip
___
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] Tunning binary insertion sort algorithm in Timsort.

[Skip Montanaro]

On Mon, Mar 9, 2015 at 10:53 AM, Steven D'Aprano  wrote:
> On Sun, Mar 08, 2015 at 10:57:30PM -0700, Ryan Smith-Roberts wrote:
>> I suspect that you will find the Python community extremely conservative
>> about any changes to its sorting algorithm, given that it took thirteen
>> years and some really impressive automated verification software to find
>> this bug:
>
> On the other hand, the only person who really needs to be convinced is
> Tim Peters. It's really not up to the Python community.

Also, there's no sense discouraging people who have ideas to
contribute. So what if nha pham's contribution isn't accepted? You
never know when the next Tim Peters, Georg Brandl, Mark Dickinson, or
Brett Cannon will turn up. (That list is practically endless. Don't
feel slighted if I failed to mention you.) With seven billion people
out there, a few of them are bound to be pretty smart.

Skip
___
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] typeshed for 3rd party packages

[Skip Montanaro]

On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum  wrote:

> For Requests, it looks like it may be better not to have stubs at all.


Can you expand on this? Why would Requests be any different than any other
module/package?

As for versioning, I think stub files would absolutely have to declare the
appropriate version(s) to which they apply (probably via embedded
directives), so type checkers can ignore them when necessary. That also
means that type checkers must be able to figure out the version of the
package used by the application being analyzed.

Not sure I'm being too clear, so I will provide an example. I have app
"myapp" which imports module "yourmod" v 1.2.7. The yourmod author hasn't
yet provided type annotations, so someone else contributed a stub to the
typeshed. Time passes and a new version of "yourmod" comes out, v 2.0.0.
(Semantic versioning tells us the API has changed in an incompatible way
because of the major version bump.) I decide I need some of its new
features and update "myapp". There is no new stub file in the typeshed yet.
When I run my fancy type checker (someone suggested I will shortly have 50
to choose from!), it needs to recognize that the stub no longer matches the
version of "yourmod" I am using, and must ignore it.

Does that suggest the typeshed needs some sort of structure which allows
all versions of stubs for the same package to be gathered together?

My apologies if I'm following along way behind the curve.

Skip
___
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 492: What is the real goal?

[Skip Montanaro]

On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov 
wrote:

> Anyways, I'd be OK to start using a new term, if "coroutine" is
> confusing.
>

According to Wikipedia , term
"coroutine" was first coined in 1958, so several generations of computer
science graduates will be familiar with the textbook definition. If your
use of "coroutine" matches the textbook definition of the term, I think you
should continue to use it instead of inventing new names which will just
confuse people new to Python.

Skip
___
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] Mac popups running make test

[Skip Montanaro]

I haven't run the test suite in awhile. I am in the midst of running it on
my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup:


​
I assume this is testing some server listening on localhost. Is this a new
thing, either with the Python test suite or with Mac OS X? (I'd normally be
hidden behind a NAT firewall, but at the moment I am on a miserable public
connection in a Peet's Coffee, so it takes on slightly more importance...)

I've also seen the Crash Reporter pop up many times, but as far as I could
tell, in all cases the test suite output told me it was expected. Perhaps
tests which listen for network connections should also mention that, at
least on Macs?

Thx,

Skip
___
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] Mac popups running make test

[Skip Montanaro]

> Twice now, I've gotten this popup: ...

Let me improve my request, as it seems there is some confusion about
what I want. I'm specifically not asking that the popups not be
displayed. I don't mind dismissing them. When they appear, I would,
however, like to glance over at the stream of messages emitted by the
test runner and see a message about it being expected. It seems that
the tests which can trigger the crash reporter do this.

If I get a chance, I will look into where the crash reporter messages
are displayed. Something similar for the network tickling tests should
also be possible.

Skip
___
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] Fwd: Python programming language vulnerabilities

[Skip Montanaro]

This popped up on python-list. It actually seems to me like it might be
interesting to the core developers. Apologies if I've missed my guess.

Skip

-- Forwarded message --
From: Stephen Michell 
Date: Fri, Sep 8, 2017 at 12:34 PM
Subject: Python programming language vulnerabilities
To: python-l...@python.org


I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We
publish an international technical report, ISO IEC TR 24772 Guide to
avoiding programming language vulnerabilities through language selection
use. Annex D in this document addresses vulnerabilities in Python. This
document is freely available from ISO and IEC.

We are updating this technical report, adding a few vulnerabilities and
updating language applicability as programming languages evolve. We are
also subdividing the document by making the language-specific annexes each
their own technical report. For the Python Part, the major portions are
written, but we have about 6 potential vulnerabilities left to complete.

We need help in finishing the Python TR. We are looking for a few Python
experts that have experience in implementing Python language systems, or
experts in implementing significant systems in Python (for technical level,
persons that provide technical supervision to implementers, or that write
and maintain organizational Python coding standards.

If you are interested in helping, please reply to this posting.

Thank you
Stephen Michell
Convenor, ISO/IEC/JTC 1/SC 22/WG 23 Programming Language Vulnerabilities
--
https://mail.python.org/mailman/listinfo/python-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] A reminder for PEP owners

[Skip Montanaro]

> But someone has to
> review and accept all those PEPs, and I can't do it all by myself.

An alternate definition for BDFL is "Benevolent Delegator For Life." :-)

Skip
___
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 aren't decorators just expressions?

[Skip Montanaro]

> Indeed, I can’t remember a single time where I’ve needed that, let alone
actually realized the restriction existed.

Likewise. I suspect the use of a function sort of just fell out from the
pre-decorator usage. Things like staticmethod()
 and
classmethod() 
were
used well before decorators were available. (According to the linked 2.7
doc references, both were introduced in 2.2, with decorator tweaks coming
along in 2.4.) In fact, those two functions might have been the most
significant driving force in the development of decorators, which, I
believe, were always just thought if as nothing more than syntactic sugar
for existing common use cases.

Skip
___
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] Partial support of a platform

[Skip Montanaro]

> The PEP 11 has a nice description to get a *full* support of a new platform:
> https://www.python.org/dev/peps/pep-0011/

PEP 11 defines the endpoint, full support, and several requirements to
call a platform fully supported. It would be nice if a process was
defined for getting from "no support" to "full support." I think that
to be as supportive as possible (no pun intended), it would make sense
to grant people check-in privileges to a branch (if that's possible or
desirable), or, if not, list forks which are intended to add support
for various platforms which are moving toward full support. I don't
know if PEP 11 is the right place to track such activity, relatively
few updates should be required. I doubt it will be an onerous burden.
Something like:

* ButterflyOS - Victor Stinner (victor.stin...@gmail.com) is working
to add CPython support for this platform on this Git branch:
https://github.com/python/Butterfly
* MothOS - Skip Montanaro (skip.montan...@gmail.com) is working to add
CPython support for this platform on this Git branch:
https://github.com/smontanaro/Moth

Interested parties would be directed to contact the pilots of those
branches if they wanted to contribute.

Skip
___
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] iso8601 parsing

[Skip Montanaro]

> I think the latest version can now strptime offsets of the form ±HH:MM with
> %z, so there's no longer anything blocking you from parsing from all
> isoformat() outputs with strptime, provided you know which one you need.

Or just punt and install arrow:

>>> import arrow
>>> arrow.get('2017-10-20T08:20:08.986166+00:00')

>>> arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip
___
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] iso8601 parsing

[Skip Montanaro]

It's got its own little parsing language, different than the usual
strftime/strptime format scheme, more like what you might see in Excel. I
never worried too much about the speed of dateutil.parser.parse() unless I
was calling it in an inner loop, but arrow.get() seems to be a fair bit
faster than dateutil.parser.parse. This makes sense, as the latter tries to
figure out what you've given it (you never give it a format string), while
in the absence of a format string, arrow.get assumes you have an ISO-8601
date/time, with only a few small variations allowed.

Skip

On Tue, Nov 28, 2017 at 2:52 PM, Paul G  wrote:

> IIRC, arrow usually calls dateutil to parse dates anyway, and there are
> many other, lighter dependencies that will parse an ISO 8601 date quickly
> into a datetime.datetime object.
>
> I still think it's reasonable for the .isoformat() operation to have an
> inverse operation in the standard library.
>
> On November 28, 2017 3:45:41 PM EST, Skip Montanaro <
> skip.montan...@gmail.com> wrote:
>>
>>  I think the latest version can now strptime offsets of the form ±HH:MM with
>>>  %z, so there's no longer anything blocking you from parsing from all
>>>  isoformat() outputs with strptime, provided you know which one you need.
>>>
>>
>> Or just punt and install arrow:
>>
>>  import arrow
>>>>>  arrow.get('2017-10-20T08:20:08.986166+00:00')
>>>>>
>>>> 
>>
>>>  arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>>>>>
>>>> datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))
>>
>> Skip
>>
>>
___
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 of the Android platform

[Skip Montanaro]

I'm not familiar with software development on/for Android, but
wouldn't official support also involve suitable package creation or
does that just fall out for free from the build-for-emulator PR?

Skip
___
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] [ssl] The weird case of IDNA

[Skip Montanaro]

Guido wrote:

This being a security issue I think it's okay to break 3.6. might even
backport to 3.5 if it's easy?


Is it also a security issue with 2.x? If so, should a fix to 2.7 be
contemplated?

Skip
___
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] gdb support could use some love

[Skip Montanaro]

> There are a bunch of open issues regarding gdb support including one with a 
> PR in need of review for 3.6+.

I rejected one (which assumed everyone now uses a python-aware gdb),
commented on another (ceval.c-related name changes in several
commands), and created a PR for third (documentation for the
user-defined commands). Unfortunately, it's been so long since I
contributed, I don't quite understand the ins and outs of the workflow
anymore. In particular, I could find no way to add the "skip news"
label. I'm afraid someone might have to intervene here:

https://github.com/python/cpython/pull/6384

Skip
___
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] gdb support could use some love

[Skip Montanaro]

> You created the PR from your local python repository master branch.  I have
> done this, with negative consequences.  I believe you will find life with
> git easier if you never edit your master branch, or at least, never make
> local commits to it, and only commit to and create PRs from special-purpose
> patch branches, as described in the devguide.

Thanks. I clearly need to brush up on workflow and etiquette.

Skip
___
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] gdb support could use some love

[Skip Montanaro]

> Modifying GitHub Labels is only available to people with commit privs and, 
> IIRC, Skip asked to drop his commit privs a few years ago (although I'm sure 
> we would all be happy to welcome him back!).

Alas, then I would feel some obligation to be semi-responsive to buggy
things in areas where I have some interest. I'd really rather be out
on my bike. :-)

S
___
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] Can't open standard streams with "a"

[Skip Montanaro]

In Python 2 you can open the standard output and error streams in
append mode, despite the fact that they aren't technically seekable.
This changed somewhere along the way in (I think) io.open. There's an
open bug report about this:

https://bugs.python.org/issue27805

I just stumbled on it porting an application from Py2 to Py3 where my
default logfile is /dev/stderr. I don't ever want to truncate a user's
logfile, so "a" is a nice default, but in case the user doesn't name a
logfile, I have to test, just in case /dev/stderr is the candidate.
This seems error-prone, and must be done in all applications. The Py2
behavior seems less error-prone. I know explicit is better than
implicit, but practicality also beats purity. Also, os.open is fine
with O_APPEND on these streams.

Any chance of this getting into 3.7 or will a fix have to wait for 3.8
at this point? (I'm guessing "no" as I don't see a patch.)

Skip
___
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] Trying to build from source, test-poplib fails

[Skip Montanaro]

It's been a long while since I rebuilt Python from the Git source. I
tried for the first time the other day. Everything passed except
test_poplib and test_asyncio. The former just runs and runs and runs.
Here's the first traceback I encounter when executing ./python
Lib/test/test_poplib.py:

test_stls_context (__main__.TestPOP3Class) ... Exception in thread Thread-16:
Traceback (most recent call last):
  File "/home/skip/src/python/cpython/Lib/threading.py", line 917, in
_bootstrap_inner
self.run()
  File "Lib/test/test_poplib.py", line 227, in run
asyncore.loop(timeout=0.1, count=1)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 207, in loop
poll_fun(timeout, map)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 150, in poll
read(obj)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 87, in read
obj.handle_error()
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 83, in read
obj.handle_read_event()
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 422, in
handle_read_event
self.handle_read()
  File "Lib/test/test_poplib.py", line 194, in handle_read
self._do_tls_handshake()
  File "Lib/test/test_poplib.py", line 174, in _do_tls_handshake
self.socket.do_handshake()
  File "/home/skip/src/python/cpython/Lib/ssl.py", line 1108, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert
certificate unknown (_ssl.c:1049)

I thought perhaps I was missing something, but _ssl built just fine. I
believe I have a recent enough version of libssl (1.0.2g), and I'm on
a pretty vanilla system (up-to-date Ubuntu 17.10). SSL-wise:

% apt search ssl | grep installed | egrep '^lib' | egrep ssl

libgnutls-openssl27/artful,now 3.5.8-6ubuntu3 amd64 [installed]
libio-socket-ssl-perl/artful,artful,now 2.050-1 all [installed]
libnet-smtp-ssl-perl/artful,artful,now 1.04-1 all [installed]
libnet-ssleay-perl/artful,now 1.80-1build1 amd64 [installed]
libssl-dev/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4 amd64
[installed]
libssl-doc/artful-updates,artful-updates,artful-security,artful-security,now
1.0.2g-1ubuntu13.4 all [installed,automatic]
libssl1.0.0/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4
amd64 [installed]

Any clues about what I might be missing from my setup would be appreciated.

Not sure what was wrong with test_asyncio. I ran it in isolation and it passed.

Thx,

Skip
___
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] Trying to build from source, test-poplib fails

[Skip Montanaro]

> Do you have ca-certificates installed?

It seems so:

% apt search ca-certificates | grep installed

ca-certificates/artful,artful,now 20170717 all [installed]
ca-certificates-mono/artful,artful,now 4.6.2.7+dfsg-1ubuntu1 all
[installed,automatic]
liblwp-protocol-https-perl/artful,artful,now 6.07-2 all [installed]

S
___
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 572: Assignment Expressions

[Skip Montanaro]

>
> Just reading this:
>
> https://www.bfilipek.com/2018/04/refactoring-with-c17-stdoptional.html
>
> about C++17, and what did I see? An example with a semicolon in
> parentheses!
>

Isn't that kind of the C++ motto? "Leave no syntactic stone unturned."
Whereas in Python, the syntax motto might better be stated, "We will ship
no syntax before its time." (With apologies to Ernest and Julio Gallo.)

Skip
___
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?

[Skip Montanaro]

I still use it a bit, in simple contexts to be sure, but I do find it
useful. Others think so as well. I think TkAgg is probably the most
commonly used backend in Matplotlib. I wrote a single Matplotlib-using
program which plots columns from CSV files. I use it almost daily with no
problems. Again, I use the TkAgg backend by default.

So, does it have problems? Almost certainly. It seems you've encountered
some. If you want to see something change though, just screaming at the
developers is almost certainly the least productive thing you could do.

Here are some things you *could* do:

* submit some bug reports
* review patches related to the problems, assuming there are some
* write some patches for the documentation adding warnings about sketchy
bits

Skip
___
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?

[Skip Montanaro]

One other small bit... There is some precedent for retaining modules where
the underlying library was known to be buggy. The dearly departed bsddb
module exposed libdb 1.85 (as I recall) which had an unfixable bug. Still,
bsddb supported that broken version of the library for quite awhile before
itself being deprecated, then removed, from the stdlib. I believe it was
the sole persistent key/value store for most of the early years.

So, bugs or not (& fixable or not) it's not like we haven't encountered
this kind of case before.

Skip
___
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] (Looking for) A Retrospective on the Move to Python 3

[Skip Montanaro]

> I have found 2to3 conversion to be remarkably easy and painless.

> And the whole Unicode thing is much easier.

The intersection of bytes, str and unicode has been the only pain point for
me. Everything else I've encountered has been pretty trivial.

Skip
___
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] bpo-33522: Enable CI builds on Visual Studio Team Services (GH-6865) (GH-6925)

[Skip Montanaro]

On Thu, May 17, 2018 at 11:32 PM Gregory P. Smith  wrote:

> Why did this commit modify .py files, unittests, and test.support?

> That is inappropriate for something claiming to merely enable a CI
platform.

I think there is probably an argument to be made that some of the changes
will be improvements, but I think such changes belong in separate PRs. Even
if that means you have to postpone the core bits of this change until they
are merged.

Skip
___
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] "make test" routinely fails to terminate

[Skip Montanaro]

On the 3.7 branch, "make test" routinely fails to terminate. (Pretty
vanilla Ubuntu 17.10 running on a Dell Laptop. Nothing esoteric at all)
Lately, it's been one of the multiprocessing tests. After a long while
(~2000 seconds), I kill it, then it complains many times about lack of a
valid_signals attribute in the signal module:

==
ERROR: test_remove_signal_handler_error2
(test.test_asyncio.test_unix_events.SelectorEventLoopSignalTests)
--
Traceback (most recent call last):
   File "/home/skip/src/python/cpython/Lib/unittest/mock.py", line 1191, in
patched
 return func(*args, **keywargs)
   File
"/home/skip/src/python/cpython/Lib/test/test_asyncio/test_unix_events.py",
line 219, in test_remove_signal_handler_error2
 m_signal.valid_signals = signal.valid_signals
AttributeError: module 'signal' has no attribute 'valid_signals'

--
Ran 1967 tests in 36.058s

FAILED (errors=362, skipped=11)
test test_asyncio failed
/home/skip/src/python/cpython/Lib/asyncio/base_events.py:605:
ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False
closed=False debug=False>
   source=self)
Re-running test 'test_signal' in verbose mode

then reruns test_signal in verbose mode.

Earlier today, a run succeeded, so I'm guessing a race condition exists in
the test system. I recall encountering a similar problem a few weeks ago
and discovered this open ticket:

https://bugs.python.org/issue33099

Should I expect this as the normal behavior?

Skip
___
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] My fork lacks a 3.7 branch - can I create it somehow?

[Skip Montanaro]

My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch
was created. I have no remotes/origin/3.7. Is there some way to create it
from remotes/upstream/3.7? I asked on GitHub's help forums. The only
recommendation was to to delete my fork and recreate it. That seemed kind
of drastic, and I will do it if that's really the only way, but this seems
like functionality Git and/or GitHub probably supports.

Thx,

Skip
___
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] "make test" routinely fails to terminate

[Skip Montanaro]

me> On the 3.7 branch, "make test" routinely fails to terminate.
Antoine> Can you try to rebuild Python?  Use "make distclean" if that helps.

Thanks, Antoine. That solved the termination problem. I still have problems
with test_asyncio failing, but I can live with that for now.

If "make distclean" is required, I suspect there is a
missing/incorrect/incomplete Make dependency somewhere. I suppose "make
distclean" is cheap enough that I should do it whenever I switch branches.

Skip
___
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] My fork lacks a 3.7 branch - can I create it somehow?

[Skip Montanaro]

> Create it from upstream? Yep! Try this:

> git checkout -b 3.7 upstream/3.7
> git push -u origin 3.7

Thanks, Chris! Didn't have to chug for too long either, just a few seconds.

S
___
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] My fork lacks a 3.7 branch - can I create it somehow?

[Skip Montanaro]

> You don't really need copies of official branches on your Github fork if
you're not a maintainer for these branches.

I explicitly wanted to run with 3.7 in the run-up to release. On that
branch, the built ./python reports 3.7.0b4+ at startup. Master tells me
3.8.0a0 on startup. Since my local repo is a clone of my fork, it made
sense to me to have a 3.7 branch on my fork which I could switch to. Am I
only nutcase who thinks that might be mildly useful? (Or that if I want to
test an application across multiple versions using tox that it makes sense
to have pre-release visibility of point releases.)

Skip
___
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] "make test" routinely fails to terminate

[Skip Montanaro]

> me> On the 3.7 branch, "make test" routinely fails to terminate.
> Antoine> Can you try to rebuild Python?  Use "make distclean" if that
helps.

> Thanks, Antoine. That solved the termination problem. I still have
problems
> with test_asyncio failing, but I can live with that for now.

Final follow-up. I finally got myself a workable, updateable 3.7 branch in
my fork. It looks like the asyncio issues are alsy resolved on both 3.7 and
master.

Skip
___
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] Python3 compiled listcomp can't see local var - bug or feature?

[Skip Montanaro]

> Is this a bug or a feature?

The bug was me being so excited about the new construct (I pushed in
someone else's work, can't recall who now, maybe Fredrik Lundh?) that
I didn't consider that leaking the loop variable out of the list
comprehension was a bad idea. Think of the Py3 behavior as one of
those "corrections" to things which were "got wrong" in Python 1 or 2.
:-)

Skip
___
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] Python3 compiled listcomp can't see local var - bug or feature?

[Skip Montanaro]

> Skip, I think you have misunderstood the  point I was making.  It was
> not whether the loop variable should leak out of a list comprehension.
> Rather, it was whether a local variable should, so to speak, "leak into"
> a list comprehension.  And the answer is: it depends on whether the code
> is executed normally, or via exec/eval.
>

Got it. Yes, you'll have to pass in locals to exec. (Can't verify, as I'm
on the train, on my phone.) Builtins like range are global to everything,
so no problem there.

Your clarification also make it more of a Python programming question , I
think.

Skip

>
___
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] Computed Goto dispatch for Python 2

[Skip Montanaro]

On Thu, May 28, 2015 at 9:02 AM, Brett Cannon  wrote:
> But you could argue that "Special cases aren't special enough to break the
> rules" and that's what we are proposing here by claiming Python 2.7 is a
> special case and thus we should accept a patch that is not a one-liner
> change to gain some performance in a bugfix release.

One can read anything he wants into the Zen. I could respond with this
retort: "Although practicality beats purity," but I won't. :-)

Skip
___
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] RM for 3.6?

[Skip Montanaro]

On Mon, Jun 1, 2015 at 1:35 PM, Ned Deily  wrote:

> I thought I was volunteering to get a pony.  I was misinformed.


Ned,

Not to worry. I'm sure that by the time 3.6a0 is due, the PSF will be able
to scrape together the funds for a pony, perhaps even one with super powers:



Skip
___
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] Is it a Python bug that the main thread of a process created in a daemon thread is a daemon itself?

[Skip Montanaro]

On Thu, Jun 25, 2015 at 12:23 PM, Elizabeth Shashkova <
elizabeth.shashk...@gmail.com> wrote:

> When I call fork() inside a daemon thread, the main thread in the child
> process has the "daemon" property set to True.


Didn't this (or a similar) topic come up here recently? For reference:

http://bugs.python.org/issue24512

and

https://docs.python.org/3.4/library/multiprocessing.html#contexts-and-start-methods

from which I quote (emphasis mine):

The parent process uses os.fork() to fork the Python interpreter. The child
process, when it begins, is *effectively identical to the parent process*.
All resources of the parent are inherited by the child process. *Note that
safely forking a multithreaded process is problematic*.


So, even if you get past this particular problem, the conventional wisdom
is, "don't do that."

Skip
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Skip Montanaro]

Just thinking out loud here, but could you devote a single buildbot to the
cause? It would only ever try to build from the "crasher" branch. When a
crash is discovered like this one, you can do whatever is necessary to
merge the code and a crasher test case to that branch. It would then turn
red. Might a segfault provide enough output to debug?

Skip
___
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] Where are bugs with the web site reported?

[Skip Montanaro]

It's a known issue -- which I thought was fixed recently. I would have
responded sooner, but I couldn't remember where website bugs are to be
reported and figured someone would chime in with the link. I *don't*
think it's bugs.python.org, though I could be wrong.

Skip
___
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] Profile Guided Optimization active by-default

[Skip Montanaro]

On Tue, Aug 25, 2015 at 11:17 AM, Brett Cannon  wrote:

> With a `make develop` target we also can make sure not only that
> --with-pydebug is used but that the installation target is /tmp so that new
> contributors don't accidentally install a debug build.


You need to be careful there. In my environment, I interface with a lot of
Boost.Python-wrapped code which would be quite impractical to compile with
--with-pydebug. I'd like to be able to throw in all the other development
bells and whistles though, without changing the size of the object header.
Maybe "develop-lite"?

-ly, y'rs,

Skip
___
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] OS X 10.9 Mavericks -> 2.7.6/3.3.3 updates needed

[Skip Montanaro]

Kind of on a tangent (and I suspect I know what the answer to my
question will be), but here at work they have asked people who use
Macs not to upgrade to Mavericks until Apple fixes one or more
networking problems which make it basically unusable, especially when
connecting to our VPN. I realize y'all will be busy trying to fix
these various problems as they relate to Python, but might it not be
better to simply tell people to hold off on the Python installers
until Apple gets their act together? Otherwise, I fear you'll just be
trying to hit a moving target.

Skip
___
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 455: TransformDict

[Skip Montanaro]

> And how does a case-insensitive string compare with a normal
> (case-sensitive) string? This is a can of worms.

I was wondering this myself. I suspect it would depend which string is
on the left hand side of the comparison operator, yes? Can of worms,
indeed.

implicit-insensitve-i-n-ly, y'rs,

Skip
___
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 small patch.

[Skip Montanaro]

> -assert 1 <= month <= 12, month
> +assert 1 <= month <= 12, 'month must be in 1..12'

In addition to Brett's comment, you might as well include the
offending value in your AssertionError message. For example, a value
of 0 probably tells you something different about your underlying bug
than a value of 2013. Just knowing it's out of range isn't really
enough.

Skip
___
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] Sort error in Misc/ACKS

[Skip Montanaro]

> We could always run random.shuffle() on the current list
> so new additions don't look out of place ;)

Wouldn't that bloat the repository with diffs and make merges more difficult?



Skip
___
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] Proposed: The Great Argument Clinic Conversion Derby

[Skip Montanaro]

On Mon, Jan 6, 2014 at 2:17 PM, Antoine Pitrou  wrote:
>> I agree with Serhiy, but that is probably known at this point. :)
>
> I agree with Serhiy and you too. Clinic's current output makes C files
> more tedious to read, and I'm not really willing to participate in the
> "conversion derby" because of that.

My first thought was that this exercise falls into the realm of fixing
things which aren't broken.

Skip
___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Skip Montanaro]

On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw  wrote:
> I think we should be willing to entertain breaking feature freeze for getting
> this in Python 3.4.

Maybe you could revert 3.4 to alpha status and give it a cycle or two
there to get this done before returning to beta status.

Skip
___
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] Start writing inlines rather than macros?

[Skip Montanaro]

I think it's at least worthwhile to investigate the use of
inline/static functions over the current macros. It's been many years
since I looked at them. I doubt they have gotten any easier to read or
edit with all their backslashes.

I do have one question though. Suppose you encounter a compiler that
doesn't understand the inline keyword, so you choose the static
declaration as Kristján suggested. The resulting Python executable
should be functionally correct, but if the optimizer doesn't happen to
inline a given static function you might be stuck with some bad
performance across-the-board (if it never inlines, or doesn't inline
where we really need it to), or only under some circumstances (as a
hypothetical example, inlining in dictobject.c, but not in ceval.c).
Is there a configurable way to tell if a compiler will inline
functions which are declared static, and possibly under what
conditions they might not? It might still be necessary to maintain
macros for those platforms.

Skip
___
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] Start writing inlines rather than macros?

[Skip Montanaro]

On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou  wrote:
> Well, if we must maintain macros, let's maintain them everywhere and
> avoid the burden of two different implementations for the same thing.

Would it be possible to generate the macro versions from the
inline/static versions where necessary, as some sort of pre-compile
step?

S
___
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 466: Proposed policy change for handling network security enhancements

[Skip Montanaro]

On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy  wrote:
> The download page for the final 2.7.z maintenance release could say
> something like "We recommend that you move to the most recent Python 3
> version if at all possible. If you cannot do that and you want to use Python
> to run a server on the public internet, we urge you to instead use the
> latest version of ServerPython 2.7.1s. This series is based on Python 2.7.z
> but has been and will continue to be enhanced with security features
> backported from Python 3."

I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release protocol) that it should be a drop-in
replacement for earlier 2.7 micro releases. On the other hand, calling
it something like "ServerPython" implies that it's not necessary for
network client applications, when, if I read the PEP correctly, it
most certainly would be.

If you create a 2.8 release which is restricted to just the topic
areas of the PEP (that is, no other stuff backported from 3.x, no
requirement to add other non-security bug fixes, etc), the incremented
minor version number tells people that a bit of extra care is required
to upgrade. The lack of change in the code base outside the security
apparatus should make update pretty trivial for most every
non-networked application. If the PEP or something like it is
approved, the work is still going to have to be done, no matter what
you call it. Why not be transparent about it?

Skip
___
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 466: Proposed policy change for handling network security enhancements

[Skip Montanaro]

On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw  wrote:
> I want to stick to our no-Python-2.8 pledge 

I don't understand this dogmatic adherence to a "no 2.8 pledge." Back
when it was made, I don't think the issue of SSL vulnerabilities was
understood (at least not to the current level). Now we're in a pickle.
We need to find some way to release something that brings the SSL (and
related) feature set up-to-date. In this thread and Nick's PEP have
read about a few ways this might be accomplished (I probably missed a
couple):

* separate the security-dependent bits out into a separate
"semi"-stdlib which would be served from PyPI
* continue with 2.7.x but admit that there will be some possible
backward incompatibilities with earlier 2.7 versions in the affected
modules
* change the name somehow and jump to two-digit micro version numbers

It seems to me the PyPI option should be a non-starter, as it's
unlikely that you will get the bulk of the 2.7 installations to update
to that version, and if people do install it, they wind up with
possible backward incompatibilities. The second option goes against
the drop-in history of micro releases. The third seems just like
"weasel words" to avoid saying "2.8." Also, a careful reading of the
Zen of Python suggests these solutions might violate a number of its
aphorisms (explicit is better than implicit, simple is better than
complex, practicality beats purity).

So what's the big deal? Why can't we be pragmatic and call this thing
(whatever it turns out to be) 2.8? Is this pledge and its rationale
written down in a PEP somewhere, so I can study the reasons behind
what appears at this point to be blind adherence? Did someone
administer a blood oath at a recent PyCon?

Pledge-be-damned-ly y'rs,

Skip
___
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 466: Proposed policy change for handling network security enhancements

[Skip Montanaro]

On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan  wrote:
> For example, RHEL7 and derivatives are already locked in to 2.7 until
> 2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
> way to keep those combination of RHEL and the Python 2 standard
> library from holding back the evolution of internet security standards
> is to find a way solve the problem *within* the 2.7 line in such a way
> that I can then make the case for also backporting it to 2.6 in a
> RHEL6 point release.

Thanks for the explanation. I'm still a bit confused though. If there
are backward compatibility issues with the proposed changes (whatever
they turn out to be), are the commercial redistributors still going to
balk at releasing these changes to their customers? From the reading
I've done (this thread and your second iteration of the PEP), it seems
like application developers will have to make some changes to take
advantage of these updated security bits. Is there some path forward
that really makes everything a drop-in improvement, requiring no
change to application code, and breaking nothing that already works?

Skip
___
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] ISO 8601 durations and datetime.timedelta

[Skip Montanaro]

Andrew wrote:

> I meant ISO 8601 syntax for "durations" [1].

That's exactly what I was referring to. Consider this session:

>>> now = datetime.datetime.now()
>>> now
datetime.datetime(2014, 3, 28, 12, 4, 38, 517110)
>>> then = now - datetime.timedelta(days=57, hours=12, minutes=12, seconds=12)
>>> now
datetime.datetime(2014, 3, 28, 12, 4, 38, 517110)
>>> then
datetime.datetime(2014, 1, 29, 23, 52, 26, 517110)

so, the difference is:

>>> now - then
datetime.timedelta(57, 43932)

Given that the timedelta has more than "a month's" worth of days, how
would you describe it using the ISO8601 duration notation without
referencing a specific point in time? Conversely, given your example,
"P3Y6M4DT12H30M5S", how would you convert that into a timedelta
without knowing which exact years and months this duration refers to?
Timedelta objects are very precise beasts, which is almost certainly
why they don't support "years" and "months" args in their
constructors.

This is why I said this deserved a separate topic. Probably on python-ideas.

Skip
___
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] Negative timedelta strings

[Skip Montanaro]

On Fri, Mar 28, 2014 at 11:07 AM, Alexander Belopolsky
 wrote:
>> Is it open to debate or is it now cast in stone?
>
> I think the barrier for changing str() is lower than that for changing
> repr(), but I would be against any changes in this area.  (I may have had a
> different view if ISO 8601 syntax for timedeltas was not so ugly. :-)

I think str() should be left alone. It's clear there is no one best
str representation for timedelta objects. I think it might be
worthwhile to add a method which allows the programmer to format
timedelta objects in whatever way s/he sees fit. That would support
the ISO 8601 syntax (*), and anything else the programmer things is
better than the status quo.

Skip

(*) As an aside (that is, this belongs in a separate thread if you
want to discuss it), in my opinion, attempting to support ISO 8601
formatting is pointless without the presence of an anchor datetime.
Otherwise how would you know how far back "five months" or "seven
years" was? If that's the case, then you might as well add the
timedelta to your anchor datetime and just use datetime.strftime().
___
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] Negative timedelta strings

[Skip Montanaro]

On Wed, Apr 2, 2014 at 7:52 AM, M.-A. Lemburg  wrote:
> >>> print now() + RelativeDateTime(months=+1, day=1)
> 2014-05-01 14:49:05.83

I find this sort date arithmetic unintuitive, though I'm at a loss to
come up with better logic than you have:

>>> d = Date(2014, 2, 28)
>>> d + RelativeDateTime(months=+1)

>>> d = Date(2014, 1, 31)
>>> d + RelativeDateTime(months=+1)


I guess the assumption is that one month is the length in days of the
current month, though, you wind up with situations where shorter
months can be skipped altogether. Is there a way to talk in terms of
"months" but not have short months get skipped?

Thx,

Skip
___
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] Python 4?

[Skip Montanaro]

I saw mention recently of Python 4 and assumed all such references
were either April Fool's jokes or pie-in-the-sky dreams for a new
version of Python which may never arrive.

Then I saw this message to webmaster. I would have guessed he meant
3.4 except he mentions having a Python3 (well, actually, a Phython3)
directory.

WTH is Python 4?

Skip

-- Forwarded message --
From: C. Reese 
Date: Thu, Apr 3, 2014 at 8:03 AM
Subject: Updated phython
To: webmas...@python.org


just updated to Python 4.  (installed to C: drive) ... now i notice
there are separate Python2 & Python3 directories as well.  i am not a
programmer in any sense (just a basic computer user).

1. do i need to have python on my computer at all for basic use?
(word, excel, power point, etc.)'
2. can i safely remove the Python 2 & Phython3 directories? (to save
hard disk space)

thanks
CR
___
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?

[Skip Montanaro]

On Thu, Apr 3, 2014 at 8:59 AM, Brett Cannon  wrote:
>
> Who the heck knows what the person specifically means, although it sounds 
> like he did mean Python 3.4 which would explain why he know has a Python3 
> directory.

Thanks. I'll try and see what he really has. I was worried that an
April Fool's prank went so far as to put a tarted up version of Python
3.x out in the wild where unsuspecting folks would find and install
it.

Skip
___
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] this is what happens if you freeze all the modules required for startup

[Skip Montanaro]

On Mon, Apr 14, 2014 at 4:51 PM, Brett Cannon  wrote:
> Thoughts?

Interesting idea, but YAGNI?

In my work environment (Python 2.7.2, all the heavy lifting done in
C++), startup costs are dominated by dynamic linking of all our C++
libraries and their Boost wrappers:

% time python -c 'import tradelink.snake.v11_2 ; raise SystemExit'

real 0m0.671s
user 0m0.405s
sys 0m0.044s

% time python -c 'raise SystemExit'

real 0m0.022s
user 0m0.011s
sys 0m0.009s

Skip
___
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] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

[Skip Montanaro]

Eric wrote:

> Perhaps not so much "a very real advantage" as "less of a
> distraction".  It's still significantly slower than 2.7.  :)

I'm still confused. I peeked in /usr/bin/hg. The only "system" modules
it imports directly are os and system (maybe I'm using an ancient
version?). After that, it imports its own lazy import module. This
suggests to me that Mercurial's import slowness is mostly in its own
code (I counted 104 Python modules and six shared objects in its
mercurial package, which isn't going to be affected (much?) by
freezing the Python standard modules.

I'm not trying to be difficult here. I thought that way back in the
day a huge amount of work was done to remove needless filesystem
activity, and zip packaging has been around for quite awhile.

As an experiment, I ran hg pull as

/usr/bin/python -v /usr/bin/hg pull

in my cpython repo then looked at the -v output. Summarizing the
output I saw the following:

30 imports (0 dlopens)

Python banner printed

86 imports (18 dlopens)

adding changesets message

5 imports (2 dlopens)

adding manifests message

1 import (0 dlopens)

adding file changes message

7 imports (3 dlopens)

added ... changesets message

4 imports (0 dlopens)

run 'hg update' message

(I missed a "searching" message in there somewhere.)

That's a total of 133 imports, 23 of which were satisfied by loading
an extension module. The imports break down as follows:

51 imports (4 dlopens) from the mercurial package
5 imports from the hgext package
7 imports from the encodings package

Everything else is imported from the top level, and at a glance
appears to be all Python stdlib stuff.  The key period of execution
looks to be between the printing of the Python banner and the printing
of the adding changesets message. I see 46 imports (2 dlopens) from
the mercurial or hgext packages. That leaves 40 stdlib imports, of
which 16 were satisfied by dlopen.

As a final check, I saved all the stdlib import statements from the -v
output (77 statements) to a file and timed its execution:

% time /usr/bin/python ~/tmp/pyimp.py

real0m0.162s
user0m0.034s
sys 0m0.010s

It doesn't take much time to import every stdlib module that Mercurial
needs.  I don't know how much slower all this import machinery is in
3.x (and can't test at work, as we don't have a copy laying about). It
would probably have to be 3x or more slower for it to have much
visible impact on even simple hg commands.  I find it hard to believe
that freezing the stdlib is going to lower the barrier enough for the
Mercurial folks, if, in fact, import slowness is their main reason for
not moving to 3.x.

Skip
___
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] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

[Skip Montanaro]

On Tue, Apr 15, 2014 at 10:40 AM, Chris Angelico  wrote:
> I've no idea whether that's the case or not. All I know is, every time
> I need to work with a Mercurial repo it feels a lot slower than doing
> similar work on a similar size git repo [1], so any improvement (or
> reduction of penalty) will be noticeable.

Based on what I saw, I really don't think that startup slowness is in
imports of Python stdlib modules, which is all Brett was aiming at. I
*can* believe overall import slowness might be a problem, but in that
case, Brett's work isn't going to help the Mercurial folks much.

Skip
___
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] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

[Skip Montanaro]

On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth  wrote:
> I wish it was less
> than 50 milliseconds (0.05 seconds) including running hg, which is the
> common threshold for "instant".

"Instant" for me is "the blink of an eye," which Wikipedia reports as
typically between 100ms and 400ms.
 If you blink, you've missed
Python 2.7 startup on a relatively modern machine.



Skip
___
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] pep8 reasoning

[Skip Montanaro]

On Thu, Apr 24, 2014 at 2:18 AM, Chris Withers  wrote:
> What were the compelling reasons to go from mixedCase to
> underscore_separated? What's considered the best approach for migrating from
> the former to the latter?

I never recall Python "going from" camelCase to separate_words. The
descriptions of best practice you see in the PEP were always that way,
as I recall. If you have a code base that does it some other way, I
would leave it be. The primary hunk of code I work with is full of
Boost.Python-generated bindings for C++ libraries, so leaks C++ naming
style out of all its pores. A lot of the other pure Python code in
this code base was written by people who were mostly C++ programmers,
and didn't know PEP 8 from a hole in the ground. Consequently, the
whole thing is riddled with all sorts of non-pep8-ness. I used to want
to change everything, but just let that sleeping dog lie. I have
better things to do with my life. New stuff I write tends to be much
more pep8-ish.

Skip
___
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] pep8 reasoning

[Skip Montanaro]

On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw  wrote:
> I will say this: the original preference for underscore_names in PEP 8 was
> spurred by user studies some of our early non-native English speaking users
> conducted many years ago.  We learned that it was more difficult for many of
> them to parse mixedCase names than underscore_names.  I'm afraid I probably no
> longer have references to those studies, but the difference was pronounced,
> IIRC, and I think it's easy to see why.  Underscores can be scanned by the eye
> as spaces, while I'd hypothesize that the brain has to do more work to read
> mixedCase names.

Given Guido's background, I suspect these studies might have been done
at CWI in the context of the ABC language.

Skip
___
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] devguide: Fix broken link to Skip's optimizer paper, update bug link

[Skip Montanaro]

On Fri, May 2, 2014 at 3:06 PM, Zachary Ware
 wrote:
>> -   
>> (http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/montanaro.html)
>> +   (http://www.smontanaro.net/python/spam7/optimizer.html)
>
> Is this a good link or is there a 'better' one available?

Zach,

That's as a good a link as I know of. (Lot of water under the bridge
since then!)

Skip
___
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] Where is our official policy of what platforms we do support?

[Skip Montanaro]

I wonder if one or more people who maintain unofficial forks on
minority platforms (OS/2, VMS, etc) could create an informational PEP
about the process (benefits and pitfalls) of that kind of effort?

Skip
___
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] Where is our official policy of what platforms we do support?

[Skip Montanaro]

On Wed, May 14, 2014 at 11:05 PM, Guido van Rossum  wrote:
> Main problem with rare platform support is not breaking it accidentally,
> since without buildbots we won't know when it's broken. This is why we don't
> make any promises.

Should we (or do we) offer to run (unofficial) buildbots for
maintainers of minority platforms where possible? For example, I have
no idea if a buildbot for MirOS is even feasible, but if the guy who
submitted the patch is amenable and it is possible to run a buildbot
slave for that OS, it still might be useful to have a "one stop" place
for this. If failing, such buildbots wouldn't block a release, but
would still provide tools for people to track down the source of
breakage.

Skip
___
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] Where is our official policy of what platforms we do support?

[Skip Montanaro]

On Thu, May 15, 2014 at 9:35 AM, Brett Cannon  wrote:
> I view stable buildbots as staying up and testing critical platforms.

Would "supported" and "unsupported" (or "critical" and "optional"?)
make more sense? "Unstable" suggests "broken" to me, not "we don't
really care about these."

S
___
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] Where is our official policy of what platforms we do support?

[Skip Montanaro]

On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou  wrote:
> We already have such buildbots, they are in the "unstable" category.
> You can browse through existing buildbots here:
> https://www.python.org/dev/buildbot/

I can't see how to distinguish "stable" from "unstable" (or to view
just the "unstable" category. What do those two categories have to do
with "supported" and "unsupported"?

Skip
___
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] Criticism of execfile() removal in Python3

[Skip Montanaro]

> you say "do this once", but actually it's "do it in each interactive
> session again and again",  ...

That's what your Python startup file is for. I have been running with
several tweaked builtin functions for years. Never have to consciously load
them. If I wanted execfile badly enough, I'd define it there.

I don't think I've used execfile more than a handful of times in the 20-odd
years I've been using Python. Perhaps our personal approaches to executing
code at the interpreter prompt are radically different, but I think if the
lack of execfile is such a big deal for you, you might want to check around
to see how other people use interactive mode.

Skip
___
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] About "python-porting" mail list

[Skip Montanaro]

> The interwebs has been collecting ton of resources about porting py2
> to 3 during these years. Any not-yet-answered question surely can be
> done in a list with more participants.
>
> Can we kill this list?

Would it perhaps make sense to replace the list with an auto-reply
about the list's demise, then auto-forward their message to
python-list?

Skip
___
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] Register-based VM [Was: Possible performance regression]

[Skip Montanaro]

> I uploaded a tarfile I had on my PC to my web site:
>
> http://python.ca/nas/python/rattlesnake20010813/
>
> It seems his name doesn't appear in the readme or source but I think
> Rattlesnake was Skip Montanaro's project.  I suppose my idea of
> unifying the local variables and the registers could have came from
> Rattlesnake.  Very little new in the world. ;-P

Lot of water under the bridge since then. I would have to poke around
a bit, but I think "from module import *" stumped me long enough that
I got distracted by some other shiny thing.

S
___
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 581: Using GitHub Issues for CPython

[Skip Montanaro]

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for 
> CPython
>
> Full text: https://www.python.org/dev/peps/pep-0581/

Thanks for doing this. I think there is a pretty strong argument to be
made that mature, widely adopted systems like GitHub (or GitLab or
Bitbucket) should be used where possible. One thing I didn't notice
was any sort of explanation about how CPython wound up on Roundup to
begin with. I think it would be worthwhile to mention a couple
reasons, when the decision was made to use Roundup, etc. Without it, a
casual reader might think the core devs made a horrible mistake way
back when, and are only now getting around to correcting it. I don't
recall when Roundup was adopted, but it was quite awhile ago, and the
issue tracker universe was a much different place. Here are a couple
things I recall (perhaps incorrectly). It's been awhile, but for the
digital spelunkers, I'm sure it's all in an email archive somewhere.
(I didn't find a PEP. Did that decision predate PEPs?)

* Back in the olden days, basically every candidate issue tracker
required modification to make it suitable for a particular project. I
don't rightly recall if Roundup was deemed easier to modify or if
there were just people willing to step up and make the necessary
changes.

* There was a desire to eat your own dog food, and I believe Roundup
is/was written in Python. That would be much less important today.
Plenty of people already eat Python brand Dog Food.™

Skip
___
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] Easier debugging with f-strings

[Skip Montanaro]

> My only complaint is that you steadfastly refuse use Guido’s time machine 
> keys to make this available in 3.7.

Wait a minute, Barry. You mean you don't already have an Emacs
function to do the rewriting as a pre-save-hook?

Skip
___
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 594: Removing dead batteries from the standard library

[Skip Montanaro]

> If this were my PEP, I'd call it "Removing unloved batteries from the 
> standard library".

Or maybe, "Removing obsolete and (potentially) dangerous batteries
from the standard library."

I can certainly understand why either class of module would be
removed. When bsddb185 was tossed out, I put it up on PyPI
(https://pypi.org/project/bsddb185/) so the source wouldn't be lost. I
never expected to actually need it, but I got pinged for the first
time a few months ago. Someone needed help building it.

So, no matter the reason for removal, I think it would be reasonable
to toss all these modules into GitHub or PyPI. Someone will want them.

Skip
___
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] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Skip Montanaro]

> You have missed at least one: the minimum technology requirement for
> using Github is a lot more stringent than for Roundup. Github's minimum
> system requirements are higher, and it doesn't degrade as well, so
> moving to Github will make it much harder for those who are using older
> technology. If not exclude them altogether.

Is that Git or GitHub? If the latter, more JavaScript bits or something else?

Skip
___
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/6COCTJ3E2WZUA5DTAWB34NQG5H45MX7I/

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

[Skip Montanaro]

My only comment is that this belongs first on python-ideas
.

Skip
___
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/54OTFAX74ICNALHGC5H4OMZDCIXXJ6J3/